WO2020041933A1

WO2020041933A1 - Methods and devices for a secure connection

Info

Publication number: WO2020041933A1
Application number: PCT/CN2018/102514
Authority: WO
Inventors: Jiaqi LIU; Daniel Nilsson; Changzheng WU
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-08-27
Filing date: 2018-08-27
Publication date: 2020-03-05

Abstract

A method implemented by a terminal device in a wireless communication network is provided. The method comprises: transmitting a first message including an authentication approach extension associated with an extensible authentication protocol (EAP) to a first network node; receiving a first EAP transfer message carrying an EAP request from the first network node; transmitting a second EAP transfer message carrying a first EAP response to the first network node; and receiving a third EAP transfer message carrying an EAP success from the first network node. Therefore, the TLS mutual authentication with the EAP approach integrated may be simplified.

Description

METHODS AND DEVICES FOR A SECURE CONNECTION

TECHNICAL FIELD

The present disclosure generally relates to a wireless communication network, and more specifically to methods and devices for a secure connection.

BACKGROUND

This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

Transport Layer Security (TLS) may allow a client to establish a secure connection with a server via an encryption/authentication algorithm and key negotiation, in which certificate (s) may be used to authenticate the peer (s) .

Fig. 1 is a sequence diagram illustrating the secure connection between the TLS client and the TLS server. In step 110, in a ClientHello message, the client provides a CipherSuite list supported by itself, a random number to be used to generate a master key, etc. The CipherSuite list is used by the server to determine encryption and integrity algorithms for a record layer and a key exchange scheme.

In step 120, in a ServerHello message, the server responds to the client with a CipherSuite selected from the CipherSuite list, a server-side random number to be used to generate a master key, a certificate (chain) to authenticate the server to the client, a CertificateRequest message (if the server also needs to authenticate the client) , etc.

In step 130, after receiving the ServerHello, the client verifies the certificate of the server. If the server is trustworthy, the client obtains key exchange parameters, generates shared secret keys, and responds to the server with a CertificateVerify message and with a client certificate if requested.

If key exchange and authentication processes are successful, either side will send a Finish message and a ChangeCipherSpec message to the peer, as shown in

steps

130 and 140. Then, a trusted secure channel is set up.

When the TLS is used for a secure connection, for example for Internet of Things (IoT) networks, mutual authentication for the TLS connection may be critical to make sure that right or authenticated things are connected by each other (e.g. both sides of an IoT terminal/gateway and an IoT server) .

Moreover, the TLS may be leveraged for secure data transfer only when the mutual authentication for a user/device to use a TLS tunnel can be performed out of TLS procedures. For example, in the 4 ^th generation (4G) /5 ^th generation (5G) network, especially the Evolved Packet Core (EPC, also known as 4G Core) /5G Core (5GC) network with non-3GPP accesses integrated, Datagram Transport Layer Security (DTLS) may be used or being proposed for the secure data transfer for signaling data (e.g., WLAN Control Protocol (WLCP) messages, Non-Access Stratum (NAS) messages, etc. ) when a user equipment (UE) /network (or the TLS client/server) is mutually authenticated by using 3GPP specific protocols (e.g. Extensible Authentication Protocols (EAPs) ) . For untrusted non-3GPP accesses, the current 4G/5G network may be using Internet Key Exchange (IKE) /IP Security (IPSeC) rather than the TLS as the secure connection approach. However, the secure data transfer is provided by an IPSeC tunnel while authentication for the secure connection is implemented during an IKE security association setup procedure.

With development of the IoT, mutual authentication between the IoT terminal/gateway and the IoT server may be critical to ensure that the right things are connected to a right service provider. The TLS may become a de facto choice for the secure connection.

Since the mutual authentication of the TLS secure connection nowadays relies upon certificates from both sides, it may be cumbersome to install initial certificates on devices, especially for low power and strained IoT terminals in the IoT network when the TLS is used. Currently, there may be no efficient way to verify a real identification which applies a client certificate over the Internet. Therefore, some security critical businesses such as banking may require the client to apply the certificate from their desktop in person with a valid citizen identification. The Public Key Infrastructure (PKI) with full functionality such as certificate revocation, online certificate application, etc. may also be costly.

Even in the 5G era, services such as Session Initiation Protocol (SIP) /IP Multimedia Subsystem (IMS) or HyperText Transfer Protocol (HTTP) services may continue to widely exist in every Information and Communication Technology (ICT) field. However, the services may not be able to carry the EAP close to the application layer even if they may be based on TLS transport. It means that authentication for service accesses cannot utilize an easy EAP approach, even if a communication device at the client side may already have 3 ^rd Generation Partnership Project (3GPP) (Universal Subscriber Identity Module (U/SIM) ) credentials and EAP capability.

In the current 5G network definition for the non-3GPP accesses including trusted non-3GPP accesses and wireline/fixed accesses, pieces of protocol fragments may probably be selected to support the secure connection for the UE/device to connect to the 5G core through the non-3GPP accesses. As stated above, there may be no efficient way of having the TLS as an entire protocol approach to support the secure connection setup for the UE/device when it initiate s registration/connection to the 5G core. One reason is that the current certificate-based authentication architecture in the TLS may not support integration with a 3GPP (U/SIM) credential-based mutual user authentication method (typically via the EAP) . At the same time, the EAP procedure is a multi-round procedure with variant exchanges while the existing TLS certificate authentication procedure may have provided rounds of handshake exchanges.

SUMMARY

It is an object of the present disclosure to provide an EAP-integrated TLS secure connection setup method and device to support an EAP based mutual authentication model in TLS application scenarios where a communication device having (U) SIM/eSIM or 3GPP credentials can establish a TLS secure connection with a communication network. For the 5G/ICT typical services such as IMS or HTTP services, the method and device according to the present disclosure may provide a secure service access by using the TLS with EAP mutual authentication integrated. Particularly, in the 5G network, the method and device according to the present disclosure may further support 5G non-3GPP (N3GPP) accesses for the UE/device to connect to the 5G core through an N3GPP access network.

