WO2020094475A1

WO2020094475A1 - Authentication and key agreement for a terminal device

Info

Publication number: WO2020094475A1
Application number: PCT/EP2019/079646
Authority: WO
Inventors: Patrik Salmela; Mohit SETHI; Vesa Lehtovirta; Vesa Torvinen
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-11-05
Filing date: 2019-10-30
Publication date: 2020-05-14

Abstract

A procedure for an Authentication and Key Agreement AKA, for a terminal device (160) is performed by an application server (200) and a key management server (300). The key management server authenticates the terminal device using Extensible Authentication Protocol, EAP, signalling during a bootstrapping session, and obtains binding information relating to the bootstrapping session from the application server. Further, the key management server obtains and stores a first key to be used as root key and derives a second key for the application server from the first key, and also based on the binding information provided to the key management server by the application server.

Description

AUTHENTICATION AND KEY AGREEMENT

FOR A TERMINAL DEVICE

TECHNICAL FIELD

Embodiments presented herein relate to methods, an application server, a key management server, computer programs, and a computer program product for authentication and key agreement for a terminal device.

BACKGROUND

As described in 3GPP TS 33.220 the Generic Bootstrapping Architecture (GBA) allows devices with 3GPP credentials to authenticate themselves to the mobile network operator and also set up shared secrets/keys with other application servers on the Internet (called Network Application Function (NAF) in 3GPP terminology). Essentially, GBA provides authentication and keys for application security based on 3GPP subscription credentials.

In principle, GBA can be used to protect any application traffic, e.g. with Transport Layer Security (TLS), as GBA provides shared keys for applications to use. Using shared keys avoids the need for complex calculations of asymmetric crypto and the need for verifying certificate chains and checking revocation lists. Instead, GBA relies on the security infrastructure of the mobile network operator. Even though GBA re-uses the credentials stored on the Universal Integrated Circuit Card in the user equipment (UE), the use of GBA does not require mobile network access but requires only Internet protocol (IP) connectivity to the mobile network operator infrastructure. As the credentials of the UICC are used by GBA, there is no need to remember or store passwords to authenticate to applications, and in principle a button-free authentication can be implemented.

The NAF has a trust relationship with the Bootstrapping Server Function (BSF) or mobile network operator of the UE, and it queries the BSF (using the bootstrapping transaction identifier (B-TID)) for the NAF specific key, K_NAF, over a secure channel such as TLS. When the BSF responds to the NAF, it also includes the service user identity to be used for the user i.e. a mapping to the user account at the service. This identity could be the international mobile subscriber identity (IMSI), IP Multimedia Private Identity (IMPI), Mobile Station ISDN Number (MSISDN, where ISDN is short for Integrated Services Digital Network) or some other information stored in the Home Subscriber Server (HSS) or Home Location Register (HLR) (in a User Security Settings (USS) entry in GBA User Security Settings (GUSS)) for the subscription/service/NAF.

In document 3GPP TS33.501, both EAP-AKA (Extensible Authentication Protocol Authentication and Key Agreement prime) and newly developed 5G AKA (Authentication and Key Agreement) are supported for core network authentication. The globally unique 5G subscription permanent identifier is called Subscription Permanent Identifier (SUPI) as defined in 3GPP TS 23.501. The Subscription Concealed Identifier (SUCI) is a privacy preserving identifier containing the concealed SUPI.

The following network nodes are involved in 5G authentication:

AMF: Access and Mobility Management Function. This node is responsible for mobility and access management parts, NAS signaling and replaces the Mobility Management Entity (MME) in Long Term Evolution (LTE) networks.

SEAF: Security Anchor Function. This node is located within the Serving Network. When roaming, the UE communicates with the SEAF of the visited network. The SEAF replaces the MME in terms of authentication handling in the network.

AUSF: Authentication Server Function. This node replaces the HSS in LTE networks. UDM/ARPF: Unified Data Management/Authentication credential

Repository and Processing Function. This node replaces the HSS in LTE networks.

The AUSF and UDM/ARPF are nodes in the home network. The UE and UDM/ARPF share a long-term secret symmetric key, K.

The SUPI should never be exposed publicly. A node called the Subscriber Identity Deconcealing Function (SIDF) in the home network is therefore configured to decrypt a SUCI value into a SUPI: this functionality resides within (or is co-located with) the ARPF. Currently EAP-AKA’ and EAP-TLS are two methods that are specified for authentication of UEs in 3GPP fifth generation (5G) networks. In 3GPP 5G network the EAP framework is used for authentication. This allows for the use of AKA-based credentials and authentication methods (e.g. EAP-AKA’) and also other than AKA-based credentials and authentication methods. Currently, GBA is specified to be performed over HTTP and based on AKA credentials. This restricts the potential to use GBA for 5G networks only for those cases where AKA-based credentials and authentication methods are used. Also, with existing GBA specification, the UE has to contact two different servers (BSF and NAF) on the Internet for successful authentication and key derivation. This not only leads to additional messages, but also more resource consumption and implementation complexity in the UE.

Hence, there is still a need for improved authentication mechanisms for UEs.

SUMMARY

An object of embodiments herein is to provide efficient authentication mechanisms for UEs, particularly in 5G networks.

According to a first aspect there is presented a method for authentication and key agreement for a terminal device. The method is performed by an application server. The method comprises tunneling, using EAP signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device. The method comprises providing binding

information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling. The method comprises obtaining a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

According to a second aspect there is presented an application server for authentication and key agreement for a terminal device. The application server comprises processing circuitry. The processing circuitry is configured to cause the application server to tunnel, using EAP signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device. The processing circuitry is configured to cause the application server to provide binding information relating to the

bootstrapping session to the key management server as part of tunneling the EAP signalling. The processing circuitry is configured to cause the application server to obtain a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

According to a third aspect there is presented an application server for authentication and key agreement for a terminal device. The application server comprises a tunnel module configured to tunnel, using EAP signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device. The application server comprises a provide module configured to provide binding information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling. The application server comprises an obtain module configured obtain a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

According to a fourth aspect there is presented a computer program for authentication and key agreement for a terminal device. The computer program comprises computer program code which, when run on processing circuitry of an application server, causes the application server to perform a method according to the first aspect.

According to a fifth aspect there is presented a method for authentication and key agreement for a terminal device. The method is performed by a key management server. The method comprises authenticating the terminal device using EAP signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server. The method comprises obtaining binding information relating to the bootstrapping session from the application server. The method comprises obtaining and storing a first key, wherein the first key is to be used as root key. The method comprises deriving a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session. The method (optionally) comprises providing the second key to the application server.

According to a sixth aspect there is presented a key management server for authentication and key agreement for a terminal device. The key

management server comprises processing circuitry. The processing circuitry is configured to cause the key management server to authenticate the terminal device using EAP signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server. The processing circuitry is configured to cause the key management server to obtain binding information relating to the bootstrapping session from the application server. The processing circuitry is configured to cause the key management server to obtain and store a first key, wherein the first key is to be used as root key. The processing circuitry is configured to cause the key management server to derive a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session. The processing circuitry is (optionally) configured to cause the key management server to provide the second key to the application server.

According to a seventh aspect there is presented a key management server for authentication and key agreement for a terminal device. The key

management server comprises an authenticate module configured to authenticate the terminal device using EAP signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server. The key management server comprises an obtain module configured to obtain binding information relating to the bootstrapping session from the application server. The key management server comprises a obtain and store module configured to obtain and store a first key, wherein the first key is to be used as root key. The key management server comprises a derive module configured to derive a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session. The key management server (optionally) comprises a provide module configured to provide the second key to the application server.

