TLS Handshake Encapsulation in HTTP for 6G Roaming Intermediaries
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing PRINS protocol for 5G roaming interfaces faces issues with RIs supporting HTTP CONNECT, leading to business and security risks, and confidentiality protection that impedes RI operations, as RIs lack visibility and control over encrypted tunnels and need to know the negotiated security mechanisms.
Innovation Solution
PRINS v2 uses HTTPS and JSON Web Signature (JWS) for hop-by-hop TLS to protect N32-c procedures, allowing RIs to inspect and participate, and defines a new handshake procedure for shared keying materials, harmonizing N32-c and N32-f operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If end-to-end TLS tunnel is established over roaming intermediaries via HTTP CONNECT, then security protection between vSEPP and hSEPP is achieved, but RIs lose visibility and control over encrypted tunnels
Solution Approach 1:
The patent segments the TLS handshake process into individual HTTP request/response messages that can be inspected at each hop. Instead of a single end-to-end encrypted tunnel, the communication is divided into manageable segments where each RI can see and validate specific portions of the handshake, maintaining both security and visibility.
Solution Approach 2:
The patent introduces HTTP CONNECT as an intermediary mechanism that allows RIs to act as mediators in the TLS handshake process. Each RI can receive HTTP requests, validate them against local policies, and forward them along the path, enabling controlled intermediation that maintains security while providing RI visibility and control.
2Productivity
If HTTP CONNECT is used to establish TLS tunnel, then TCP payloads carrying TLS messages can be exchanged directly, but business and security risks are introduced for RIs
Solution Approach 1:
The patent implements feedback mechanisms where each RI receives HTTP responses from subsequent RIs and can validate them against local security policies. This feedback loop allows RIs to detect and reject malicious or non-compliant traffic, mitigating security risks while maintaining efficient communication through the established TLS tunnel.
Solution Approach 2:
The patent performs preliminary validation actions at each RI before allowing TLS traffic to pass through. Each RI inspects HTTP requests and responses in advance, validating certificates, checking policies, and ensuring compliance before forwarding messages along the roaming path, thereby preventing security risks from compromising communication efficiency.
3Reliability
If confidentiality protection is provided for N32-c procedures, then security is enhanced, but RI operations are impeded due to lack of visibility
Solution Approach 1:
The patent applies local quality by providing confidentiality protection at each individual hop rather than end-to-end. Each RI receives encrypted traffic from the previous hop and forwards it to the next hop, maintaining security at each local level while allowing each RI to inspect and validate the encrypted messages according to local policies, thus balancing security with operational ease.
4Reliability
If traditional TLS layered over TCP is used, then transport protection is achieved, but integration with HTTP/2 and proxy architectures is limited
Solution Approach 1:
The patent makes TLS multi-functional by encapsulating it within HTTP request/response messages. This universal approach allows the same mechanism to work across different proxy architectures, HTTP versions, and network configurations, enabling TLS to adapt to various environments while maintaining transport protection and improving interoperability with existing HTTP/2 infrastructure.
Data Source
AI summary
Transport layer security (TLS) for the Internet and Sixth Generation (6G) Communications is described herein. A first network node encapsulates a transport layer security (TLS) ClientHello message, a client key share, and one or more other TLS extensions in a first hypertext transfer protocol (HTTP) POST request message. Then, the first network node sends, to a second network node, the first HTTP POST request message. The second network node forwards the first HTTP POST request message to a third network node. The third network node encapsulates a TLS ServerHello message, a server key share, a TLS Server Finished message, and one or more other TLS server generated messages in a first HTTP 200 OK status response message. The third network node sends the first HTTP 200 OK status response message to the second network node, which forwards the message to the first network node.