According to a first aspect of the present disclosure, a method implemented by a terminal device in a wireless communication network is provided. The method comprises: transmitting a first message including an authentication approach extension associated with an extensible authentication protocol (EAP) to a first network node; receiving a first EAP transfer message carrying an EAP request from the first network node; transmitting a second EAP transfer message carrying a first EAP response to the first network node; and receiving a third EAP transfer message carrying an EAP success from the first network node.

In an alternative embodiment of the first aspect, the first message may further include an identification of the terminal device.

In a further alternative embodiment of the first aspect, a first authentication challenge associated with the terminal device may be received as part of the EAP request, and a second authentication challenge associated with the terminal device may be transmitted as part of the first EAP response.

In a yet further alternative embodiment of the first aspect, the method may further comprise, before transmitting the second EAP transfer message to the first network node: if the EAP is associated with a multiple authentication approach, generating a key based on certificate-based key exchange to decrypt the first EAP transfer message, and performing certificate-based authentication; if the EAP is associated with a single authentication approach, generating a key based on a Diffie-Hellman anonymous cipher suite, and decrypting the first EAP transfer message; and verifying the first network node based on the first authentication challenge; and upon success of the verification, the first EAP response having the second authentication challenge may be transmitted to the first network node in the second EAP transfer message.

In another alternative embodiment of the first aspect, a start indicator may be received as part of the EAP request.

In a further alternative embodiment of the first aspect, the first EAP response may include an identification of the terminal device.

In a yet further alternative embodiment of the first aspect, the method may further comprise: after transmitting the second EAP transfer message, receiving at least one subsequent first EAP transfer message each carrying a subsequent EAP request from the first network node; and transmitting at least one subsequent second EAP transfer message each carrying a subsequent EAP response to the first network node.

In another alternative embodiment of the first aspect, the method may further comprise: after receiving the third EAP transfer message, generating a master key using a master session key of the terminal device; calculating verification data based on the generated master key; and transmitting a first finish message including the verification data to the first network node.

In a further alternative embodiment of the first aspect, the master session key may be used as a pre-master secret to generate the master key.

In a still further alternative embodiment of the first aspect, the method may be performed in an environment associated with Transport Layer Security.

According to a second aspect of the present disclosure, a method implemented by a first network node in a wireless communication network is provided. The method comprises: receiving a first message including an authentication approach extension from a terminal device; if the authentication approach extension is associated with an extensible authentication protocol (EAP) , transmitting a first EAP transfer message carrying an EAP request to the terminal device; receiving a second EAP transfer message carrying a first EAP response from the terminal device; and transmitting a third EAP transfer message carrying an EAP success to the terminal device.

According to a third aspect of the present disclosure, a terminal device in a wireless communication network is provided. The terminal device comprises a processor and a memory communicatively coupled to the processor. The memory is adapted to store instructions which, when executed by the processor, cause the terminal device to perform operations of the method of the above first aspect.

According to a fourth aspect of the present disclosure, a first network node in a wireless communication network is provided. The first network node comprises a processor and a memory communicatively coupled to the processor. The memory is adapted to store instructions which, when executed by the processor, cause the first network node to perform operations of the method of the above second aspect.

According to a fifth aspect of the present disclosure, a wireless communication system is provided. The wireless communication system comprises: a terminal device of the above third aspect; and a first network node of the above fourth aspect, communicating with at least the terminal device.

According to a sixth aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon is provided. When the computer program is executed by a set of one or more processors of a terminal device in a wireless communication system, the computer program causes the terminal device to perform operations of the method according to the above first aspect.

According to a seventh aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon is provided. When the computer program is executed by a set of one or more processors of a first network node in a wireless communication system, the computer program causes the first network node to perform operations of the method according to the above second aspect.

In the present disclosure, the TLS mutual authentication with the EAP approach integrated may be simplified. When the EAP approach is deployed in the TLS, it can enable N3GPP accesses (including trusted N3GPP accesses and wireline/fixed accesses) to the 5GC over the TLS and provide an easy way for the secure service accesses for various 5G/ICT services.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be best understood by way of example with reference to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure. In the drawings:

Fig. 1 is a sequence diagram illustrating the secure connection between the TLS client and the TLS server;

Fig. 2 is an exemplary sequence diagram illustrating a secure connection according to some embodiments of the present disclosure;

Fig. 3 is an exemplary sequence diagram illustrating a further secure connection according to some embodiments of the present disclosure;

Fig. 4 is an exemplary block diagram illustrating a secure service access according to some embodiments of the present disclosure;

Fig. 5 is a flow chart illustrating a method implemented on a terminal device according to some embodiments of the present disclosure;

Fig. 6 is a more specific flow chart illustrating a method implemented on a terminal device according to some embodiments of the present disclosure;

Fig. 7 is a flow chart illustrating a method implemented on a first network node according to some embodiments of the present disclosure;

Fig. 8is a more specific flow chart illustrating a method implemented on a first network node according to some embodiments of the present disclosure;

Fig. 9 is a block diagram illustrating a terminal device according to some embodiments of the present disclosure;

Fig. 10 is another block diagram illustrating a terminal device according to some embodiments of the present disclosure;

Fig. 11 is a block diagram illustrating a first network node according to some embodiments of the present disclosure;

Fig. 12 is another block diagram illustrating a first network node according to some embodiments of the present disclosure; and

Fig. 13 is a block diagram illustrating a wireless communication system according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

The following detailed description describes methods and devices for a secure connection in a wireless communication network. In the following detailed description, numerous specific details such as logic implementations, types and interrelationships of system components, etc. are set forth in order to provide a more thorough understanding of the present disclosure. It should be appreciated, however, by one skilled in the art that the present disclosure may be practiced without such specific details. In other instances, control structures, circuits and instruction sequences have not been shown in detail in order not to obscure the present disclosure. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to “one embodiment” , “an embodiment” , “an example embodiment” etc. indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the present disclosure. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the present disclosure.

