5G Roaming RI Proxy Authentication for Secure N32-c Tunneling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current PRotocol for N32 Interconnect Security (PRINS) in 5G roaming systems requires intermediaries (RIs) to support HTTP CONNECT, turning them into TCP proxies, leading to business and security risks due to lack of cryptographic authentication and visibility, allowing unauthorized traffic through encrypted tunnels.
Innovation Solution
Implementing digital signatures in HTTP CONNECT messages using JSON Web Tokens (JWS) to authenticate and verify the integrity of communication between RIs, ensuring only authorized N32-c procedures are transmitted, thereby enhancing security and control for RIs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If RIs support HTTP CONNECT to enable end-to-end TLS tunneling for N32-c procedures, then security for roaming communication is improved, but business and security risks increase due to lack of cryptographic authentication and visibility
Solution Approach 1:
The patent introduces RIs as intermediary components between vSEPP and hSEPP that perform HTTP CONNECT to establish TLS tunnels. The RI Proxy specifically acts as a mediator that can intercept, inspect, and control traffic passing through the tunnel, enabling both security enforcement and visibility while maintaining the end-to-end encryption architecture.
Solution Approach 2:
The patent implements preliminary authentication and authorization actions before traffic is allowed through the TLS tunnel. The RI Proxy performs cryptographic authentication of N32-c procedures and validates traffic permissions in advance, preventing unauthorized communication before it can occur while still maintaining secure tunneling.
2Ease of operation
If RIs act as TCP proxies to forward traffic between vSEPP and hSEPP, then connectivity and roaming functionality are improved, but control and visibility over transmitted traffic are reduced
Solution Approach 1:
The RI Proxy serves as an intermediary that sits between the TLS-encrypted tunnel and the RI application. It can decrypt and inspect N32-c procedures for validation, then re-encrypt them for forwarding, thereby maintaining both connectivity functionality and traffic visibility/control simultaneously.
Solution Approach 2:
The patent metaphorically applies 'color changes' by transforming the opaque encrypted tunnel into a transparently controllable interface. The RI Proxy makes traffic visible and controllable (changing its 'color' from hidden to observable) while preserving the encrypted transport properties, enabling both ease of operation and difficulty of detection to be satisfied.
3Reliability
If cryptographic authentication is implemented in HTTP CONNECT messages using JWS tokens, then security control and authorization are improved, but message complexity and processing overhead increase
Solution Approach 1:
The patent changes the parameter structure of HTTP CONNECT messages by incorporating JWS tokens with specific cryptographic parameters (algorithm, key ID, signature). This standardized parameter change enables automated cryptographic verification while managing complexity through structured data formats that can be processed algorithmically.
Solution Approach 2:
The patent replaces manual security control mechanisms with automated cryptographic verification using JWS tokens. The mechanical process of manual authentication is substituted with algorithmic verification of digital signatures, reducing human complexity while enhancing security control through machine-executable cryptographic proofs.
Data Source
AI summary
Methods and apparatus for session management for a Fifth Generation (5G) roaming solution using PRotocol for N32 INterconnect Security (PRINS) are provided herein. A first roaming intermediary (RI) Proxy receives a first hypertext transfer protocol secure (HTTPS) request, including a first JavaScript Object Notation (JSON) Web Encryption (JWE) token. The first RI Proxy reconstructs a first hypertext transfer protocol (HTTP) request based on the JWE token, and forwards the first HTTP request to a first RI application. The first RI Proxy receives a second HTTP request from the first RI application. The first RI Proxy creates a first JSON patch based on the first HTTP request and the second HTTP request. The first RI Proxy protects the first JSON patch with JSON Web Signature (JWS) to create a first JWS token. The first RI Proxy sends a second HTTPS request, including the first JWE token and the first JWS token.