According to an eight aspect there is presented a computer program for authentication and key agreement for a terminal device, the computer program comprising computer program code which, when run on processing circuitry of a key management server, causes the key management server to perform a method according to the fifth aspect.

According to a ninth aspect there is presented a computer program product comprising a computer program according to at least one of the fourth aspect and the eight aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium. Advantageously these methods, these application servers, these key management servers, these computer programs, and this computer program product provide efficient authentication and key agreement for the terminal device.

Advantageously these methods, these application servers, these key management servers, these computer programs, and this computer program product enable authentication and application security based on 3GPP subscription credentials in the context of 5G telecommunication systems.

Advantageously these methods, these application servers, these key management servers, these computer programs, and this computer program product enable the possibility to use EAP methods and credentials supported by the mobile network operator for GBA, where the mobile network operator is allowed to decide what EAP method to be used.

Advantageously these methods, these application servers, these key management servers, these computer programs, and this computer program product enable reduction of the resource consumption on the terminal device, requiring one less round trip than standard GBA.

Advantageously these methods, these application servers, these key management servers, these computer programs, and this computer program product are applicable for application layer protocols that do not have HTTP digest AKA authentication.

Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent enumerated embodiments as well as from the drawings.

Generally, all terms used in the enumerated embodiments are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

Fig. l is a schematic diagram illustrating a communication network according to embodiments;

Figs. 2, 3, 4, 7, 8, 9, to, n, 12, 13 are signalling diagrams according to embodiments;

Figs. 5 and 6 are flowcharts of methods according to embodiments;

Fig. 14 is a schematic diagram showing functional units of an application server according to an embodiment;

Fig. 15 is a schematic diagram showing functional modules of an application server according to an embodiment;

Fig. 16 is a schematic diagram showing functional units of a key management server according to an embodiment;

Fig. 17 is a schematic diagram showing functional modules of a key management server according to an embodiment; and

Fig. 18 shows one example of a computer program product comprising computer readable means according to an embodiment.

DETAILED DESCRIPTION

The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

Fig. l is a schematic diagram illustrating a network too where embodiments presented herein can be applied. The network too comprises a radio access network no in which a network node 150 provide network access in a cell via a transmission and reception point 140. The network 100 further comprises a core network 120 and a service network 130. The radio access network no is operatively connected to the core network 120 which in turn is operatively connected to the service network 130. The radio access network node 140 thereby enables terminal devices 160 to access services and exchange data as provided by the service network 130.

Examples of terminal devices 160 include, but are not limited to, User Equipment (UE), mobile stations, mobile phones, handsets, wireless local loop phones, smartphones, laptop computers, tablet computers, sensors, actuators, modems, repeaters, network-equipped Internet of Things devices, and network-equipped vehicles. Examples of network nodes 150 include, but are not limited to, radio base stations, base transceiver stations, Node Bs, evolved Node Bs, gNBs, and access points. As the skilled person understands, the network 100 may comprise a plurality of transmission and reception points 140, each providing network access to a plurality of terminal devices 160, and each controlled by a network node 150.

An application server 200 and a key management server 300 could be provided in the core network 120 and/or the service network 130. Further functionality of the application server 200 and the key management server 300 will be disclosed below. As disclosed above, there is still a need for improved authentication mechanisms for terminal devices, such as UEs.

One example of GBA authentication is shown in the signalling diagram of Fig.

2. Slot: The UE initially identifies itself to the mobile network operator and requests for authentication.

S102: The mobile network operator responds by sending a challenge that can be correctly responded to, only with the permanent secret stored on the UICC. S103: The UE responds to the challenge using the permanent secret on the UICC, and derives a master key, K_BSF.

S104: The mobile network operator then verifies the response and if it is found to be valid, it derives the same master key K_BSF and returns a bootstrapping ID (B-TID), and associated lifetime, to the UE. S105: The UE then derives an application server specific session key from the master key and initiates a secure connection with the application server with which it wants to communicate and provides the bootstrapping ID obtained in the previous step.

S106: The application server uses the bootstrapping ID to obtain a session key from the mobile network operator. The session key is derived from the master key by the mobile network operator. The mobile network operator authenticates the application server before generating and revealing the session key. Once the application server is authenticated, the application server receives the session key. S107: The application authenticates the UE with this session key, which then can be used for setting up a secure session. One example of a sample GBA bootstrapping and Hypertext Transfer Protocol (HTTP) digest authentication between the UE and a NAF is shown in the signalling diagram of Fig. 3.

S201: The UE contacts the service with which it wishes to communicate (NAF in 3GPP terminology). This means that the UE sends a HTTP GET message for the resource which it wishes to access.

S202: The service/NAF in-turn replies with a HTTP 401 Unauthorized message with WWW-Authenticate indicating that it requires digest authentication for access to that resource. The HTTP response header also contains the realm prefixed with“3GPP-Bootstrapping@” to indicate that a GBA run can be performed to obtain the appropriate keys for digest authentication.

Steps S201 and S202 could be skipped if the UE already knows that it will need to perform GBA bootstrapping for accessing the NAF. S203: The UE contacts the BSF hosted by the mobile network operator by sending a HTTP GET message. This message also includes the identity of the UE (IMPI) in the HTTP Authorization header.

S204: The HTTP GET request from the UE results in transmission of a 401 unauthorized message from the BSF to the UE with the HTTP header containing algorithm=”AKAvi-MD5” indicating that AKA authentication needs to be run. The message also includes a random number (RAND) and an authentication token (AUTN), which the BSF has received from the HSS when requesting an authentication vector based on the received IMPI.

S205: The UE checks that the AUTN is trusted and fresh (which

authenticates the network to the UE). If the AUTN is correctly verified, the UE then creates and sends another HTTP GET message, containing the username (IMPI) and using the result from AKA as password, to the BSF. S206: After verifying the authentication, the BSF replies with a 200 OK message whose body contains the B-TID and the lifetime for which the B-TID and the derived master key (Ks) would be valid. The B-TID is a context identifier that can be used for locating the bootstrapping context of the UE in the BSF. The B-TID has the format: base64(RAND)@<BSF domain name>.

S207: The UE contacts the service/NAF with a HTTP request.

S208: The NAF responds with HTTP 401 Unauthorized message.

S209: The UE sends a HTTP request message with Authorization header containing the B-TID as the username and using K_NAF as the password. The key K_NAF is derived from the master key K_BSF and the fully qualified domain name (FQDN) of the NAF.

S210: The NAF, over a secure and authenticated channel, requests a session (K_NAF) key from BSF based on the B-TID.

S211: If the NAF can verify the authentication message of the UE using the key K_NAF, the service/NAF replies with a 200 OK message and the UE is assured of successful authentication.

S212: The UE and NAF can then use the session key e.g. for TLS or Datagram Transport Layer Security (DTLS) in Pre-Shared Key (PSK) mode. This key can also be used for message level encryption and/or integrity protection. One example of EAP-AKA’ authentication is shown in the signalling diagram of Fig. 4.

S301: The UE identifies itself with the SUCI, including information identifying the home network. The message is sent to the SEAF.

S302: The SEAF forwards the message to the AUSF of the home network as identified by the message received from the UE.

S303: The AUSF further forwards the message to the UDM/ARPF. S304, S305, S306: The UDM/ARPF provides the SUCI to the SIDF which maps the SUCI to the SUPI and returns the SUPI to the UDM/ARPF.