In the following detailed description and claims, the terms “coupled” and “connected, ” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, cooperate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

As used herein, the terms “first” , “second” and so forth refer to different elements. The singular forms “a” and “an” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” as used herein, specify the presence of stated features, elements, and/or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

The term “terminal device” refers to any end device/client that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device may refer to a mobile terminal, a user equipment (UE) , or other suitable devices. The UE may be, for example, a subscriber station, a portable subscriber station, a mobile station (MS) or an access terminal (AT) . The terminal device may include, but not limited to, portable computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, a mobile phone, a cellular phone, a smart phone, a tablet, a wearable device, a personal digital assistant (PDA) , a vehicle, and the like. In the following description, the terms “terminal device” , “client” and “UE” may be used interchangeably.

The present disclosure provides an EAP-integrated TLS secure connection setup method and device to support an EAP based mutual authentication model in TLS application scenarios. Particularly, in the 5G network, the method and device according to the present disclosure may further support 5G non-3GPP (N3GPP) accesses for the UE/device to connect to the 5G core through an N3GPP access network.

The EAP procedures may be performed between an EAP client (in the communication device) and an authentication server (which terminates the EAP if any) while a TLS server may act as an authenticator. Specifically, in the 5G N3GPP access case, the EAP may be terminated in the TLS server (rather than being terminated in the authentication server) and NAS signaling of 5G registration and user authentication may be transferred through EAP over TLS between the UE/TLS client and the access gateway which may take a role of the TLS server.

In a ClientHello message transmitted from the TLS client, new extensions may be added. One new extension may be named “Client ID” , which may allow the TLS client to signal its identification to the TLS server. Another new extension may be named “AUTH METHOD” , which may indicate to the server whether EAP based authentication is to be carried out or not. The TLS server may refer to an authentication server based on the identification to perform EAP based authentication, e.g., related to EAP AKA (Authentication and Key Agreement) , EAP AKA′ (Authentication and Key Agreement Prime) , EAP SIM (Subscriber Identity Module) , etc. The identification may be a unique ID for the client which is recognizable for the authentication server, such as a Network Access Identifier (NAI) .

If the AUTH METHOD is set as EAP-integrated, a CipherSuite in the ClientHello message should contain only suites of a Diffie-Hellman (DH) anonymous category or of a certificate category in the case that certificate-based authentication may be performed in parallel. Otherwise, if the AUTH METHOD is set as a value other than the EAP-integrated, or the ClientHello message has no extension of “Client ID” or no extension of “AUTH METHOD” , the EAP-integrated TLS secure connection setup method will not be implemented.

As the EAP procedure may take multiple rounds of message exchange, and none of the existing messages is suitable to convey EAP messages between the TLS client and the TLS server, a new message may be defined for such a purpose, that is “EAP_transfer” . This new message may be used to exchange EAP payloads between the TLS client and the TLS server along with or after a ServerHello message transmitted from the TLS server.

After the EAP procedure finishes, an EAP success may be transmitted to the client, and a Master Session Key (MSK) generated at the TLS client (which may act as an authentication client) or an MSK transmitted from the authentication server to the TLS server (which may act as an authenticator) may be used to generate a master key for a record layer. The TLS client and the TLS server may transmit ChangeCipherSpec to each other. The mutual authentication may be achieved, without a need of certificates if only a single authentication method is needed, or with a need of certificates if a multiple authentication method is needed.

When the EAP is terminated in the authentication server, a protocol between the TLS server and the authentication server may be any protocol that can carry an EAP payload, such as Diameter or RADIUS.

When the EAP is terminated in the TLS server (i.e., does not exist between the TLS server and the authentication server) , particularly in the 5G N3GPP access case where NAS signaling of 5G registration and user authentication may be transferred through EAP over TLS between the UE/TLS client and the access gateway/TLS server, a protocol between the access gateway/TLS server and the authentication server (AUSF) may be via an Access and Mobility Management Function (AMF) as an intermediate node where N2 may be used to carry the NAS signaling of 5G registration and user authentication.

The method and device according to the present disclosure are implemented in an environment of the TLS by way of example, but also applied to e.g. the DTLS.

Fig. 2 is an exemplary sequence diagram illustrating TLS mutual authentication with EAP payloads according to some embodiments of the present disclosure. In this scenario, assuming that a TLS client has knowledge of what EAP mutual authentication method should be used to perform authentication and key generation for the TLS setup and which TLS server should act as an authenticator for the EAP procedures.

In step 210, a device or TLS client 201may transmit a ClientHello message to an access gateway of TLS server 202, including at least a CipherSuite list supports by the TLS client 201 and a client-side random number to be used to generate a master key. In order to enable the EAP based authentication, a new extension may be added to indicate to the server an identification of the TLS client 201, and may be named “Client ID” . Moreover, in order to allow the TLS client 201 to signal to the TLS server 202 how to perform the EAP based authentication explicitly, another new extension “AUTH METHOD” may be added to indicate an authentication method.

The encoding of "Client ID" may be:

enum {

signature_algorithms (13) , client_id (TBD) , (65535)

}ExtensionType;

The value of "Client ID" may be registered in the Internet Assigned Numbers Authority (IANA) and to be determined. For instance, the content of "Client ID" may be defined as:

The encoding of "AUTH METHOD" may be:

The value of "AUTH METHOD" may also be registered in the IANA and also to be determined. For instance, the content of "AUTH METHOD" may be defined as:

The value “eap_integrated (255) ” means that the EAP method may be used to authenticate the TLS client 201, hence the CipherSuite should be of the DH anonymous category or of the certificate category in the case that the certificate-based authentication may be performed in parallel.

When the TLS server 202 receives the ClientHello including the extensions of "Client ID" and "AUTH METHOD" , it may select an appropriate authenticator server 203 based on information of the "Client ID" to perform the EAP based authentication. In step 220, the TLS server 202 may transmit an authentication request to the selected authentication server 203, carrying an EAP response. The "Client ID" may be a payload of this EAP response.

