Patent Application
20250126151
This application claims the benefit of European patent application serial number 21382865.0, filed Sep. 28, 2021, the disclosure of which is hereby incorporated herein by reference in its entirety.
The present disclosure relates to Transport Layer Security (TLS) authentication.
Today, there is a strong move for encrypting Domain Name System (DNS) exchanges for obvious privacy reasons. More specifically, encryption prevents a man-in-the-middle attack to intercept and read the DNS exchanges, which contain privacy-sensitive information, i.e., your web history. However, a man-in-the middle attack is only one type of attack. Accordingly, there is a need to ensure that the termination (e.g., DNS resolver) of the encrypted channel from the DNS client corresponds to the one chosen by the DNS client.
Network Operators (NOs), such as Mobile Network Operators (MNOs), should be able to provide or provision encrypted DNS resolvers in order to avoid a user's data being sent to third parties. This can be done by managing a Transport Layer Security (TLS) session between the User Equipment (UE) and the DNS resolver. Cloud providers and web browser providers are using the privacy argument to convince end users to switch from using the DNS resolver provided by their NO to a DNS resolver provided by the cloud provider. However, because there is trust in the NO network, there is a need to ensure that applications (e.g., cloud service applications and/or web browsers) cannot not overwrite user choices or NO configuration.
Systems and methods for Transport Layer Security (TLS) authentication based on a hash of an expected certificate are disclosed. In one embodiment, a method performed by a client application comprises obtaining one or more configuration parameters for establishing a TLS session between the client application and a trusted server application, the one or more configuration parameters comprising either: a certificate of the trusted server application, a hash of the certificate of the trusted server application, or a Pre-Shared Key (PSK). The method further comprises performing a TLS handshake procedure with a server application, wherein either: during the TLS handshake procedure the client application receives a certificate from the server application, or the TLS handshake procedure is performed with PSK authentication based on the PSK comprised in the one or more configuration parameters. The method further comprises determining that an error has occurred based on either: (a) a comparison of either (i) the certificate of the trusted server application comprised in the one or more configuration parameters and the certificate received from the server application during the TLS handshake or (ii) the hash of the certificate of the trusted server application and a computed hash of the certificate received from the server application during the TLS handshake; or (b) failed PSK authentication. The method further comprises, responsive to determining that the error has occurred, performing one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters.
In one embodiment, the one or more configuration parameters comprise the hash of the certificate of the trusted server application, and the method further comprises computing a hash of the certificate received from the server application during the TLS handshake. Determining that the error has occurred comprises comparing the hash of the certificate of the trusted server application comprised in the one or more configuration parameters and the hash of the received certificate and determining that there is an error based on a result of comparing the hash of the certificate of the trusted server application comprised in the one or more configuration parameters and the hash of the received certificate. In one embodiment, the one or more configuration parameters comprise an Internet Protocol (IP) address associated to the trusted server application, an indication of a security protocol type, and a TLS for Authentication record (TLSA) that contains the hash of the certificate of the trusted server application. In one embodiment, the one or more configuration parameters further comprise a port number. In one embodiment, the one or more configuration parameters further comprise an authentication domain name.
In one embodiment, the method further comprises, responsive to determining that the error has occurred, aborting setup of the TLS session.
In one embodiment, performing one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters comprises reporting a TLS error to a network node. In one embodiment, the method further comprises, responsive to reporting a TLS error to a network node, receiving a message comprising one or more re-initialized configuration parameters for establishing a TLS session between the client application and a trusted server application.
In one embodiment, performing one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters comprises sending, to a network node, a message for modification of the IP connectivity session that comprises an indication of a request for re-initialization of the one or more configuration parameters for establishing a TLS session between the client application and a trusted server application.
In one embodiment, the client application is a Domain Name System (DNS) client, and the server application is a DNS resolver.
In one embodiment, the client application is implemented on a wireless communication device for a cellular communications system, and obtaining the one or more configuration parameters comprises obtaining the one or more configuration parameters from a network node in a core network of the cellular communications system. In one embodiment, the cellular communication system is either a Fifth Generation System (5GS) or an Evolved Packet System (EPS).
Corresponding embodiments of a communication device that includes a client application are also disclosed. In one embodiment, a communication device that includes a client application comprises processing circuitry configured to cause the communication device to obtain one or more configuration parameters for establishing a TLS session between the client application and a trusted server application, the one or more configuration parameters comprising either: a certificate of the trusted server application, a hash of the certificate of the trusted server application, or a PSK. The processing circuitry is further configured to cause the communication device to execute the client application such that the client application performs a TLS handshake procedure with a server application, wherein either: during the TLS handshake procedure, the client application receives a certificate from the server application, or the TLS handshake procedure is performed with PSK authentication based on the PSK comprised in the one or more configuration parameters. The processing circuitry is further configured to cause the communication device to execute the client application such that the client application determines that an error has occurred based on either: (a) a comparison of either: (i) the certificate of the trusted server application comprised in the one or more configuration parameters and the certificate received from the server application during the TLS handshake or (ii) the hash of the certificate of the trusted server application and a computed hash of the certificate received from the server application during the TLS handshake; or (b) failed PSK authentication. The processing circuitry is further configured to cause the communication device to execute the client application such that the client application to, responsive to determining that the error has occurred, perform one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters.
In one embodiment, a method performed by a client application comprises obtaining one or more configuration parameters for establishing a TLS session between the client application and a trusted server application, the one or more configuration parameters comprising either: a certificate of the trusted server application or a hash of the certificate of the trusted server application. The method further comprises performing a TLS handshake procedure with a server application during which the client application receives a certificate from the server application and determining that the server application from which the certificate is received during the TLS handshake is the trusted server application based on a comparison of either: (i) the certificate of the trusted server application comprised in the one or more configuration parameters and the certificate received from the server application during the TLS handshake or (ii) the hash of the certificate of the trusted server application and a computed hash of the certificate received from the server application during the TLS handshake. The method further comprises, responsive to determining that the server application from which the certificate is received during the TLS handshake is the trusted server application, proceeding with setup of the TLS session. The method further comprises performing a TLS handshake for establishment of a subsequent TLS session associated to the same IP connectivity session using a mechanism that ensures that the subsequent TLS session is established to the same trusted server application at that to which the TLS session is established.
In one embodiment, the mechanism is either TLS session resumption based on a PSK or PSK Elliptic-Curve Diffie-Hellman Exchange (PSK-ECDHE) authentication or a TLS handshake using Elliptic-Curve Diffie-Hellman Exchange (ECDHE) authentication.
Embodiments of a method performed by a first network node in a core network of a cellular communications system are also disclosed herein. In one embodiment, a method performed by a first network node in a core network of a cellular communications system comprises receiving, from a second network node, a message that comprises one or more rules to be implemented by the first network node to detect a TLS error reported by a wireless communication device within traffic for an existing TLS connection between a DNS client at the wireless communication device and a DNS resolver. The method further comprises detecting a TLS error reported by the wireless communication device using the one or more rules and, responsive to detecting the TLS error, sending a message to the second network node that comprises an indication of a request to re-initialize one or more DNS parameters configured to the wireless communication device.
In one embodiment, the cellular communications system (300) is a 5GS, the first network node is a User Plane Function (UPF), and the second network node is a Session Management Function (SMF). Receiving the message that comprises the one or more rules comprises receiving, from the SMF (500), a Packet Forwarding Control Protocol (PFCP) Session Establishment Request comprising the one or more rules, and sending the message comprises sending a PFCP report request message to the SMF, wherein the PFCP report request message comprises the indication of the request to re-initialize the one or more DNS parameters configured to the wireless communication device.
In another embodiment, a method performed by a first network node in a core network of a cellular communications system comprises sending, to a second network node, a message that comprises one or more rules to be implemented by the second network node to detect a TLS error reported by a wireless communication device within traffic for an existing TLS connection between a DNS client at the wireless communication device and a DNS resolver. The method further comprises receiving a message from the second network node that comprises an indication of a request to re-initialize one or more DNS parameters configured to the wireless communication device and, responsive to receiving the message, triggering an Internet Protocol (IP) session modification procedure for re-initializing one or more DNS parameters configured to the wireless communication device.
In one embodiment, the cellular communications system is a 5GS, the first network node is a SMF, and the second network node is a UPF. Sending the message that comprises the one or more rules comprises sending, to the UPF, a PFCP Session Establishment Request comprising the one or more rules, and receiving the message comprises receiving a PFCP report request message from the UPF, wherein the PFCP report request message comprises the indication of the request to re-initialize the one or more DNS parameters configured to the wireless communication device. Triggering the IP session modification procedure for re-initializing the one or more DNS parameters configured to the wireless communication device comprises triggering a Protocol Data Unit (PDU) session modification procedure for re-initializing the one or more DNS parameters configured to the wireless communication device.
Corresponding embodiments of network nodes are also disclosed herein.
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.
The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.
Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device.
Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.
Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.
Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (IoT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.
Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.
Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.
Today, Domain Name System (DNS) resolutions are performed by an authenticated DNS resolver in order to improve end user's privacy. While this represents an improvement on the end user's privacy, little attention is being provided to ensure that the authenticated DNS resolver matches the choice of the end user. Currently, when communication device requests the support of encrypted DNS, the communication device obtains the necessary configuration parameters (IP address and TLS parameters) from the network to set the encrypted session (i.e., the Transport Layer Security (TLS) session) with the DNS resolver. The necessary configuration parameters for the TLS session are generally provided from the network to the communication device during establishment of an Internet Protocol (IP) connectivity session (e.g., during Protocol Data Unit (PDU) session establishment in a 3GPP 5GS or during IP connectivity session establishment in a 3GPP EPS). Each TLS session to the DNS resolver is based on these configuration parameters. Thus, the current solution assumes that the configuration parameters have not been changed by any parties. Thus, the existing solution consists of provisioning configuration parameters and having the DNS client us them each time a TLS session is needed. This solution puts a lot of trust into the configuration parameters and requires these configuration parameters to remain relatively static. However, it is quite possible that these configurations parameters may be changed at the device, e.g., via an attack or otherwise, such that TLS sessions are subsequently established to a DNS resolver other than that configured by the network/NO/MNO/ISP.
Systems and methods are disclosed herein that address the aforementioned and/or other issues related to existing DNS resolution solutions. Note, however, that while some of the embodiments described herein are described with respect to DNS resolution, embodiments of the solutions described herein are not limited to DNS resolution and may be used with respect to TLS sessions established between any two endpoints.
In some embodiments, systems and methods are provided that relate to a DNS resolver (e.g., provided by a network, Network Operator (NO), or Internet Service Provider (ISP)) that is authenticated using TLS authentication and a corresponding DNS client. Embodiments are disclosed herein that increases the probability that the DNS resolver used by the DNS client for an initial TLS session and any subsequent TLS session(s) associated to the same IP connectivity session is the same DNS resolver configured by the network/NO/ISP when the IP connectivity session is established. In other words, embodiments of the present disclosure increase the probability that network parameters configured by the network/NO/ISP are not changed by a third-party application during the lifetime of the IP connectivity session. Embodiments are disclosed herein related to mechanisms that are enforced on the DNS client as well as mechanisms that are enforced by the DNS resolver. These mechanisms include any one or more of the following mechanisms:
While not being limited by or to any particular advantages, embodiments of the solutions described herein provide advantages over the existing solutions. These advantages include one or more of the following advantages:
In this regard,
session between the client application 108 at the communication device 106 and the server application 112 at the network node 110 as well as TLS error handling and establishment of subsequent TLS session(s), in accordance with embodiments of the present disclosure. Optional steps are represented by dashed lines/boxes. As illustrated, the communication device 106 obtains configuration parameters for TLS session setup from the network 102 (e.g., from a network node 104) (step 200). In one embodiment, the configuration parameters are obtained in association with (e.g., during) a procedure for establishment of an associated IP connectivity session between the communication device 106 and the network 102. For example, in an embodiment in which the system 100 is a 3GPP 5GS, the IP connectivity session is a PDU session, and the configuration parameters are obtained by the communication device 106 from the network 102 during PDU session establishment. As another example, in another embodiment, the system 100 is a 3GPP EPS, the IP connectivity session is an IP-Connectivity Access Network (IP_CAN) session, and the communication device 106 obtains the configuration parameters from the network 102 during PDN session/connection establishment.
In one embodiment, the configuration parameters for TLS session setup include either: (a) a TLS certificate of a trusted (or expected) server application (e.g., a trusted DNS resolver) or (b) a hash of the TLS certificate of the trusted server application. In the example of
Until otherwise noted, the remainder of the discussion of
Assuming that TLS authentication was successful, in one embodiment, one or more additional TLS sessions between the client application 108 and the server application 112 may subsequently be desired. In one embodiment, in order to establish an additional TLS session (e.g., associated to the same IP connectivity session as the initial TLS session above), rather than using the configuration parameters, the client application 108 utilizes TLS handshake mechanism that relies on a secret obtained by the client application 108 during setup of the initial TLS session such that setup of the additional TLS session will only be successful if the server application 112 is the same as that to which the initial TLS session was established (step 216). As discussed below, in one example embodiment, setup of the additional TLS session utilizes a session resumption mechanism defined in, e.g., TLS 1.3 based on a Pre-Shared Key (PSK) or PSK-Elliptic-Curve Diffie-Hellman Exchange (ECDHE) authentication. As understood by those of skill in the art, the PSK or PSK-ECDHE is obtained during setup of the initial TLS session above and is used for TLS authentication during a modified TLS handshake (i.e., a TLS handshake for session resumption). In another example embodiment, the TLS handshake for the additional TLS session uses ECDHE authentication. Because the TLS handshake for the additional TLS session relies on a secret obtained during the initial TLS session setup, TLS authentication for the additional TLS session will only succeed if the server application 112 is the same as that to which the initial TLS session was established (step 218). Otherwise, TLS authentication will fail and a TLS error will be detected, which in turn will trigger a TLS error report to the network 102 (step 220). The network will then perform a network-triggered re-initialization of the configuration parameters for TLS session setup (step 222).
Before proceeding a description of an alternative embodiment in which the configuration parameters of step 200 include a PSK. In this case, in step 202, the TLS handshake procedure uses PSK authentication (and as such the certificate may not be provided to the client application 108 during the TLS handshake). If the server application 112 is the trusted server application, PSK authentication will succeed. Otherwise, PSK authentication, and thus TLS session setup, will fail. If PSK authentication fails, the client application 108 detects a TLS error and may send a notification of the TLS error to the network node, e.g., in step 212, which in turn may trigger the network to re-initialize the configuration parameters, as described above.
Now, the description will turn to specific example embodiments related to an authenticated DNS resolver and a DNS client. Further, in these example embodiments, the authenticated DNS resolver and the DNS client are implemented in the context of a 3GPP 5GS. However, it is to be understood that the following embodiments are not limited to a 3GPP 5GS but may be utilized in other types of 3GPP systems (e.g., EPS) and/or in other types of communication systems (e.g., an ISP network).
In this regard,
In accordance with one embodiment of the present disclosure, the 5GS 300 also includes a network node 312 that hosts or otherwise implements a DNS resolver 314. In the illustrated example, the network node 312 is illustrated as part of the core network 306; however, the present disclosure is not limited thereto. Further, a DNS client 316 is implemented on the wireless communication device 310.
In the following, an initial, or first (in time), TLS session between a DNS client and a DNS resolver is performed in such a way that it is guaranteed that the DNS resolver is the expected (legitimate or trusted) DNS resolver. Then, rather than relying on the same configuration parameters when establishing subsequent TLS sessions associated to the same PDU session, other mechanism (e.g., TLS session resumption procedure) is performed to ensure that the subsequent TLS sessions are established with the same (legitimate) DNS resolver. This strategy is referred to herein as Trust On First Use (TOFU).
As illustrated, the wireless communication device (WCD) 310 obtains configuration parameters for TLS session setup from a network node 308 in association with (e.g., during) a PDU session establishment procedure of a particular PDU session (step 400). The configuration parameters for TLS session setup include either: (a) a TLS certificate of an expected, or trusted, DNS resolver or (b) a hash of the TLS certificate of the expected, or trusted, DNS resolver. In one embodiment, the hash of the TLS certificate, rather than the full chain of expected certificate, is included in the configuration parameters. In this manner, the size of the configuration parameters in terms of number of bytes of data is substantially reduced. The configuration parameters for TLS session may further include one or more other parameters such as, e.g., an IP address of the DNS resolver 314 or the network node 312, security protocol type, etc.).
More specifically, in one embodiment, if the IP address of the DNS resolver 314 is public and the DNS resolver 314 has a public certificate (e.g., X.509 certificate) with the IP address of the DNS resolver 314 appearing in the SubjectAtName or similar field, the network node 308 sends the DNS client 316 at the WCD 310 the following configuration parameters:
In one embodiment, if the DNS resolver 314 does not have a public IP address and a certificate (e.g., a X509 certificate) associated the DNS resolver 314 has a subjectAtName or similar field that contains an authoritative domain name, the network node 308 sends the DNS client 316 at the WCD 310 the following configuration parameters:
Note also that SPKI [RFC7469] could alternatively be used to carry the hash of the expected certificate.
Sometime thereafter, when the WCD 310 desires to setup an initial TLS session for communication between the DNS client 316 and the DNS resolver 314 at the network node 312, the WCD 310 and the network node 312 perform a TLS handshake procedure during which the WCD 310 receives a TLS certificate of the DNS resolver 314 (step 402). More specifically, the DNS client 316 on the WCD 310 derives the DNS resolver 314 from the DNS Server IP address (e.g., the IPV6 Address or DNS Server IPV4 Address) contained in the received configuration parameters. The DNS client 316 derives the port from the port number parameter and, when not explicitly specified, the DNS client 310 uses the default port specified by the security protocol. For the TLS handshake, the DNS client 316 starts the TLS session with the IP address and port and, during the TLS handshake, receives the TLS certificate of the DNS resolver 314.
In one embodiment, the WCD 310 computes a hash of the received TLS certificate (step 404). The WCD 310 determines whether the DNS server 114 is authenticated (i.e., determines whether the DNS resolver 114 is the expected DNS resolver) based on a comparison of the received certificate or the computed hash and the certificate or hash included in the configuration parameters (e.g., in the DSSI TLSA) in step 400 (step 406). If there is not a match (i.e., if there is a mismatch between the two certificates/hashes), the TLS handshake is aborted with a “bad_certificate” error (step 408). In addition, if a DSSI authentication domain has been provided in the configuration parameters, the DNS client 316 checks that the provided DSSI authentication domain matches the certificate Subject Alternative Name (SAN); otherwise, the DNS client XX116 determines whether the certificate SAN matches the DNS Server IPv4/6 Address (step 410). If a mismatch occurs, the TLS handshake is aborted with a “bad_certificate” error (step 412). If there is a match between the two certificates/hashes and if there is a match between either the provided DSSI authentication domain and the certificate SAN or a match between the certificate SAN and the DNS Server IPv4/6 Address, the TLS authentication is a success (i.e., the TLS session is set) and communication between the DNS client 316 and the DNS resolver 314 over the established TLS session is performed (step 414). Note that the matching of the SAN in step 410 is optionally performed to check coherence with other configuration parameters, but this could be considered as additional checks given that the hash is provided in a secure way and the hash match should be sufficient.
In one embodiment, if a bad_certificate error is returned, this event is logged and an alert is raised to the ISP for further investigation as the WCD 310 is considered to be unable to connect to the Internet.
In one embodiment, if a bad_certificate error is returned, the WCD 310 determines that there is a TLS error and reports this TLS error to the network (e.g., to the network node 308 in the illustrated embodiment) (step 416). In response, the network (e.g., the network node 308) initiates a procedure by which the configuration parameters for TLS session setup are re-configured at the WCD 310 (step 418).
Assuming that TLS authentication was successful, in one embodiment, one or more additional TLS sessions between the DNS client 316 and the DNS resolver 314 may subsequently be desired. In one embodiment, in order to establish an additional TLS session associated to the same PDU session as the initial TLS session above, rather than using the configuration parameters, the DNS client 316 utilizes a TLS handshake mechanism that relies on a secret obtained by the DNS client 316 during setup of the initial TLS session such that setup of the additional TLS session will only be successful if the DNS resolver 314 is the same as that to which the initial TLS session was established (step 420). As discussed below, in one example embodiment, setup of the additional TLS session utilizes a session resumption mechanism defined in, e.g., TLS 1.3 based on a Pre-Shared Key (PSK) or PSK-Elliptic-Curve Diffie-Hellman Exchange (ECDHE) authentication. As understood by those of skill in the art, the PSK or PSK-ECDHE is obtained during setup of the initial TLS session above and is used for TLS authentication during a modified TLS handshake (i.e., a TLS handshake for session resumption). In another example embodiment, the TLS handshake for the additional TLS session uses ECDHE authentication. Because the TLS handshake for the additional TLS session relies on a secret obtained during the initial TLS session setup, TLS authentication for the additional TLS session will only succeed if the DNS resolver 314 is the same as that to which the initial TLS session was established (step 422). Otherwise, TLS authentication will fail and a TLS error will be detected, which in turn will trigger a TLS error report to the network 102 (step 424). The network will then perform a network-triggered re-initialization of the configuration parameters for TLS session setup (step 426).
In one embodiment, when a TLS session cannot be set, a renegotiation of the configuration parameters associated to the DNS resolver 314 is performed. Such negotiation may be initiated (and optionally performed) by the DNS client 316 or the DNS resolver 314. In one embodiment, once initiated, the renegotiation of the configuration parameters is performed by the network upon the receipt of a report of a TLS error from the DNS client 316 or the DNS resolver 314.
As discussed above, in the event of a TLS error, reinitialization of the configuration parameters associated with the DNS resolver 314 is desired. In this regard,
As illustrated in
The UPF 502 answers the SMF 500 with a PFCP Session Establishment Response indicating successful operation (step 508).
The WCD 310 (e.g., the DNS client 316) decides that DNS re-initialization is needed (step 510) and sends a specific TLS error message in the existing TLS connection between the DNS client 316 and the DNS resolver 314 (step 512). The DNS client 316 may decide that DNS re-initialization is needed when a “bad_certificate” error occurs in step 408 or 412 of
The UPF 502 detects the TLS error message in the existing TLS connection between the DNS client 1016 and the DNS resolver 1014 based on the configured PDR and URR from step 506 (step 514) and reports the TLS error to the SMF 500 in a PFCP Session Report Request message (step 516). In one embodiment, the SMF 500 reports the detected TLS error in the PFCP Session Report Request message by extending the Application Detection Information IE as follows:
The proposed solution includes the following impacts (in bold) in the current 3GPP TS 29.244:
The SMF 500 answers the UPF 502 with a PFCP Session Report Response indicating successful operation (step 518).
Based on the above report, the SMF 500 triggers a (SMF requested) PDU Session Modification procedure including an extended Protocol Configuration Options (ePCO) Information Element (IE) with the configuration parameters related to DNS resolution (also referred to herein as “DNS parameters) (step 520). In order to do this, the SMF 5000 triggers, towards a corresponding AMF 522, a Namf_Communication_N1N2_MessageTransfer message (step 524) including the following parameters:
The AMF 522 forwards the information received from the SMF 500 in step 524 towards the (R)AN (e.g., towards the base station 302) by including this information in the N1N2_MessageTransfer message (step 528). The (R)AN (e.g., base station 302) answers with a response indicating successful operation (step 530).
As only N1 SM container is received in step 528 from the AMF 522, the (R)AN (e.g., base station 302) transports only the N1 SM container to the WCD 310 (step 532). The N1 SM container includes the PDU Session Modification Command, which includes at least the PDU Session ID and the ePCO including the DNS parameters. The WCD 310 answers with a response indicating successful operation (step 534). The WCD 310 stores (re-initializes) the DNS parameters (step 536).
Note that the embodiments described herein related to the 5GS 300 are only an example. Similar procedures can be applied in an EPS by replacing:
Now, returning to
Further details regarding establishment of such a subsequent TLS session will now be described. Using the existing solution, when establishing a subsequent TLS session, the stored configuration parameters on the WCD 310 are read and used to initiate the TLS session. One problem is that stored configuration parameters on the WCD 310 have limited guarantees of integrity, and one should refrain from relying on these stored configuration parameters. In order to address this problem as well as to address the problem of ensuring that such subsequent TLS sessions are established to the same (legitimate) DNS resolver 314 as the initial TLS session, in some embodiments, one of the two following mechanisms are used to establish the subsequent TLS session. The first mechanism relies on a TLS 1.3 mechanism known as session resumption based on PSK or PSK-ECDHE authentication. The second mechanism consists of re-doing a TLS handshake using ECDHE authentication. This mechanism assumes that the DNS client 316 supports DNS Security Extensions (DNSSEC), the TLS identity pining extension.
When the DNS client 316 determines that a TLS session to be established not the initial TLS session for the associated PDU session (e.g., determines that the TLS session is not initiated while negotiating a PDU session), the DNS client 316 considers using session resumption where authentication is based on PSK(-ECDHE) authentication with a PSK that is derived from a secret derived in the previous TLS handshake when establishing the initial TLS session. PSK and NewSessionTickets (see, e.g., RFC8446) are of course also stored on the WCD 310, but this information is expected to be managed and access solely by the TLS library and so be associated to a higher level of security. In addition, the TLS handshake using PSK based authentication are 1-Round Trip Time (RTT) and are also expected to be lighter, so the additional security also comes with an additional performance gain.
Identity pinning or DNSSEC validation not supported: In one embodiment, it is assumed that:
Returning to step 702, if the message is not a <ClientHello> message (step 702, NO), the TLS server of the DNS resolver 314 determines whether the received TLS message is indicative of a TLS error (step 712). If so, the process proceeds to step 710 to trigger a PDU session modification. Otherwise, the process proceeds to step 706.
Returning to step 704, if the received message is a <ClientHello> message and PSK or PSK-ECDHE is not proposed, the TLS server of the DNS resolver 314 determines whether a source IP of the received TLS message is in IP_DB (step 714). IP_DB is a database provisioned with assigned IP addresses (i.e., IP addressed assigned for PDU sessions). If so, the source IP is removed from IP_DB (step 716) and the process proceeds to step 706. Otherwise, the process proceeds to step 708.
Identity pinning and DNSSEC validation supported: In one embodiment, it is assumed that:
In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the network node 800 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1100 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.
| Number | Date | Country | Kind |
|---|---|---|---|
| 21382865.0 | Sep 2021 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2021/060936 | 11/24/2021 | WO |