S307: The UDM/ARPF generates an EAP-AKA’ authentication vector (AV) for the UE. The UDM/ARPF generates cipher key prime (CK’) and integrity key prime (IK’) and replaces cipher key CK and the integrity key IK with CK’ and IK’. The UDM/ARPF sends the transformed authenticator vector AV’ containing the RAND, AUTN, XRES, CK’ and IK’ and the corresponding SUPI to the AUSF (where XRES denotes expected response).

S308, S309: The AUSF sends an EAP-Request/AKA’-Challenge message to the SEAF. The SEAF transparently forwards this to the UE.

S310: The UE authenticates the network by checking the AUTN received. If accepted, it computes the response RES and computes CK and IK and then derives CK’ and IK’.

S311: The UE sends an EAP-Response/AKA’-Challenge message to the SEAF. S312: The SEAF transparently forwards the EAP-Response/AKA’-Challenge to the AUSF.

S313: The AUSF verifies the RES received and proceeds only on correct verification.

S314: The AUSF and the UE can exchange multiple EAP-Request/AKA’- Notification and EAP-Response/AKA’-Notification messages before the completion.

S315: The AUSF derives the Extended Master Session Key (EMSK) from CK’ and IK’. It uses the first 256-bits from EMSK as the K_AUSF and then drives the K_SEAF from the K_AUSF. The AUSF then sends an EAP-Success message to the SEAF along with the K_SEAF and SUPI.

S316: The SEAF forwards the EAP-Success message to the UE. The SEAF uses the key K_SEAF to derive the key K_AMF and sends the key K_AMF to the AMF. The EAP-Success message is sent to the UE together with the key ngKSI and Anti-Bidding-down Between Architectures, ABBA, parameter.

On receiving the EAP-SUCCESS, the UE calculates the EMSK from the CK’ and IK’ and uses the 256 first bits as the K_AUSF. It uses the K_AUSF to calculate the K_SEAF and K_AMF.

If the UE has a 5G Globally Unique Temporary Identity (GUTI), which is allocated by the AMF, it can be used instead of SUCI between UE and SEAF. SEAF then uses SUPI towards AUSF. SIDF is not used in this case as there is no need to find out SUPI as it is already known. The embodiments disclosed herein thus relate to mechanisms for

authentication and key agreement for a terminal device. In order to obtain such mechanisms there is provided an application server 200, a method performed by the application server 200, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the application server 200, causes the application server 200 to perform the method. In order to obtain such mechanisms there is further provided a key management server 300, a method performed by the key management server 300, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the key management server 300, causes the key management server 300 to perform the method.

Reference is now made to Fig. 5 illustrating a method for authentication and key agreement for a terminal device as performed by an application server 200 according to an embodiment. In this respect the application server might be configured to operate in, or interact with nodes in, a telecommunication system, such as a 5G telecommunication system.

S1110: The application server tunnels, using EAP signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device.

S1120: The application server provides binding information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling

S1130: The application server obtains a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

Embodiments relating to further details of authentication and key agreement for a terminal device as performed by the application server 200 will now be disclosed.

In terms of S1130, if the application server is implemented in the NAF, it obtains the third key from the key management server. If the application server is implemented in the BSF, it obtains the second key from the key management server (implemented in the AUSF) and then generates the third key itself from the second key.

There could be different types of application servers. In some embodiments the application server is a NAF server. In other embodiments the the application server is a BSF server.

In some aspects, when implemented in, or as, a NAF server the application server uses the third key for authentication and secure communication with the terminal device. Particularly, according to an embodiment the application server is configured to perform (optional) step S1140:

S1140: The application server authenticates the terminal device and/or establishes secure communication between the application server and the terminal device using the third key. i6

In some aspects, when implemented in, or as, a BSF server the application server can use the second key to derive further (third) keys (K_NAF) for those NAFs the terminal device wants to authenticate to. Particularly, according to an embodiment the application server is configured to perform (optional) step S1150:

S1150: The application server derives at least one further key from the second key for each NAF server the terminal device is to authenticate to.

In some aspects the EAP signalling is tunneled via the BSF and further via the NAF (i.e. it is also in the role of application server), and the BSF derives at least one further key from the second key for the NAF.

In some aspects the SUCI of the terminal device is provided to the key management server. Particularly, according to an embodiment the application server is configured to perform (optional) step S1160:

S1160: The application server provides a SUCI of the terminal device to the key management server.

In general terms, there are two ways of sending SUCI to the key management server. The first is by using EAP signalling and the second is by requesting authentication from the key management server with the SUCI (outside EAP) - and then starting the actual EAP signalling. Hence, in some aspects the SUCI is provided as part of tunneling the EAP signalling in step S1110.

Reference is now made to Fig. 6 illustrating a method for authentication and key agreement for a terminal device as performed by a key management server 300 according to an embodiment. In this respect the key management server might be configured to operate in, or interact with nodes in, a telecommunication system, such as a 5G telecommunication system.

S1210: The key management server authenticates the terminal device using EAP signalling during a bootstrapping session for the terminal device. The EAP signalling is tunneled to the terminal device via an application server. S1220: The key management server obtains binding information relating to the bootstrapping session from the application server.

S1230: The key management server obtains and stores a first key. The first key is to be used as root key.

S1240: The key management server derives a second key from the first key and based on the binding information, thereby binding the second key to the bootstrapping session.

S1250: (Optional) The key management server provides the second key to the application server.

In case the application server is implemented in the BSF the second key is derived for the application server. In case the application server is implemented in the NAF the key management server does not provide the second key to the application server. Hence step S1250 is optional.

In case both the application server and the key management server are implemented in one and the same BSF, the last step could be omitted.

Embodiments relating to further details of authentication and key agreement for a terminal device as performed by the key management server 300 will now be disclosed.

In some aspects the second key is a GBA master key and acts as a root key from which further (third) NAF specific keys (K_NAF) can be derived. Thus, according to an embodiment the key management server is configured to perform (optional) step S1260:

S1260: The key management server derives at least one further third key from the second key for each NAF server the terminal device is to

authenticate to.

This could, for example, be the case where the key management server is implemented as a BSF. If the key management server is implemented as e.g. an AUSF, the AUSF could generate the first key during EAP signalling, and then derive the second key that is provided to the BSF, from which the BSF might derive further third keys, such as NAF specific keys.

According to an embodiment the first key is bound to the bootstrapping session. In this respect, the first key could be bound to any of: GBA, NAF, BSF, GBA and NAF, GBA and BSF, GBA and NAF and BSF, and 5G_GBA.

In some aspects the application server provides a SUCI of the terminal device to the key management server. Thus, according to an embodiment the key management server is configured to perform (optional) step S1270: S1270: The key management server obtains a SUCI of the terminal device from the application server.

In some aspects the key management server then obtains the SUPI. Thus, according to an embodiment the key management server is configured to perform (optional) step S1280: S1280: The key management server obtains a SUPI of the terminal device based on the SUCI.

There could be different protocol layers on which the EAP signalling is provided. In some aspects the EAP signalling is provided at the application layer of the Open Systems Interconnection model (OSI) model. Particularly, according to an embodiment the EAP signalling is provided in headers or as payload of application layer messages.

There could be different protocols on the application layer. According to an embodiment the EAP signalling is provided in headers or as payload of HTTP messages. According to another embodiment the EAP signalling is provided in headers or as payload of Constrained Application Protocol (CoAP) messages. There could be different types of binding information. According to an embodiment the binding information pertains to at least one of: an identifier of the 5G application server, and/or an identifier of the 5G key management server and/or a string identifying that the purpose of the key usage is securing application layer communication, such as“GBA” or“application layer security”. In some aspects the binding information is referred to as GBA information.