In step 230, the authentication server 203 may calculate a first authentication challenge for the TLS client 201 and respond back to the TLS server 202 with an authentication response carrying an EAP request which has the first authentication challenge as a payload. In an example, the first authentication challenge may be an AKA challenge, an AKA′challenge, a SIM challenge, etc. EPA/AKA is shown herein by way of example.

Before initiating the EAP request/AKA challenge (as a payload) message, the authentication server 203 may also transmit an EAP request/Client ID message to the TLS client 201 to retrieve again a more complete version of the identification of the TLS client 201 through an EAP message.

In step 240, the TLS server 202 may construct a ServerHello message including at least the selected CipherSuite, a server-side random number, etc., as well as Certificate, ServerKeyExchange and CertificateRequest if necessary. A new type of message may be created to help communicate the EAP request/AKA from the authentication server 203 to the TLS client 201, i.e., the "EAPTransfer" message for conveying EAP payloads between the TLS client 201 and the TLS server 202, until an EAP success or an EAP failure happens. This EAPTransfer message should be transmitted to the TLS client 201 along with the ServerHello message.

Specifically, the EAPTransfer message may be defined as:

The HandshakeType value for eap_transfer may also be registered in the IANA and to be determined. The content of the message may be defined as:

struct {

opaqueeap_payload<4..2^16-1>;

}EAPTransfer;

In step 250, the TLS client 201 may perform server hello key exchange, in which if the EAP is associated with a multiple authentication approach, the TLS client 201 may generate a key based on certificate-based key exchange to decrypt/encrypt the EAPtransfer message, and perform certificate-based authentication, and if the EAP is associated with a single authentication approach, the TLS client 201 may generate a key based on a DH anonymous CipherSuite and encrypt/decrypt the EAPTransfer message. After this, the TLS client 201 may verify the TLS server 202 based on the received AKA challenge. If the verification of the TLS server 202 succeeds, the TLS client 201 may respond an EAP response having a second authentication challenge associated with the TLS client 201 to the TLS server 202 via another EAPTransfer message, together with and at the end of a handshake message. In an example, the second authentication challenge may be an AKA challenge, an AKA′challenge, a SIM challenge, etc. EPA/AKA is shown herein by way of example.

In step 260, the TLS server 202 may relay the EAP response/AKA challenge to the authentication server 203 in an authentication request.

In step 270, the authentication server 203 may verify the TLS client 201 based on the EAP response/AKA challenge. If the verification succeeds, the authentication server 203 may response an EAP success/MSK to the TLS server 202 in an authentication response.

The TLS server 202 may use the MSK to generate a master key for TLS message authentication. In an example, the MSK may be used as a pre_master_secret, and the master key may be generated from the pre_master_secret. In step 280, the TLS server 202 may relay the EAP success to the TLS client 201 via an EAPTransfer message along with a ServerHelloDone message indicating the Handshake procedure is done. At the TLS server 202, the EAP procedure is finished when the EAP success is transmitted.

Generation of the master secret may be as follows:

master_secret = PRF (pre_master_secret, "master secret" , ClientHello. random + ServerHello. random)

[0..47] ;

The pre_master_secret for the TLS is derived from the MSK.

After receiving the EAP success, the TLS client 201 may use its own MSK to generate a master key, calculate verification data based on the generated master key, and respond ChangeCipherSpec and a first Finish message which includes its calculated verification data to the TLS server 202 in step 290. The generated master key is only used for authentication data calculation but not for overriding the existing master secret being used for the TLS session.

After receiving the ChangeCipherSpec and the first Finish message from the TLS client 201, the TLS server 202 may verify the received Finish message based on its generated master key. If the verification succeeds, the TLS server 202 may calculate verification data based on its generated master key, and respond ChangeCipherSpec and a second Finish message which includes its calculated verification data to the TLS client 201. The TLS server 202 should use the same method as the TLS client 201 to generate the master key.

At this point, the mutually trusted secure tunnel is set up.

In this way, the mutual authentication between the TLS client and the TLS server may be an inherent design of the AKA. Therefore, cumbersome efforts to install initial certificates on the IoT terminal and thus the PKI that issues/revokes the certificates may be eliminated. The AKA uses different authentication than the certificate, increasing accountability as multiple authentications become important in some application scenarios, such as mission critical use cases.

Fig. 3 is an exemplary sequence diagram illustrating EAP-integration procedures for a 5G secure connection according to some embodiments of the present disclosure. In the 5G system, a 3GPP specific EAP method called EAP-5G may be used to register non-3GPP accesses to the 5G core. When the EAP method is integrated into the TLS, the EAP-5G method may be enabled in a similar way as the EAP AKA. Therefore, the EAP-integrated TLS may be used for 5G registration for non-3GPP accesses including trusted N3GPP accesses and wireline/fixed accesses. The EAP-5G may be used to transport NAS signaling of 5G registration and user authentication, and be terminated in a non-3GPP access gateway, i.e., N3IWF (Non-3GPP InterWorking Function) 302 as shown in Fig. 3, which may also take a role of the TLS server.

In step 1, a UE 301 which acts as a TLS client may transmit a ClientHello to the N3IWF 302. From the ClientHello message, the N3IWF 302 may be aware of the EAP-integrated TLS method is to be implemented e.g., the AUTH_METHOD included in the ClientHello message has the value of EAP-integrated. At this point, instead of expecting the Client ID to be discovered from the message, the N3IWF 302 may initiate EAP-5G procedures by transmitting to the UE 301 a start indicator, e.g., a 5G-start, as a payload of an EAP-request which is carried in a TLS EAPTransfer message in step 2. There may be other TLS messages such as a ServerHello message transmitted together with the EAPTransfer message to the UE 301

