Patent Application
20250227126
The subject matter described herein relates to establishing communications channel for network function. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for out-of-band TLS version and parameter negotiation.
While promising significant security enhancements, deploying TLS 1.3 in 5G core networks introduces the challenge of backward compatibility with existing TLS 1.2 infrastructure. Unlike smoother transitions between earlier versions, TLS 1.3's incompatibility necessitates explicit version negotiation at the handshaking stage. This relies on the ClientHello message carrying a “supported_versions” extension to advertise its capabilities. Ideally, a TLS 1.2 server should recognize this extension and, if unable to support TLS 1.3, use the ClientHello's “legacy_version” field to gracefully fallback to a compatible version, such as TLS 1.2.
However, the potential for improperly written TLS 1.2 servers complicates this process. These servers may abruptly abort the handshake upon encountering unfamiliar extensions like “supported_versions,” causing connection failures. Consequently, mitigating this vulnerability requires careful server and client configuration, considering legacy compatibility alongside the security benefits of TLS 1.3.
In light of these and other difficulties, there exists a need for improved methods, systems, and computer readable media for out-of-band TLS version and parameter negotiation.
An example method includes registering, at a network function repository function (NRF) of a telecommunications network, a producer network function, including receiving a first transport layer security (TLS) version for the producer network function; providing, by the NRF, the first TLS version of the producer network function to a consumer network function in a network function discovery response; and establishing, by the consumer network function, a service based interface (SBI) communication with the producer network function based on the first TLS version and a second TLS version for the consumer network function.
According to another aspect of the subject matter described herein, the method includes registering, at the NRF, the consumer network function and receiving the second TLS version for the consumer network function during registration.
According to another aspect of the subject matter described herein, registering the producer network function and the consumer network function comprises storing the first TLS version in a first network function profile for the producer network function and storing the second TLS version in a second network function profile for the consumer network function.
According to another aspect of the subject matter described herein, registering the producer network function and the consumer network function comprises storing one or more first TLS parameters in a first network function profile for the producer network function and storing one or more second TLS parameters in a second network function profile for the consumer network function.
According to another aspect of the subject matter described herein, the method includes finding, at the NRF, one or more misconfigured TLS parameters in a plurality of network function profiles stored by the NRF.
According to another aspect of the subject matter described herein, the method includes notifying a network operator of the one or more misconfigured TLS parameters.
According to another aspect of the subject matter described herein, the method includes applying one or more operator-based policies using a plurality of TLS parameters stored in a plurality of network function profiles.
An example system includes at least one processor and a memory. The system includes an an NF repository function (NRF) of a telecommunications network, the NRF being implemented using the at least one processor and configured for: registering a producer network function, including receiving a first transport layer security (TLS) version for the producer network function; and providing, by the NRF, the first TLS version of the producer network function to a consumer network function in a network function discovery response. The consumer network function is configured for establishing a service based interface (SBI) communication with the producer network function based on the first TLS version and a second TLS version for the consumer network function
According to another aspect of the subject matter described herein, the NRF is configured for registering, at the NRF, the consumer network function and receiving the second TLS version for the consumer network function during registration.
According to another aspect of the subject matter described herein, registering the producer network function and the consumer network function comprises storing the first TLS version in a first network function profile for the producer network function and storing the second TLS version in a second network function profile for the consumer network function.
According to another aspect of the subject matter described herein, registering the producer network function and the consumer network function comprises storing one or more first TLS parameters in a first network function profile for the producer network function and storing one or more second TLS parameters in a second network function profile for the consumer network function.
According to another aspect of the subject matter described herein, the NRF is configured for finding, at the NRF, one or more misconfigured TLS parameters in a plurality of network function profiles stored by the NRF.
According to another aspect of the subject matter described herein, the NRF is configured for notifying a network operator of the one or more misconfigured TLS parameters.
According to another aspect of the subject matter described herein, the NRF is configured for applying one or more operator-based policies using a plurality of TLS parameters stored in a plurality of network function profiles.
According to another aspect of the subject matter described herein, a non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor of a computer control the computer to perform steps is provided. The steps include registering, at a network function repository function (NRF) of a telecommunications network, a producer network function, including receiving a first transport layer security (TLS) version for the producer network function; providing, by the NRF, the first TLS version of the producer network function to a consumer network function in a network function discovery response; and establishing, by the consumer network function, a service based interface (SBI) communication with the producer network function based on the first TLS version and a second TLS version for the consumer network function.
The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
Exemplary implementations of the subject matter described herein will now be explained with reference to the accompanying drawings, of which:
This document describes methods, systems, and computer readable media for solving TLS inter-operability issues and improving performance and security by out-of-band negotiation of TLS version and parameters. Network functions can provide TLS version and parameters as part of the NF discovery process.
RFC 8446 highlights the challenge of incorporating TLS 1.3 into 5G core networks due to its incompatibility with previous TLS versions. This mandates a version negotiation mechanism to establish seamless communication. However, the introduction of new extensions in TLS 1.3's ClientHello message, such as supported_versions, key_share, and signature_algorithms_cert, poses potential interoperability issues with legacy TLS 1.2 servers.
The crux of the challenge lies in the NF Consumer's initial unawareness of the NF Producer's supported TLS version. This leads to the transmission of ClientHello with TLS 1.3 extensions, even towards TLS 1.2 servers. While ideally, a TLS 1.2 server should gracefully handle unsupported extensions, real-world implementations often exhibit unpredictable behaviors, including handshake terminations.
Beyond interoperability concerns, frequent TLS parameter negotiation for each new TCP/TLS connection introduces performance overheads and potential vulnerabilities associated with insecure parameter selection.
To address these concerns, this document proposes the inclusion of TLS version and parameter information within NF discovery responses. This enables clients to proactively select compatible versions and parameters, fostering interoperability, enhanced performance, and a more robust security posture.
Furthermore, storing this information within NF profiles at the NRF offers several advantages:
By adopting these measures, 5G networks can effectively address TLS interoperability challenges, enhance performance, and bolster security posture through comprehensive visibility and control.
NFs register with a network function repository function (NRF). The NRF maintains profiles of available NF instances identifying the services supported by each NF instance. The profile of an NF instance is referred to in 3GPP TS 29.510 as an NF profile.
NF instances can obtain information about other NF instances that have registered with the NRF through the NF discovery service operation. According to the NF discovery service operation, a consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters that the NRF uses to locate the NF profiles of producer NFs capable of providing the service identified by the query parameters. NF profiles are data structures that define the type of service provided by an NF instance as well as contact and capacity information regarding the NF instance.
The architecture in
NRF 100 is a repository for profiles of NF instances. To communicate with a producer NF instance, a consumer NF or an SCP must obtain the NF profile of the producer NF instance from NRF 100. The NF profile is a Javascript object notation (JSON) data structure defined in 3GPP TS 29.510. The NF profile includes attributes that indicate the type of service provided, capacity of the NF instance, and information for contacting the NF instance.
In
The NFs illustrated in
A network slice selection function (NSSF) 116 provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. NSSF 116 provides the NSSelection service, which allows NFs to request information about network slices and the NSSAIReachability service, which enables NFs to update and subscribe to receive notification of updates in network slice selection assistance information (NSSAI) reachability information.
A network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (IoT) devices and other UEs attached to the network. NEF 118 performs similar functions to the service capability exposure function (SCEF) in 4G networks.
A radio access network (RAN) 120 connects user equipment (UE) 114 to the network via a wireless link. Radio access network 120 may be accessed using a gNB (not shown in
SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. SEPP 126 may communicate with an SEPP in a foreign PLMN which manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN. A unified data repository (UDR) 128 stores subscription data for UEs. A binding support function (BSF) 130 manages bindings between PDU sessions and PCFs.
Network functions within the 5G core leverage TLS to encrypt and authenticate connections, preventing unauthorized access and bolstering the overall resilience of the communication infrastructure. The implementation of TLS in the 5G core is not only integral to preserving the privacy of user information but also contributes to the reliability and trustworthiness of the network, meeting the stringent security requirements essential for the deployment of advanced and diverse services in the 5G era.
RFC 5246 section 7.3 defines the TLS handshake protocol. The handshake is introduced before TLS extensions and version negotiation.
Further, the TLS parameter negotiation typically must be repeated for each new TLS connection, which can impact performance. Incomplete information in ClientHello causes another round trip, which should be avoided to improve performance. Further TLS parameter negotiation potentially exposes security attacks that my be exploited.
Referring to
Both the consumer network function 302 and the producer network function 306 provide TLS version information and optionally other parameters as part of registering with the NRF 304. The NRF 304 provides the TLS version and parameters of the producer network function 306 to the consumer network function 302 in a discovery response. As a result, the consumer network function 302 is able to correctly establish the SBI communication with the producer network function 306.
The NRF 304 can store the TLS version and parameter information in network function profiles. The NF profiles typically encompass crucial information about each network function's capabilities and characteristics. These profiles serve as a comprehensive reference for the dynamic orchestration and management of network services. The NRF 304, in some cases, maintains a structured database containing details such as supported interfaces, service capabilities, and specific attributes relevant to each NF. This information is regularly updated by network functions as they register with the NRF 304, ensuring real-time accuracy and reflecting the evolving nature of the network. The storage of NF profiles by the NRF 304 enables efficient service discovery, dynamic adaptation, and interoperability within the 5G core.
This solution can provide one or more of the following advantages:
Referring to
The consumer network function 302 then exchanges messages 406 with the NRF 304 for a network discovery request that results in identification of the producer network function 306. Then the consumer network function 302 exchanges messages 408 with the consumer network function to establish SBI communication using the appropriate version of TLS, for example, TLS 1.3 if both network functions 302 and 306 support TLS 1.3 and TLS 1.2 if one or both does not support TLS 1.3.
The method 500 includes registering 502, at an NRF of a telecommunications network, a producer network function and a consumer network function. The registration includes receiving a first TLS version for the producer network function and a second TLS version for the consumer network function.
The method 500 includes storing 504 the first TLS version in a first network function profile for the producer network function and storing 504 the second TLS version in a second network function profile for the consumer network function. The method 500 can include storing one or more first TLS parameters in a first network function profile for the producer network function and storing one or more second TLS parameters in a second network function profile for the consumer network function.
Examples of TLS parameters include cipher suites that dictate cryptographic algorithms like AES-GCM or ChaCha20-Poly1305, determining data encryption methods. Key exchange algorithms, such as RSA or Diffie-Hellman, specify secure key-sharing processes. Certificate information includes details about authentication certificates, like the issuing certificate authority and public key. Hash functions, such as SHA-256, are employed for integrity checks. Session resumption parameters optimize performance by allowing the resumption of previously established secure sessions. Perfect Forward Secrecy (PFS) support ensures ongoing security even if long-term keys are compromised. Additional considerations encompass maximum transmission unit (MTU), renegotiation policies, compression methods, and other configurations, collectively defining the security framework for TLS connections. These parameters align with security policies, compliance requirements, and cryptographic capabilities, safeguarding the confidentiality, integrity, and authenticity of data within the 5G core network.
The method 500 includes providing 506, by the NRF, the first TLS version of the producer network function to the consumer network function in a network function discovery response.
The method 500 includes establishing 508, by the consumer network function, an SBI communication with the producer network function based on the first TLS version for the producer network function and the second TLS version for the consumer network function. For example, if both network functions support TLS 1.3, then the method 500 can include using the TLS 1.3 handshake. If one or the other of the network functions does not support TLS 1.3 but does support TLS 1.2, then the method 500 can include using the TLS 1.2 handshake.
The method 500 can include finding, at the NRF, one or more misconfigured TLS parameters in the network function profiles stored by the NRF. For example, the NRF can continuously or periodically analyze the stored TLS parameters for potential misconfigurations. This can include scrutinizing elements such as cipher suites, key lengths, and protocol versions to identify any deviations from recommended security practices.
The method 500 can include notifying a network operator of the one or more misconfigured TLS parameters. For example, notifying can include sending a message or presenting a notification in a user interface. Upon detecting misconfigured TLS parameters, the NRF can trigger corrective actions, possibly initiating updates or notifications to the relevant network functions. This proactive approach can help ensure that TLS security standards are upheld across the 5G core network, mitigating potential vulnerabilities arising from misconfigurations and contributing to the overall robustness of the communication infrastructure.
The method 500 can include applying one or more operator-based policies using the TLS parameters stored in the network function profiles. Operator-defined policies could encompass a range of security measures tailored to the specific needs and preferences of the network operator. For instance, policies might dictate minimum TLS version requirements, preferred cipher suites, or key exchange algorithms. These policies can be designed to align with regulatory compliance standards or industry best practices, ensuring a standardized and secure communication environment.
The NRF can dynamically apply these policies across the network by evaluating TLS parameters stored in the network function profiles. If a network function's TLS parameters deviate from the defined policies, the NRF could initiate corrective actions, such as signaling the relevant functions to update their configurations accordingly. This approach can be useful, for example, for mitigating the risk of vulnerabilities arising from inconsistent TLS configurations.
The disclosure of each of the following references is hereby incorporated herein by reference in its entirety.
It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.