There could be different examples of key management servers. In some embodiments the key management server is a BSF server. In some embodiments the key management server is an AUSF server.

Particular embodiments based on the above aspects, embodiments, and examples will now be described with references to the signalling diagrams of Figs. 7 to 13. Thus, the particular embodiments of Figs. 7 to 13 are based on, and thus encompassed by, the embodiments defined by the methods described with reference to the flowcharts of Figs. 5 and 6. Likewise, any of the steps of the signalling diagrams of Figs. 7 to 13 can be readily combined with the methods described with reference to the flowcharts of Figs. 5 and 6.

Fig. 7 shows a scenario where the UE first obtains the K_BSF by running GBA with EAP-AKA’ directly with the BSF. In general terms, the GBA bootstrapping based on HTTP digest AKA is replaced with EAP-AKA’. In this scenario no changes are required at the existing NAF for GBA authentication.

S401: The UE sends a HTTP request message to the BSF. The UE may include the identity (SUCI) already in this message.

S402: Optionally, the BSF responds with a 401 Unauthorized message and indicates that the UE identity is required (e.g. by including an EAP- Request/Identity message). S403: If requested in step S402, the UE sends a HTTP Authorization request message including its identity (e.g. in EAP-Response/Identity message) which includes SUCI as the identity.

S404: The BSF constructs the GBA information and requests authentication from the AUSF. This message includes the SUCI and the GBA information. This message may be an EAP-Response/Identity message, or a

Nausf_UEAuthenticationAuthenticate Request message, or another message.

S405: The AUSF requests authentication information from the UDM/ARPF and indicates the purpose of the authentication by indicating GBA in the Serving network name parameter. The request includes the SUCI.

S4o6a, S4o6b, S406C: The SUCI is resolved to SUPI.

S407: The UDM/ARPF generates AV using the GBA indication in the CK’ and IK’ derivation.

S408: The UDM/ARPF sends the AV and SUPI to the AUSF. S409: The AUSF sends the EAP-Request/AKA’ Challenge message to the

BSF. The AT_KDF_INPUT parameter is included in the message and indicates the use of GBA as described below.

S410: The BSF forwards the EAP-Request/AKA’ Challenge to the UE in a 401 Unauthorized header message. S411: The UE processes the EAP-Request/AKA’ Challenge message (RAND,

AUTN etc.). The UE processes AT_KDF_INPUT parameter and verifies that the authentication is for GBA and uses it in the derivation of CK’ and IK’. The verification can be done e.g. by comparing the BSF identifier present in the AT_KDF_INPUT parameter with the BSF identifier in the HTTP request Uniform Resource Identifier (URI).

S412: The UE sends a EAP-Response/AKA’ Challenge message to the BSF. S413: The BSF forwards the EAP-Response/AKA’ Challenge message to the AUSF

S414: The AUSF verifies the EAP-Response/AKA’ Challenge message. If successful, the AUSF derives EMSK from CK’ and IK’. S415: The AUSF derives K_BSF from the EMSK using GBA indication in the

K-BSF derivation as the Serving network name parameter.

S416: The AUSF sends EAP Success and the K_BSF to the BSF.

S417: The BSF keeps the K_BSF and sends the EAP Success (and optionally the B-TID) to the UE. Upon receiving the EAP Success, the UE derives EMSK and K_BSF similarly as the AUSF did.

The K_BSF can be used similarly as the key K_BSF is used to access a NAF.

S418: The UE proceed with requesting a resource from the NAF, e.g. using HTTP GET request as in regular pre-sG GBA. S419: The NAF replies with a HTTP 401 authentication request message, requesting HTTP digest authentication.

S420: The UE derives a NAF specific KEY, K_NAF, from the key K_BSF and the NAF information, including the FQDN. The UE answers the

authentication challenge using the B-TID or the SUCI as user name and the key K_NAF as password.

S421: The NAF requests the key K_NAF from the BSF using B-TID or the SUCI.

S422: The BSF verifies the NAF identity and using the provided B-TID locates the associated key K_NAF, from which it generates the matching K_NAF. The BSF provides the K_NAF to the NAF. S423: The NAF verifies the authentication of the UE using the received K_NAF and replies with a HTTP 200 OK message indicating authentication was successful.

S724: The UE and NAF can using the shared secret K_NAF establish a secure session.

Variant: NoAUSF

The termination of EAP messages in the example above is at the AUSF in the home network. The EAP messages can also be instead terminated at the BSF (i.e. it is the EAP server) so AUSF is not needed at all. In this case the BSF communicates with the UDM/ARPF directly and can optionally use EMSK directly as the K-BSF.

In another variant, the AUSF is present but the BSF still takes the role of the EAP server. The BSF in this case would then communicate via the AUSF with the UDM/ARPF.

EAP-AKA’ and the AT KDF INPUT parameter

When the same authentication credentials are used for more than one purpose, e.g. for primary authentication to access an evolved packet core (EPC) network or a 5G core network (5GC), it is in some aspects required that the authentication messages used in one context cannot be tunneled (e.g. by an attacker) into the other context.

EAP-AKA’ includes a parameter AT_KDF_INPUT that is used to bind the CK’ and IK’ and consequently the EMSK to the access type or to the serving network name. The parameter is populated by the EAP server (e.g. AUSF) and sent to the UE inside the EAP-AKA’ messages. Both the peer (i.e. the UE) and the EAP server (e.g. AUSF) use the AT_KDF_INPUT as an input to the derivation of CK’/IK’ and consequently to the derivation of EMSK. The UE checks that the access type or the serving network is correct, and the EAP server (e.g. AUSF or authentication, authorization, and accounting server) verifies that the corresponding parameters are correct.

3GPP TS 24.302 specifies the Access Network Identity (ANID) that represents the actual encoding of the AT_KDF_INPUT parameter. When EAP-AKA’ is used in the evolved packet system (EPS), the AT_KDF_INPUT includes only an ANID prefix. The format would allow the use of one or more ANID additional character strings separated by the colon character When EAP-AKA’ is used in a 5G context, the prefix has a static string“5G” (i.e. the SNN-service-code), and the suffix includes always the serving network name. Below is listed two options. The quotes (“) and the concatenation character (I I) are not part of the actual character string.

• EPS:

• 5GS: SNN-service-code 1 1 ” 1 1 SNN-network-identifier In some aspects the 5G GBA needs to specify what is included in the

AT_KDF_INPUT parameter. In some embodiments, the ANID prefix includes a static string, e.g.“GBA”,“5G-GBA” or similar that is different from currently specified ANID prefixes in 3GPP TS 24.302. The additional ANID strings (that are separated from the prefix and other additional strings with “:” character), may not exist, or may include the BSF identifier or the NAF identifier or both. Below are listed some options for AT_KDF_INPUT in GBA context.

• AT_KDF_INPUT =“GBA’

• AT_KDF_INPUT =“GBA” | |”:” 1 1 NAF_identifier

• AT_KDF_INPUT =

“GBA”| |”:”BSF_identifier| |”:”| |NAF_identifier Variant: GBA with EAP via NAF