In step 3, the UE 301 may transmit a further EAPTransfer message which carries an EAP response/5G-NAS having at least some parameters as payloads to the N3IWF 302. The parameters may include an identification of the UE 301, such as a SUCI (SUbscription Concealed Identifier) , 5G-GUTI (5G Globally Unique Temporary Identity) , etc. The identification may be used as a Client ID for an intermediate node AMF 302’to select an authentication server (AUSF) 303 in step 4c.

The steps subsequent to step 3 till step 8a may constitute 5G registration and user authentication procedures as defined in the 3GPP, except that at least one EAP request and at least one EAP response may be included in TLS EAPTransfer messages conveyed between the UE 301 and the N3IWF 302, and may have various types of payloads. The EAP is terminated in the N3IWF 302, i.e., it does not exist between the N3IWF 302 and the AUSF 303.

An Access Stratum (AS) key may be transmitted from the AUSF 303 to the N3IWF 302 as the MSK shown in Fig. 2.

Steps

8b, 9a and 9b are similar to

steps

280, 290 and 295 of Fig. 2 respectively and will not be described herein in detail.

Steps

10 and 11 may be performed between the N3IWF 302 and the AMF 302′for initial context setup and NAS registration accept.

After step 12, the 5G NAS signaling can be transferred over a secure TLS tunnel.

Fig. 4 is an exemplary block diagram illustrating a secure service access according to some embodiments of the present disclosure. The secure service access may be provided by using the EAP-integrated TLS method where mutual authentication may be based on the integrated EAP, especially when a communication device 401 at the client side already has 3GPP (U/SIM) credentials and EAP capability.

As shown in Fig. 4, a service client 411 and a TLS client 413 of the communication device 401, a TLS server 422 of a service/access gateway 402, and an application server 404 may communicate on a service flow, and an EAP client 412 and the TLS client 413 of the communication device 401, an EAP authenticator 421 and the TLS server 422 of the service/access gateway 402, and an authentication server 403 may communicate on an EAP authentication flow. In an example, the service/access gateway 402 may be integrated with the application server 404.

Moreover, in the 5G/ICT era, services such SIP/IMS or HTTP services may or may not have the TLS as secure transport.

Fig. 5 is a flow chart illustrating a method 500 implemented on a terminal device according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by the terminal device, such as the client 201 as shown in Fig. 2 or the UE 301 as shown in Fig. 3 but not limited thereto. The operations in this and other flow charts will be described with reference to the exemplary embodiments of the other figures. However, it should be appreciated that the operations of the flow charts may be performed by embodiments of the present disclosure other than those discussed with reference to the other figures, and the embodiments of the present disclosure discussed with reference to these other figures may perform operations different than those discussed with reference to the flow charts.

In one embodiment, the method 500 begins with the terminal device transmitting a first message including an authentication approach extension associated with an EAP to a first network node (block 501) . As an example, the first network node may be the server 202 as shown in Fig. 2 or the N3IWF 302 as shown in Fig. 3, but it is not limited thereto.

The terminal device may receive a first EAP transfer message carrying an EAP request from the first network node (block 502) . Then, the terminal device may transmit a second EAP transfer message carrying an EAP response to the first network node (block 503) . Finally, the terminal device may receive a third EAP transfer message carrying an EAP success from the first network node (block 504) .

In one embodiment, the method 500 may be performed in a TLS environment.

Fig. 6 is a more specific flow chart illustrating a method 600 implemented on a terminal device according to some embodiments of the present disclosure. As an example, the terminal device may be the client 201 as shown in Fig. 2 or the UE 301 as shown in Fig. 3 but not limited thereto.

In one embodiment, the client 201/UE 301 may transmit a first message including an authentication approach (e.g., AUTH METHOD) extension associated with an EAP to a first network node (block 601) . As an example, the first network node may be the server 202 as shown in Fig. 2 or the N3IWF 302 as shown in Fig. 3, but it is not limited thereto. As an example, the first message may be a ClientHello message.

In the case of e.g. EAP/AKA procedures as shown in Fig. 2, the first message may include an identification of the client 201. As an example, the client 201 may receive a first authentication challenge associated with the client 201 from the server 202 as a payload of an EAP request carried in a first EAP transfer message (block 602) . As a further example, the first authentication challenge may be an AKA challenge, an AKA′challenge, a SIM challenge or the like.

As an optional example, if that the EAP is associated with a multiple authentication approach, the client 201 may generate a key based on certificate-based key exchange to decrypt the received first EAP transfer message (block 603) , and perform certificate-based authentication (block 604) . Instead, in the case of a single authentication approach, the client 201, the client 201 may generate a key based on a DH anonymous cipher suite (block 605) , and decrypt the received first EAP transfer message (block 606) . Then, the client 201 may verify the server 202 based on the first authentication challenge (block 607) . If the verification of the server is successful, the client 201 may transmit a second EAP transfer message carrying an EAP response which has a second authentication challenge associated with the client 201 as a payload to the server 202 (block 608) . As a further example, the second authentication challenge may be an AKA challenge, an AKA′challenge, a SIM challenge or the like.

In the case of e.g. EAP-5G procedures as shown in Fig. 3, the UE 301 may receive a start indicator, e.g., a 5G-start, from the N3IWF 302, as a payload of an EAP request which is carried in a first EAP transfer message (block 609) . The UE 301 may transmit a second EAP transfer message to the N3IWF 302, carrying an EAP response which has an identification of the UE 301 as a payload, such as a SUCI, 5G-GUTI, etc (block 610) .

In one embodiment, the UE 301 may receive at least one first EAP transfer message from the N3IWF 302, each of which carries an EAP request (block 611) . In response to each EAP transfer message, the UE 301 may transmit a second EAP transfer message carrying an EAP response (block 612) .

In both cases, the client 201/UE 301 may receive a third EAP transfer message carrying an EAP success from the server 202/N3IWF 302 (block 613) .

As an example, the client 201/UE 301 may generate a master key using its own master session key (block 614) , calculate verification data based on the generated master key (block 615) , and then transmit a finish message including the verification data to the server 202/N3IWF 302 (block 616) . As a further example, the master key may be generated from a pre-master secret derived from the master session key.

In one embodiment, the method 600 may be performed in a TLS environment.

Fig. 7 is a flow chart illustrating a method 700 implemented on a first network node according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by the server 202 as shown in Fig. 2 or the N3IWF 302 as shown in Fig. 3, but it is not limited thereto.

In one embodiment, the method 700 begins with the first network node receiving a first message including an authentication approach extension from a terminal device (block 701) . As an example, the terminal device may be the client 201 as shown in Fig. 2 or the UE 301 as shown in Fig. 3, but it is not limited thereto.

If the authentication approach extension is associated with an EAP, the first network node may transmit a first EAP transfer message carrying an EAP request to the terminal device (block 702) . Then, the first network node may transmit a second EAP transfer message carrying an EAP response from the terminal device (block 703) . Finally, the first network node may transmit a third EAP transfer message carrying an EAP success from to terminal device (block 704) .

In one embodiment, the method 700 may be performed in a TLS environment.

Fig. 8 is a more specific flow chart illustrating a method 800 implemented on a first network node according to some embodiments of the present disclosure. As an example, the first network node may be the server 202 as shown in Fig. 2 or a combination of the N3IWF 302 with the AMF 302′as shown in Fig. 3 but not limited thereto.

In one embodiment, the server 202/N3IWF 302 may receive a first message including an authentication approach (e.g., AUTH METHOD) extension from a terminal device (block 801) . As an example, the terminal device may be the client 201 as shown in Fig. 2 or the UE 301 as shown in Fig. 3, but it is not limited thereto. As an example, the first message may be a ClientHello message.

In the case of e.g. EAP/AKA procedures as shown in Fig. 2, the first message may include an identification of the client 201. The server 202 may select a second network node based on the identification of the client 201 (block 802) . As an example, the second network node may be the authentication server 203 as shown in Fig. 2.

As an optional example, if the authentication approach extension of the first message is associated with an EAP, the server 202 may transmit an EAP response having the identification of the client 201 as a payload to the selected authentication server 203 (block 803) , and receive an EAP request having a first authentication challenge associated with the client 201 from the selected authentication server 203 (block 804) . As a further example, the first authentication challenge may be an AKA challenge, an AKA′challenge, a SIM challenge or the like.

As an optional example, the server 202 may transmit a first EAP transfer message carrying an EAP request which has the received first authentication challenge as a payload to the client 201 (block 805) , and receive a second EAP transfer message carrying an EAP response which has a second authentication challenge as a payload from the client 201 (block 806) . As a further example, the second authentication challenge may be an AKA challenge, an AKA′challenge, a SIM challenge or the like.

In the case of e.g. EAP-5G procedures as shown in Fig. 3, if the authentication approach extension of the first message is associated with an EAP, the N3IWF 302 may transmit a start indicator, e.g., a 5G-start, to the UE 301, as a payload of an EAP request which is carried in a first EAP transfer message (block 807) . The N3IWF 302 may receive a second EAP transfer message from the UE 301, carrying an EAP response which has an identification of the UE 301 as a payload, such as a SUCI, 5G-GUTI, etc (block 808) . The AMF 302′may select a second network node based on the identification of the UE 301 (block 809) . As an example, the second network node may be the AUSF 303 as shown in Fig. 3.

In one embodiment, the N3IWF 302 may transmit at least one first EAP transfer message to the UE 301, each of which carries an EAP request (block 810) , and may receive a second EAP transfer message carrying an EAP response to each EAP request from the UE 301 (block 811) .

In both cases, the server 202/N3IWF 302 may transmit a third EAP transfer message carrying an EAP success to the client 201/UE 301 (block 812) .

As an example, the server 202/N3IWF 302 may generate a master key using a master session key received from the selected authentication server 203/AUSF 303 (block 813) . After receiving a finish message from the client 201/UE 301, the server 202/N3IWF 302 may verify the received finish message based on the generated master key (block 814) , and if the verification succeeds, calculate verification data based on the generated master key (block 815) , and transmit a further finish message including the verification data to the client 201/UE 301 (block 816) . As a further example, the master key may be generated from a pre-master secret derived from the master session key.

In one embodiment, the method 800 may be performed in a TLS environment.

Fig. 9 is a block diagram illustrating a terminal device 900 according to some embodiments of the present disclosure. As an example, the terminal device 900 may be the client 201 as shown in Fig. 2 or the UE 301 as shown in Fig. 3, but it is not limited thereto. It should be appreciated that the terminal device 900 may be implemented using components other than those illustrated in Fig. 9.

With reference to Fig. 9, the terminal device 900 may comprise at least a processor 901, a memory 902, a network interface 903 and a communication medium 904. The processor 901, the memory 902 and the network interface 903 may be communicatively coupled to each other via the communication medium 904.

The processor 901 may include one or more processing units. A processing unit may be a physical device or article of manufacture comprising one or more integrated circuits that read data and instructions from computer readable media, such as the memory 902, and selectively execute the instructions. In various embodiments, the processor 901 may be implemented in various ways. As an example, the processor 901 may be implemented as one or more processing cores. As another example, the processor 901 may comprise one or more separate microprocessors. In yet another example, the processor 901 may comprise an application-specific integrated circuit (ASIC) that provides specific functionality. In still another example, the processor 901 may provide specific functionality by using an ASIC and/or by executing computer-executable instructions.

The memory 902 may include one or more computer-usable or computer-readable storage medium capable of storing data and/or computer-executable instructions. It should be appreciated that the storage medium is preferably a non-transitory storage medium.

The network interface 903 may be a device or article of manufacture that enables the terminal device 900 to send data to or receive data from other network nodes. In different embodiments, the network interface 903 may be implemented in different ways. As an example, the network interface 903 may be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., Wi-Fi, WiMax, etc. ) , or another type of network interface.