For 5G EAP -AKA’ based GBA authentication and key establishment between a UE and a NAF (application server), the following message exchanges, as shown in the signalling diagram of Fig. 8 takes place. S501: The UE contacts the NAF. The UE sends a HTTP GET message for the resource which it wishes to access. This step and step S502 can be skipped if the UE knows that the NAF supports GBA with (in this case) EAP -AKA’, in which case the UE includes the SUCI in this message, and steps S502 and S503 are skipped. S502: Optionally, the service/NAF replies with a HTTP 401 Unauthorized message with WWW-Authenticate indicating that the requested resource is protected and authentication is required for access. The HTTP response header can also contain the realm prefixed with“3GPP-Bootstrapping@” to indicate that a GBA run can be performed to obtain the appropriate keys for accessing the desired resource. The header can alternatively include an explicit realm prefix such as“EAP-3GPP-Bootstrapping@” to indicate that a EAP based GBA run can be performed (for backwards compatibility 3GPP- Bootstrapping is preferred). The header also contains an identity request which could be e.g. the EAP-Request/Identity message. Currently the values registered by IANA for WWW- Authentication schemes include Digest, Basic,

OAuth etc. and not EAP. A new value will need to be registered for EAP based HTTP resource authentication. This value would then be used in the HTTP 401 message in the WWW-Authenticate header. For HTTP Digest, the header starts with“WWW-Authenticate: Digest”. For the EAP scheme, the allocated value, e.g.“EAP”, would replace“Digest”. The EAP message (e.g. EAP

Identity request) could follow after that, e.g. in base64 encoded format. In a similar way, when using the HTTP Authorization header, which for Digest authentication begins with“Authorization: Digest”,“Digest” could be replaced by“EAP”, and then the carried EAP message would follow. The same logic can be applied for other related headers, e.g. the Authentication- info header Below it will be disclosed how EAP based GBA can be used with the existing digest authentication scheme in a backwards compatible way). EAP messages sent in HTTP headers or bodies can be encoded for example with base64- S503: If requested, the UE then responds with an HTTP request message containing the Authorization Request header. The header includes the UE identity which could be encoded as the EAP-Response Identity message or a separate identity part in the HTTP body. The identity used can be the SUCI or 5G GUTL The identity information can be formatted as a Network Access Identifier (NAI) specified in RFC 7542. The identity could be of the form SUCI@Home-network.

S504: The service/NAF acts as a simple pass through EAP authenticator. It sends an authentication request to the BSF (which could be the EAP- Response Identity message or some other message). The service/NAF can deduce this from the identity provided by the UE/device. Optionally, the NAF may construct and include NAF-info that is also included into the message. The NAF-info is an instance of the NAF-identifier that could be used in the AT_KDF_INPUT.

S505: The BSF constructs the GBA information parameter, and requests authentication from the AUSF. This message includes the UE identity (that may be encoded as EAP-Response Identity message) and the GBA-info. The GBA-info parameter may include e.g. part of the NAF-info parameter and the BSF-identifier.

S506: The AUSF requests authentication information from the UDM/ARPF. The AUSF indicates that the authentication information is needed for GBA. The request includes the SUCI.

8507a, 8507b, S507C: The UDM/ARPF uses the SIDF to map the SUCI to the SUPI. S508: On receiving the SUPI, the UDM/ARPF generates the EAP-AKA’ AV containing the RAND, AUTN, XRES, CK’ and IK’. UDM/ARPF uses GBA specific“serving network name” construction.

S509: The UDM/ARPF sends the EAP-AKA’ AV to the AUSF together with the SUPI.

S510: The AUSF generates the EAP-Request/AKA-Challenge message containing the AUTN, RAND and AT_KDF_INPUT and sends it to the BSF. The BSF forwards it to the NAF which then forwards it to the UE (in an HTTP 401 message containing the WWW-Authenticate header). The UE verifies the network by checking the AUTN.

S511: On successful verification of the AT_KDF_INPUT parameter (i.e. UE verifies the BSF identity, NAF identity or both), the UE also responds with an HTTP GET message containing the Authorization Request header that has the EAP-Response/AKA’-Challenge message comprising the RES. S512: The NAF on receiving the EAP message forwards it to the BSF which then forwards it to the AUSF. The AUSF compares the RES with the XRES. If they match, the authentication is successful and the AUSF uses the EMSK exported by the EAP authentication to derive K_AUSF.

S513: The AUSF then derives the K_BSF using GBA specific“serving network name” construction. It is possible that the“serving network name” construction used by UDM/ARPF in step S508 and the“serving network name” construction used here are the same or different.

S514: The AUSF sends K_BSF along with the EAP-Success message to the BSF.

S515: BSF derives K_NAF based on the NAF identity and K_BSF and sends it along with the EAP-Success message to the NAF. S516: The NAF at this stage considers the UE authenticated for the resource and sends the EAP-Success along with a 200 OK message containing the Authentication-Info Response header that has the EAP-Success message. This packet may contain payload of the original request resource.

S517: A secure session key is established between the UE and the NAF.

Variant: GBA with EAP-TLS

Fig. 9 is a signalling diagram of an example of how EAP-TLS can be used instead of EAP-AKA' for GBA bootstrapping. Similar to Fig. 7, the UE first obtains the K_BSF by running GBA with EAP-TLS directly with the BSF. The GBA bootstrapping based on HTTP digest AKA is replaced with EAP-TLS. In this scenario no changes are required at existing NAF for GBA

authentication.

S601: The UE sends HTTP request to the BSF. The UE may include the identity (SUCI) in this message.

S602: Optionally, the BSF responds with a 401 Unauthorized message and indicates that the UE identity is required (e.g. by including an EAP- Request/Identity message).

If requested in step S602, the UE sends a HTTP Authorization request message including its identity (e.g. in EAP-Response/Identity message) which includes SUCI as the identity.

S603: The BSF constructs the GBA info and requests authentication from the AUSF. This message includes the SUCI and the GBA information. This message may be EAP-Response/Identity message or

Nausf_UEAuthenticationAuthenticate Request or a new message.

S604: The AUSF requests authentication information from UDM/ARPF and indicates the purpose of the authentication by indicating GBA in the Serving network name parameter. The request includes the SUCI. S605, S606: The SUCI is resolved to SUPI.

S607-S621: The UDM/ARPF provides the SUPI to the AUSF and indicates the supported EAP mode (EAP-TLS in this example, but other/multiple modes could be indicated as well). The UE and AUSF run the EAP-TLS exchange, with the BSF acting as EAP authenticator. Once EAP-TLS is completed, AUSF generates the BSF key (K_BSF, or Ks in legacy GBA) from the key material exported by the EAP-TLS authentication and provides it to the BSF together with the EAP success message. K_BSF can be derived from the MSK/EMSK exported by EAP-TLS authentication such as

K_BSF=h(“GBA-EAP-TLS-BSF”, EMSK) where h is a

random/pseudorandom function chosen/negotiated. The UE similarly generates the K_BSF with the key material exported by EAP-TLS. The key Ks_NAF is generated from the key K_BSF and can be used for digest authentication. Variant: GBA with EAP-TLS over HTTP via NAF

The signalling diagram of Fig. 10 gives an example of how EAP-TLS can be used instead of EAP -AKA’ for GBA bootstrapping when bootstrapping via NAF.

The steps in Fig. 10 are the same as the steps in Fig. 9 except that the messages go from UE through NAF (i.e. steps S703, S713, etc.) and then to the BSF, which means that carrying EAP in HTTP authentication messages occurs between the UE and the NAF instead of between the UE and the BSF; between the NAF and the BSF the EAP messages are not carried in HTTP authentication messages. In summary, this results in the following differences compared to Fig. 9:

S704: The NAF includes NAF information, which is by the BSF included in the GBA information sent in step S705. S711: The BSF sends the TLS start, without HTTP 401 unauthorized, which is instead added by the NAF in step S712.