The communication medium 904 may facilitate communication among the processor 901, the memory 902 and the network interface 903. The communication medium 904 may be implemented in various ways. For example, the communication medium 904 may comprise a Peripheral Component Interconnect (PCI) bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing System Interface (SCSI) interface, or another type of communications medium.

In the example of Fig. 9, the instructions stored in the memory 902 may include those that, when executed by the processor 901, cause the terminal device 900 to implement the method described with respect to Fig. 5 or 6.

Fig. 10 is another block diagram illustrating a terminal device 1000 according to some embodiments of the present disclosure. As an example, the terminal device 1000 may be the client 201 as shown in Fig. 2 or the UE 301 as shown in Fig. 3, but it is not limited thereto. It should be appreciated that the terminal device 1000 may be implemented using components other than those illustrated in Fig. 10.

With reference to Fig. 10, the terminal device 1000 may comprise at least a transmission unit 1001 and a receiving unit 1002. The transmission unit 1001 may be adapted to perform at least the operations described in

blocks

501 and 503 of Fig. 5 and in

blocks

601, 608, 610, 612 and 616 of Fig. 6. The receiving unit 1002 may be adapted to perform at least the operations described in

blocks

502 and 504 of Fig. 5 and in

blocks

602, 609, 611 and 613 of Fig. 6.

In one embodiment, the terminal device 1000 may further comprise at least a key generation unit 1003, a decryption unit 1004, a verification unit 1005 and a calculation unit 1006. The key generation unit 1003 may be adapted to perform at least the operations described in

blocks

603, 605 and 614 of Fig. 6. The decryption unit 1004 may be adapted to perform at least the operation described in block 606 of Fig. 6. The verification unit 1005 may be adapted to perform at least the operations described in blocks 604 and 607 of Fig. 6. The calculation unit 1006 may be adapted to perform at least the operation described in block 615 of Fig. 6.

Fig. 11 is a block diagram illustrating a first network node 1100 according to some embodiments of the present disclosure. As an example, the first network node 1100 may be the server 202 as shown in Fig. 2 or a combination of the N3IWF 302 with the AMF 302′as shown in Fig. 3 but it is not limited thereto. It should be appreciated that the first network node 1100 may be implemented using components other than those illustrated in Fig. 11.

With reference to Fig. 11, the first network node 1100 may comprise at least a processor 1101, a memory 1102, a network interface 1103 and a communication medium 1104. The processor 1101, the memory 1102 and the network interface 1103 may be communicatively coupled to each other via the communication medium 1104.

The processor 1101, the memory 1102, the network interface 1103 and the communication medium 1104 are structurally similar to the processor 901, the memory 902, the network interface 903 and the communication medium 904 respectively, and will not be described herein in detail.

In the example of Fig. 11, the instructions stored in the memory 1102 may include those that, when executed by the processor 1101, cause the first network node 1100 to implement the method described with respect to Fig. 7 or 8.

Fig. 12 is another block diagram illustrating a first network node 1200 according to some embodiments of the present disclosure. As an example, the first network node 1200 may be the server 202 as shown in Fig. 2 or a combination of the N3IWF 302 with the AMF 302′as shown in Fig. 3, but it is not limited thereto. It should be appreciated that the first network node 1200 may be implemented using components other than those illustrated in Fig. 12.

With reference to Fig. 12, the first network node 1200 may comprise at least a receiving unit 1201 and a transmission unit 1202. The receiving unit 1201 may be adapted to perform at least the operations described in

blocks

701 and 703 of Fig. 7 and in

blocks

801, 804, 806, 808 and 811 of Fig. 8. The transmission unit 1202 may be adapted to perform at least the operations described in

blocks

702 and 704 of Fig. 7 and in

blocks

803, 805, 807, 810, 812 and 816 of Fig. 8.

In one embodiment, the first network device 1200 may further comprise at least a selecting unit 1203, a key generation unit 1204, a verification unit 1205 and a calculation unit 1206. The selecting unit 1203 may be adapted to perform at least the operations described in

blocks

802 and 809 of Fig. 8. The key generation unit 1204 may be adapted to perform at least the operation described in block 813 of Fig. 8. The verification unit 1205 may be adapted to perform at least the operation described in block 814 of Fig. 8. The calculation unit 1206 may be adapted to perform at least the operation described in block 815 of Fig. 8.

The units 1001-1006 and 1201-1206 are illustrated as separate units in Figs. 10 and 12. However, this is merely to indicate that the functionality is separated. The units may be provided as separate elements. However, other arrangements are possible, e.g., some of them may be combined as one unit in each figure. Any combination of the units may be implemented in any combination of software, hardware, and/or firmware in any suitable location. For example, there may be more controllers configured separately, or just one controller for all of the components.

The units shown in Figs. 10 and 12 may constitute machine-executable instructions embodied within a machine, e.g., readable medium, which when executed by a machine will cause the machine to perform the operations described. Besides, any of these units may be implemented as hardware, such as an application specific integrated circuit (ASIC) , Digital Signal Processor (DSP) , Field Programmable Gate Array (FPGA) or the like.

Moreover, it should be appreciated that the arrangements described herein are set forth only as examples. Other arrangements (e.g., more controllers or more detectors, etc. ) may be used in addition to or instead of those shown, and some units may be omitted altogether. Functionality and cooperation of these units are correspondingly described in more detail with reference to Figs. 5-8.

Fig. 13 is a block diagram illustrating a wireless communication system 1300 according to some embodiments of the present disclosure. The wireless communication system 1300 may comprise at least a terminal device 1301 and a first network node 1302 communicating with each other.

As an example, the terminal device 1301 may act as the terminal device 900 as depicted in Fig. 9 or the terminal device 1000 as depicted in Fig. 10, and the first network node 1302 may act as the first network node 1100 as depicted in Fig. 11 or the first network node 1200 as depicted in Fig. 12.

Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be appreciated, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to actions and processes of a computer system, or a similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system′s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments of the present disclosure are not described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the present disclosure as described herein.

An embodiment of the present disclosure may be an article of manufacture in which a non-transitory machine-readable medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor” ) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines) . Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

In the foregoing detailed description, embodiments of the present disclosure have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the spirit and scope of the present disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Throughout the description, some embodiments of the present disclosure have been presented through flow diagrams. It should be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended as a limitation of the present disclosure. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams without departing from the spirit and scope of the present disclosure as set forth in the following claims.

Claims

A method (500) implemented by a terminal device in a wireless communication network, the method comprising:

transmitting (501, 601) a first message including an authentication approach extension associated with an extensible authentication protocol (EAP) to a first network node;

receiving (502) a first EAP transfer message carrying an EAP request from the first network node;

transmitting (503) a second EAP transfer message carrying a first EAP response to the first network node; and

receiving (504, 613) a third EAP transfer message carrying an EAP success from the first network node.
The method of Claim 1, wherein the first message further includes an identification of the terminal device.
The method of Claim 2, wherein a first authentication challenge associated with the terminal device is received (602) as part of the EAP request, and a second authentication challenge associated with the terminal device is transmitted (608) as part of the first EAP response.
The method of Claim 3, further comprising, before transmitting the second EAP transfer message to the first network node:

if the EAP is associated with a multiple authentication approach,

generating (603) a key based on certificate-based key exchange to decrypt the first EAP transfer message, and

performing (604) certificate-based authentication;

if the EAP is associated with a single authentication approach,

generating (605) a key based on a Diffie-Hellman anonymous cipher suite, and

decrypting (606) the first EAP transfer message; and

verifying (607) the first network node based on the first authentication challenge, and

wherein upon success of the verification, the first EAP response having the second authentication challenge are transmitted (608) to the first network node in the second EAP transfer message.
The method of Claim 1, wherein a start indicator is received (609) as part of the EAP request.
The method of Claim 5, wherein the first EAP response includes an identification of the terminal device.
The method of Claim 5 or 6, further comprising:

after transmitting the second EAP transfer message, receiving (611) at least one subsequent first EAP transfer message each carrying a subsequent EAP request from the first network node; and

transmitting (612) at least one subsequent second EAP transfer message each carrying a subsequent EAP response to the first network node.
The method of any of Claims 1 to 7, further comprising:

after receiving the third EAP transfer message, generating (614) a master key using a master session key of the terminal device;

calculating (615) verification data based on the generated master key;

transmitting (616) a first finish message including the verification data to the first network node.
The method of Claim 8, wherein the master session key is used as a pre-master secret to generate the master key.
The method of any of Claims 1 to 9, wherein the method is performed in an environment associated with Transport Layer Security.
A method (700) implemented by a first network node in a wireless communication network, the method comprising:

receiving (701, 801) a first message including an authentication approach extension from a terminal device;

if the authentication approach extension is associated with an extensible authentication protocol (EAP) , transmitting (702) a first EAP transfer message carrying an EAP request to the terminal device;

receiving (703) a second EAP transfer message carrying a first EAP response from the terminal device; and

transmitting (704, 812) a third EAP transfer message carrying an EAP success to the terminal device.
The method of Claim 11, wherein the first message further includes an identification of the terminal device, and wherein the method further comprises:

selecting (802) a second network node based on the identification of the terminal device.
The method of Claim 12, further comprising, before transmitting the first EAP transfer message to the terminal device:

transmitting (803) a second EAP response including the identification of the terminal device to the selected second network node; and

receiving (804) the EAP request including a first authentication challenge associated with the terminal device from the selected second network node.
The method of Claim 13, wherein the first authentication challenge is transmitted (805) to the terminal device as part of the EAP request carried in the first EAP transfer message, and a second authentication challenge is received (806) from the terminal device as part of the first EAP response carried in the second EAP transfer message.
The method of Claim 11, wherein a start indicator is transmitted (807) as part of the EAP request.
The method of Claim 15, wherein the first EAP response includes an identification of the terminal device, and wherein the method further comprises:

selecting (809) a second network node based on the identification of the terminal device.
The method of Claim 16, further comprising:

after communicating with the selected second network node, transmitting (810) at least one subsequent first EAP transfer message each carrying a subsequent EAP request to the terminal device; and

receiving (811) at least one subsequent second EAP transfer message each carrying a subsequent EAP response from the terminal device.
The method of any of Claims 11 to 17, wherein a cipher suite of the first message contains suites of a Diffie-Hellman anonymous category or suites of a certificate category in which certificated based authentications are performed in parallel.
The method of any of Claims 11 to 18, further comprising:

generating (813) a master key using a master session key received from the selected second network node;

after receiving a first finish message from the terminal device, verifying (814) the first finish message based on the generated masker key;

when the verification succeeds, calculating (815) verification data based on the generated master key; and

transmitting (816) a second finish message including the verification data to the terminal device.
The method of Claim 19, wherein the master session key is used as a pre-master secret to generate the master key.
The method of any of Claims 11 to 20, wherein the method is performed in an environment associated with Transport Layer Security.
A terminal device (900) in a wireless communication network, comprising:

a processor (901) ; and

a memory (902) communicatively coupled to the processor and adapted to store instructions which, when executed by the processor, cause the terminal device to perform operations of the method of any of Claims 1 to 10.
A first network node (1100) in a wireless communication network, comprising:

a processor (1101) ; and

a memory (1102) communicatively coupled to the processor and adapted to store instructions which, when executed by the processor, cause the first network node to perform operations of the method of any of Claims 11 to 21.
A wireless communication system (1300) , comprising:

a terminal device (1301) of Claim 22; and

a first network node (1302) of Claim 23, communicating with at least the terminal device.
A non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a terminal device in a wireless communication network, causes the terminal device to perform operations of the method of any of Claims 1 to 10.
A non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a first network node in a wireless communication network, causes the first network node to perform operations of the method of any of Claims 11 to 21.