S729: The BSF receives EAP-Success and K_BSF. The BSF generates the key K_NAF and forwards it together with the EAP-Success to the NAF. S731: The UE and the NAF have an established TLS session.

The message exchange follows that of EAP -AKA’ until the SIDF replies with SUPI to ARPF. The ARPF, instead of generating the EAP -AKA’ AV, provides the SUPI to AUSF and indicates the supported EAP mode (EAP-TLS in this example, but other/multiple modes could be indicated as well). The UE and AUSF run the EAP-TLS exchange, with the NAF acting as EAP authenticator and the BSF forwarding messages between NAF and AUSF. Once EAP-TLS is completed, The AUSF generates the BSF key (K_BSF, or Ks in legacy GBA) and provides it to the BSF together with the EAP success message. The BSF further generates the key K_NAF from the key K_BSF and provides it to the NAF with the EAP-Success message. The key K_BSF can be generated from the key material exported by the successful EAP-TLS authentication, such as using the MSK/EMSK exported. This could be of the form K_BSF=h(“GBA- EAP-TLS-BSF”, EMSK) and K_NAF =h(“GBA-EAP-TLS-NAF”, EMSK) where h is a random/pseudorandom function chosen/negotiated. The UE obtains an indication that EAP-TLS was completed successfully and optionally also the requested resource from the NAF. The UE and NAF have established a secure TLS session at this stage.

The message exchanges shown in Figs. 7, 8, 9, and 10 rely on transporting EAP messages in HTTP headers and using header options such as

Authentication-Info, Authorization Request and WWW-Authenticate.

However, the EAP messages can also be sent in payload of application layer messages.

Variant: GBA with EAP over CoAP via NAF The signalling diagram of Fig. 11 gives an example of how EAP based GBA can be used for applications relying on CoAP instead of HTTP, and in addition also how the EAP messages can be included in the message body by sending CoAP POST messages instead of CoAP GET messages. Fig. 11 illustrates the same exchange as shown in Fig. 8 but with HTTP replaced with CoAP, and including EAP messages in the message body instead of the headers.

S801: UE sends CoAP GET for a resource of the NAF. The SUCI could be included in the message and the identity could be included in the initial request message.

S802: NAF replies with a CoAP 4.01 message indicating authentication is required. The message includes an EAP identity request

S803: the UE replies with a CoAP POST message with its identity, SUCI, carried in an EAP identity response, which is part of the CoAP message body. The POST is to a resource (/auth/17) at the NAF. The resource could be known/configured to the UE from before, be standardized, or the UE could find it out by querying the so-called“.well-known” of the CoAP peer.

S804: The NAF forwards the EAP identity response message to the BSF, and includes information about itself in NAF info (for optionally use when binding keys to the GBA session)

S805: The BSF forwards the EAP message to the AUSF, together with the GBA info parameter which contains information about both the NAF

(received in NAF info) and the BSF

S806: The AUSF requests authentication information from the UDM/ARPF. The AUSF indicates that the authentication information is needed for GBA. The request includes the SUCI and GBA session related information such as NAF info and BSF info

Steps S807-S809 are identical to steps S507-S509, except that S810-S811: The AUSF generates the EAP-Request/AKA’-Challenge message containing the AUTN, RAND and AT_KDF_INPUT and sends it to the BSF. The BSF forwards it to the NAF

S812: The NAF replies with a CoAP 2.01 Created message as a reply to the POST message S803. The message contains the EAP request message in the body of the CoAP 2.01 message

S813: The UE performs the AKA’ protocol as in all previous flows and again replies with a CoAP POST message to the /auth/17 resource with the EAP- AKA’ response in the body of the CoAP message S814: The NAF forwards the EAP -AKA’ response to the BSF

S815: the BSF forwards the EAP-AKA’ response to the AUSF

S816: the AUSF verifies the AKA’ response, generates K_BSF and replies to BSF with an EAP SUCCESS message, including the key K_BSF

S817: The BSF derives K_NAF from K_BSF and forwards the EAP Success message to the NAF together with the key K_NAF and optionally the B-TID. The B-TID is optionally communicated from the BSF to the UE (possibly via the NAF).

S818: The NAF sends a CoAP acknowledgement 2.04 message with changed payload, including the EAP Success message and B-TID if received from BSF. S819: The UE derives the keys K_BSF and K_sNAF so NAF and UE have a shared secret in K_NAF.

Variant: GBA with EAP and HTTP Digest

The signalling diagram of Fig. 12 gives an example of how GBA based on EAP-AKA’ can be used in a backwards compatible way with HTTP digest authentication towards the NAF (where the Digest challenge called Digest nonce in the figures). In addition to including the digest authentication to the NAF, this message exchange is different from the ones in Figs. 7-10 because it does not use the Authorization Request header with challenge =“EAP”, but instead uses HTTP POST messages to include EAP messages in the message body (in a similar way as is done in Fig. 11 for CoAP).

Fig. 12 is identical to Fig. 11, except that CoAP is replaced with HTTP, and a different resource to post to (/auth/5) is used in Fig. 12. Also, the NAF includes a digest challenge/nonce in S918.

Further, Fig. 12 shows how to establish the secure session with the NAF, which is not shown in Fig. 11:

S919: The UE as part of a HTTP GET request sends a digest response to the NAF as response to the digest challenge received in S918 (the digest challenge was not part of the method in Fig. 11 as CoAP does not have digest authentication). B-TID, or optionally SUCI (such as if the B-TID is optional and not present), is used as username and K_NAF is used as password.

S920: The NAF verifies the digest using K_NAF received from the BSF in S917 and responds with an HTTP 200 OK and optionally includes the response to the HTTP request of S919.

S921: The UE and the NAF share a secret, the key K_NAF.

Variant: GBA with EAP and optimized HTTP Digest authentication

The signalling diagram of Fig. 13 is a further optimization of the signalling diagram in Fig. 12 where the UE sends the digest authentication response (as in step S919) before the NAF has received the necessary keys for

authentication (as in step S917). In general terms, the challenge response message contains two authentication responses; one for the BSF/AKA and one for the NAF/digest. The UE receives both authentication challenges in the HTTP 401 message. In Fig. 12 the UE/network first handle the AKA challenge and then in a separate run the digest challenge. However, these can be done with one response message in the same way that the two challenges are received in one message. The signalling diagram of Fig. 13 is an example where authentication to two nodes (NAF and BSF) is done with a single message.

Fig. 13 is identical to Fig. 12, except for the following differences:

S1012: The NAF forwards the EAP request, optionally in the authentication header, to the UE and includes a digest challenge/nonce in the authentication header. Alternatively, the NAF sends a separate digest challenge message, and then sends the EAP request in a separate message, e.g. HTTP/2 SERVER PUSH message.

S1013: The UE performs AKA procedure and derives keys K_BSF and K_NAF in a similar way as described earlier. The UE responds with an HTTP POST message, with the EAP response in the message body. In addition, the message comprises a digest response to the digest challenge received in S1012, e.g. in an authentication header. The digest response is calculated using B-TID or SUCI as username and K_NAF as password.

S1014: The NAF stores the digest response and forwards the EAP response to the BSF.

S1018: The NAF, using K-NAF received in S1017, verifies the digest response stored in S1014, and if the verification is successful, then the NAF replies with an HTTP 200 OK message.

S1019: The UE and the NAF have a shared session key, Ks_NAF.

Some key differences between the herein disclosed embodiments, aspects, and examples to existing GBA will be summarized next.

According to some of the herein disclosed embodiments, aspects, and examples, it is possible to use SUCI instead of B-TID. SUCI provides similar privacy as B-TID. As the SUCI could be updated by the UE during the lifetime of a bootstrapping context, the UE would have to store the old SUCI with the associated bootstrapping context when it updates the SUCI.

According to some of the herein disclosed embodiments, aspects, and examples, the UE processes EAP messages sent within an application layer protocol such as CoAP/HTTP instead of performing HTTP digest AKA.

According to some of the herein disclosed embodiments, aspects, and examples, GBA authentication is enabled to be performed with any EAP method instead of solely relying on AKA.

According to some of the herein disclosed embodiments, aspects, and examples, the NAF acts as proxy for EAP messages as it acts as EAP authenticator.

According to some of the herein disclosed embodiments, aspects, and examples, the BSF obtains key K_BSF from the AUSF.

According to some of the herein disclosed embodiments, aspects, and examples the BSF can have bootstrapping context for the UE based on SUCI instead of B-TID.

According to some of the herein disclosed embodiments, aspects, and examples, GBA authentication could be performed with certificates (with EAP-TLS) or any other credentials chosen by the mobile network operator. This also means that the network is authenticated to the UE by, for example certificates (in EAP-TLS).

According to some of the herein disclosed embodiments, aspects, and examples, EAP messages are sent in an HTTP/CoAP POST body. This essentially means that the NAF is processing a post message from a node that is not yet authenticated. This might be necessary as a HTTP/CoAP GET message does not have a payload for carrying the EAP messages. Fig. 14 schematically illustrates, in terms of a number of functional units, the components of an application server 200 according to an embodiment.

Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1810a (as in Fig. 18), e.g. in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry 210 is configured to cause the application server 200 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 may be configured to retrieve the set of operations from the storage medium 230 to cause the application server 200 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.

The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The application server 200 may further comprise a communications interface 220 for communications with other servers, functions, nodes, entities, and devices. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital

components.

The processing circuitry 210 controls the general operation of the application server 200 e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the application server 200 are omitted in order not to obscure the concepts presented herein.

Fig. 15 schematically illustrates, in terms of a number of functional modules, the components of an application server 200 according to an embodiment. The application server 200 of Fig. 15 comprises a number of functional modules; a tunnel module 210a configured to perform step S1110, a provide module 210b configured to perform step S1120, and an obtain module 210c configured to perform step S1130. The application server 200 of Fig. 15 may further comprise a number of optional functional modules, such as any of an authentication/establish module 2iod configured to perform step S1140, a derive module 2ioe configured to perform step S1150, and a provide module 2iof configured to perform step S1160. In general terms, each functional module 2ioa-2iof may be implemented in hardware or in software.

Preferably, one or more or all functional modules 2ioa-2iof may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and/or the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 2ioa-2iof and to execute these instructions, thereby performing any steps of the application server 200 as disclosed herein.

Fig. 16 schematically illustrates, in terms of a number of functional units, the components of a key management server 300 according to an embodiment. Processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1810b (as in Fig. 18), e.g. in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA). Particularly, the processing circuitry 310 is configured to cause the key management server 300 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 may be configured to retrieve the set of operations from the storage medium 330 to cause the key management server 300 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The key management server 300 may further comprise a communications interface 320 for communications with other servers, functions, nodes, entities, and devices. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 310 controls the general operation of the key management server 300 e.g. by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the key management server 300 are omitted in order not to obscure the concepts presented herein.

Fig. 17 schematically illustrates, in terms of a number of functional modules, the components of a key management server 300 according to an

embodiment. The key management server 300 of Fig. 17 comprises a number of functional modules; an authenticate module 310a configured to perform step S1210, an obtain module 310b configured to perform step S1220, a obtain and store module 310c configured to perform step S1230, and a derive module 3iod configured to perform step S1240. The key management server 300 of Fig. 17 may further comprise a number of optional functional modules, such as any of a provide module 3ioe configured to perform step S1250, a derive module 3iof configured to perform step S1260, an obtain module 3iog configured to perform step S1270, and an obtain module 310I1 configured to perform step S1280.

In general terms, each functional module 3ioa-3ioi may be implemented in hardware or in software. Preferably, one or more or all functional modules 3ioa-3ioi may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and/or the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 3ioa-3ioi and to execute these instructions, thereby performing any steps of the key management server 300 as disclosed herein.

The application server 200 and/or key management server 300 may be provided as a standalone device or as a part of at least one further device. For example, the application server 200 and/or key management server 300 may be provided in a core network node. Alternatively, functionality of the application server 200 and/or key management server 300 may be distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part or may be spread between at least two such network parts.

Thus, a first portion of the instructions performed by the application server 200 and/or key management server 300 may be executed in a first device, and a second portion of the of the instructions performed by the application server 200 and/or key management server 300 may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the application server 200 and/or key management server 300 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by an application application server 200 and/or key management server 300 residing in a cloud computational environment. Therefore, although a single processing circuitry 210, 310 is illustrated in Figs. 14 and 16 the processing circuitry 210, 310 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 2ioa-2iof, 3ioa-3ioi of Figs. 15 and 17 and the computer programs 1820a, 1820b of Fig. 18.

Fig. 18 shows one example of a computer program product 1810a, 1810b comprising computer readable means 1830. On this computer readable means 1830, a computer program 1820a can be stored, which computer program 1820a can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 1820a and/or computer program product 1810a may thus provide means for performing any steps of the application server 200 as herein disclosed. On this computer readable means 1830, a computer program 1820b can be stored, which computer program 1820b can cause the processing circuitry 310 and thereto operatively coupled entities and devices, such as the communications interface 320 and the storage medium 330, to execute methods according to embodiments described herein. The computer program 1820b and/or computer program product 1810b may thus provide means for performing any steps of the key management server 300 as herein disclosed.

In the example of Fig. 18, the computer program product 1810a, 1810b is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1810a,

1810b could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1820a, 1820b is here schematically shown as a track on the depicted optical disk, the computer program 1820a, 1820b can be stored in any way which is suitable for the computer program product 1810a, 1810b.

The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the enumerated embodiments below:

1. A method for authentication and key agreement for a terminal device, the method being performed by an application server , the method comprising:

tunneling, using Extensible Authentication Protocol, EAP, signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device;

providing binding information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling; and

obtaining a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

2. The method according to item 1, wherein the application server is a Network Application Function, NAF, server.

3. The method according to item 1, further comprising:

authenticating the terminal device and/or establishing secure communication between the application server and the terminal device using the second key. 4. The method according to item l, wherein the application server is a Bootstrapping Server Function, BSF, server.

5. The method according to item 4, further comprising:

deriving at least one further key from the second key for each Network Application Function, NAF, server the terminal device is to authenticate to.

6. The method according to item 1, further comprising:

providing a Subscription Concealed Identifier, SUCI, of the terminal device to the key management server.

7. The method according to item 6, wherein the SUCI is provided as part of tunneling the EAP signalling.

8. A method for authentication and key agreement for a terminal device, the method being performed by a key management server , the method comprising:

authenticating the terminal device using Extensible Authentication Protocol, EAP, signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server ;

obtaining binding information relating to the bootstrapping session from the application server;

obtaining and storing a first key, wherein the first key is to be used as root key;

deriving a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session; and

(optionally) providing the second key to the application server.

9. The method according to item 8, further comprising:

deriving at least one further third key from the second key for each Network Application Function, NAF, server the terminal device is to authenticate to. 10. The method according to item 8, wherein the first key is bound to the bootstrapping session.

11. The method according to item 8, further comprising:

obtaining a Subscription Concealed Identifier, SUCI, of the terminal device from the application server.

12. The method according to item n, further comprising:

obtaining a Subscription Permanent Identifier, SUPI, of the terminal device based on the SUCI.

13. The method according to item 8, wherein the EAP signalling is provided in headers or as payload of application layer messages.

14. The method according to item 8, wherein the EAP signalling is provided in headers or as payload of Hypertext Transfer Protocol, HTTP, messages.

15. The method according to item 8, wherein the EAP signalling is provided in headers or as payload of Constrained Application Protocol, CoAP, messages.

16. The method according to item 8, wherein the binding information pertains to at least one of: an identifier of the 5G application server, and/or an identifier of the 5G key management server.

17. The method according to item 8, wherein the key management server is a Bootstrapping Server Function, BSF, server.

18. The method according to item 8, wherein the key management server is an Authentication Server Function, AUSF, server.

19. An application server for authentication and key agreement for a terminal device, the application server comprising processing circuitry, the processing circuitry being configured to cause the application server to: tunnel, using Extensible Authentication Protocol, EAP, signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device;

provide binding information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling; and

obtain a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

20. An application server for authentication and key agreement for a terminal device, the application server comprising:

a tunnel module configured to tunnel, using Extensible Authentication Protocol, EAP, signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device;

a provide module configured to provide binding information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling; and

an obtain module configured obtain a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

21. The application server according to item 19 or 20, further being configured to perform the method according to any of items 2 to 7.

22. A key management server for authentication and key agreement for a terminal device, the key management server comprising processing circuitry, the processing circuitry being configured to cause the key management server to:

authenticate the terminal device using Extensible Authentication Protocol, EAP, signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server ;

obtain binding information relating to the bootstrapping session from the application server;

obtain and store a first key, wherein the first key is to be used as root key;

derive a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session; and

(optionally) provide the second key to the application server.

23. A key management server for authentication and key agreement for a terminal device, the key management server comprising:

an authenticate module configured to authenticate the terminal device using Extensible Authentication Protocol, EAP, signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server ;

an obtain module configured to obtain binding information relating to the bootstrapping session from the application server;

a obtain and store module configured to obtain and store a first key, wherein the first key is to be used as root key;

a derive module configured to derive a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session; and

a provide module (optional) configured to provide the second key to the application server.

24. The key management server according to item 22 or 23, further being configured to perform the method according to any of items 9 to 18. 25. A computer program for authentication and key agreement for a terminal device, the computer program comprising computer code which, when run on processing circuitry of an application server , causes the application server to:

tunnel, using Extensible Authentication Protocol, EAP, signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device;

26. A computer program for authentication and key agreement for a terminal device, the computer program comprising computer code which, when run on processing circuitry of a key management server , causes the key management server to:

obtain and store a first key, wherein the first key is to be used as root key;

(optionally) provide the second key to the application server.

27. A computer program product comprising a computer program according to at least one of items 25 and 26, and a computer readable storage medium on which the computer program is stored.

Furthermore, the above mentioned and described embodiments are only given as examples and should not be limiting to the present invention. Other solutions, uses, objectives, and functions within the scope of the invention as claimed in the accompanying patent claims should be apparent for the person skilled in the art.

Claims

l. A method for authentication and key agreement for a terminal device, the method being performed by an application server , the method

comprising:

tunneling (sino), using Extensible Authentication Protocol, EAP, signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device;

providing (sii2o) binding information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling; and

obtaining (SI130) a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

2. The method according to item 1, wherein the application server is a

Network Application Function, NAF, server.

3. The method according to item 1, further comprising:

authenticating the terminal device and/or establishing secure communication (SI140) between the application server and the terminal device using the second key.

4. The method according to item 1, wherein the application server is a Bootstrapping Server Function, BSF, server.

5. The method according to item 4, further comprising:

deriving (SI150) at least one further key from the second key for each Network Application Function, NAF, server the terminal device is to authenticate to.

6. The method according to item 1, further comprising:

providing (sn6o) a Subscription Concealed Identifier, SUCI, of the terminal device to the key management server.

8. A method for authentication and key agreement for a terminal device, the method being performed by a key management server, the method comprising:

authenticating (si2io) the terminal device using Extensible

Authentication Protocol, EAP, signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server ;

obtaining (si22o) binding information relating to the bootstrapping session from the application server;

obtaining and storing (S1230) a first key, wherein the first key is to be used as root key;

deriving (S1240) a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session; and

optionally providing (S1250) the second key to the application server.

9. The method according to item 8, further comprising:

deriving (si26o) at least one further third key from the second key for each Network Application Function, NAF, server the terminal device is to authenticate to.

10. The method according to item 8, wherein the first key is bound to the bootstrapping session.

11. The method according to item 8, further comprising:

obtaining (S1270) a Subscription Concealed Identifier, SUCI, of the terminal device from the application server.

12. The method according to item 11, further comprising:

obtaining (si28o) (a Subscription Permanent Identifier, SUPI, of the terminal device based on the SUCI.

19. An application server (200) for authentication and key agreement for a terminal device (160), the application server comprising processing circuitry (210), the processing circuitry being configured to cause the application server to:

20. An application server (200) for authentication and key agreement for a terminal device (160), the application server comprising:

a tunnel module (210a) configured to tunnel, using Extensible

Authentication Protocol, EAP, signalling, messages of an authentication procedure of the terminal device between the terminal device and a key management server during a bootstrapping session for the terminal device; a provide module (2iob)configured to provide binding information relating to the bootstrapping session to the key management server as part of tunneling the EAP signalling; and

an obtain module (210 c) configured obtain a third key, wherein the third key is derived from a first key via a second key and bound to the bootstrapping session based on the binding information.

22. A key management server (300) for authentication and key agreement for a terminal device (160), the key management server comprising processing circuitry (310), the processing circuitry being configured to cause the key management server to:

obtain and store a first key, wherein the first key is to be used as root key;

optionally provide the second key to the application server.

23. A key management server (300) for authentication and key agreement for a terminal device (160), the key management server comprising:

an authenticate module (310a) configured to authenticate the terminal device using Extensible Authentication Protocol, EAP, signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server ;

an obtain module (310b) configured to obtain binding information relating to the bootstrapping session from the application server;

a obtain and store module (310c) configured to obtain and store a first key, wherein the first key is to be used as root key;

a derive module (3iod) configured to derive a second key for the application server from the first key and based on the binding information, thereby binding the second key to the bootstrapping session; and

an optional provide module (3ioe) configured to provide the second key to the application server.

24. The key management server according to item 22 or 23, further being configured to perform the method according to any of items 9 to 18.

25. A computer program for authentication and key agreement for a terminal device (160), the computer program comprising computer code which, when run on processing circuitry (210) of an application server, causes the application server (200) to:

26. A computer program for authentication and key agreement for a terminal device (160), the computer program comprising computer code which, when run on processing circuitry (310) of a key management server, causes the key management server (300) to:

authenticate the terminal device using Extensible Authentication

Protocol, EAP, signalling during a bootstrapping session for the terminal device, wherein the EAP signalling is tunneled to the terminal device via an application server ;

obtain and store a first key, wherein the first key is to be used as root key;

optionally provide the second key to the application server.

27. A computer program product (1810a, b) comprising a computer program 1820a, b) according to at least one of items 25 and 26, and a computer readable storage medium on which the computer program is stored.