WO2020007461A1

WO2020007461A1 - Authentication and key agreement between a network and a user equipment

Info

Publication number: WO2020007461A1
Application number: PCT/EP2018/068115
Authority: WO
Inventors: Patrik Salmela; Vesa Lehtovirta; Mohit SETHI
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-07-04
Filing date: 2018-07-04
Publication date: 2020-01-09

Abstract

There is provided mechanisms for establishing authentication and key agreement between a network and a UE. The UE has an Identifier. A method is performed by the UE. The method comprises providing, towards a bootstrapping server function of the network of the UE, a request message with the Identifier of the UE as username, as part of bootstrapping of the UE. The method comprises obtaining, from the bootstrapping server function, a response message to the request message. The response message comprises a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV. The AV has been generated based on the Identifier. The method comprises verifying the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an AUSF of the network of the UE.

Description

AUTHENTICATION AND KEY AGREEMENT BETWEEN A NETWORK AND A USER EQUIPMENT

TECHNICAL FIELD

Embodiments presented herein relate to a method, a user equipment (UE), a computer program, and a computer program product for establishing authentication and key agreement between a network and the UE. Further embodiments presented herein relate to a method, a bootstrapping server function, a computer program, and a computer program product for enabling establishment of authentication and key agreement between the network and the UE. Further embodiments presented herein relate to a method, an AUSF, a computer program, and a computer program product for enabling establishment of authentication and key agreement between the network and the UE.

BACKGROUND

In communications networks, there may be a challenge to obtain good performance and capacity for a given communications protocol, its parameters and the physical environment in which the communications network is deployed.

For example, one parameter in providing good performance and capacity for a given communications protocol in a communications network is

authentication.

In document 3GPP TS 33.501“Security architecture and procedures for 5G System”, V 15.1.0, both Extensible Authentication Protocol Authentication and Key Agreement prime (EAP-AKA) and 5G AKA are supported for core network authentication. Here, a globally unique 5G subscription permanent identifier is called a Subscription Permanent Identifier (SUPI) as defined in document 3GPP TS 23.501“System Architecture for the 5G System”, V 15-2- o. The so-called 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 (with functionality similar to that of the Mobility Management Entity (MME) in Long Term Evolution (LTE) networks, for mobility and access management parts, non-access stratum (NAS) signaling).

SEAF: Security Anchor Function (with functionality similar to that of the authentication parts of the MME in LTE networks). This node is within the serving network. When roaming, the used SEAF is located in the visited network.

AUSF: Authentication Server Function (with functionality similar to that of the Home Subscriber Server (HSS) in LTE networks).

ARPF: Authentication credential Repository and Processing Function (with functionality similar to that of the Home Subscriber Server (HSS) in LTE networks).

The AUSF and ARPF are nodes in the home network. The User Equipment (UE) and ARPF share a long-term secret symmetric key, K.

It is advantageous that the SUPI never is exposed publicly. A Subscriber Identity De-concealing Function (SIDF) in the home network is used to decrypt a SUCI value into a SUPI. This functionality resides within (or is co located with) the ARPF.

Fig. 1 is a signalling diagram of Authentication and Key Agreement (AKA) for a UE in a 5G network:

Si: UE identifies itself with the SUCI, where the SUCI includes information identifying the home network (HN). The message is sent to SEAF (first message:“SUCI + HN”). S2: SEAF forwards the message to the AUSF of the home network as identified by the message received from the UE (second message:“SUCI + HN”).

S3: AUSF further forwards the message to ARPF (third message:“SUCI + HN”).

S4a, S4b: ARPF provides the SUCI to SIDF (message“SUCI”) and gets in return the associated SUPI (message“SUPI”).

S5: ARPF generates a home environment (HE) authentication vector (AV) for the UE based on stored subscription information, including the secret key K. HE AV contains RAND, AUTN, and RES as in 4G AKA. The ARPF also generates and includes the key K_AUSF. HE AV and SUPI are provided to AUSF (message:“SUPI + HE AV: RAND, AUTN, XRES, K_AUSF”).

S6: AUSF generates the key K_SEAF and generates HXRES and provides an AV, containing RAND, AUTN, HXRES, and K_SEAF_, to SEAF (message:“AV: RAND, AUTN, HXRES, K_SEAF...”).

S7: SEAF forwards RAND and AUTN to the UE (message:“AUTN, RAND”).

S8: UE authenticates the network based on AUTN and answers the

authentication challenge, generating RES, K_SEAF_, and key K_AUSF. RES is sent to the SEAF (message:“RES”).

S9: SEAF verifies that the hash of RES is the expected hash of RES (HXRES) (action:“H(RES) ?= HXRES”).

S10: SEAF forwards RES to AUSF, which verifies that RES is the expected result (XRES) (message:“RES”, and action“RES ?= XRES”).

S11: If AUSF decides the authentication is successful, it indicates this to the SEAF and provides the SUPI (message:“Authenticated, SUPI”).

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

In view of the method illustrated in Fig. l and described above, the AKA procedure requires substantial signalling and sessions to be established.

Hence, there is still a need for an improved AKA procedure for a UE.

SUMMARY

An object of embodiments herein is to provide efficient authentication and key agreement between a network and a UE that does not suffer from the issues noted above, or at least where the above noted issues are reduced or mitigated.

According to a first aspect there is presented a method for establishing authentication and key agreement between a network and a UE. The UE has an Identifier. The method is performed by the UE. The method comprises providing, towards a bootstrapping server function of the network of the UE, a request message with the Identifier of the UE as username, as part of bootstrapping of the UE. The method comprises obtaining, from the bootstrapping server function, a response message to the request message. The response message comprises a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV. The AV has been generated based on the Identifier. The method comprises verifying the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an AUSF of the network of the UE.

According to a second aspect there is presented a UE for establishing authentication and key agreement between a network and the UE. The UE has an Identity. The UE comprises processing circuitry. The processing circuitry is configured to cause the UE to provide, towards a bootstrapping server function of the network of the UE, a request message with the

Identifier of the UE as username, as part of bootstrapping of the UE. The processing circuitry is configured to cause the UE to obtain, from the bootstrapping server function, a response message to the request message. The response message comprises a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV. The AV has been generated based on the Identifier. The processing circuitry is configured to cause the UE to verify the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an AUSF of the network of the UE.

According to a third aspect there is presented a UE for establishing

authentication and key agreement between a network and the UE. The UE has an Identity. The UE comprises a provide module configured to provide, towards a bootstrapping server function of the network of the UE, a request message with the Identifier of the UE as username, as part of bootstrapping of the UE. The UE comprises an obtain module configured to obtain, from the bootstrapping server function, a response message to the request message. The response message comprises a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV. The AV has been generated based on the Identifier. The UE comprises a verify module configured to verify the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an AUSF of the network of the UE.

According to a fourth aspect there is presented a computer program for establishing authentication and key agreement between a network and the UE. The computer program comprises computer program code which, when run on processing circuitry of the UE, causes the UE to perform a method according to the first aspect.

According to a fifth aspect there is presented a method for enabling establishment of authentication and key agreement between a network and a UE. The UE has an Identifier. The method is performed by a bootstrapping server function. The method comprises obtaining, from the UE, a request message with the Identifier of the UE as username, as part of bootstrapping of the UE. The method comprises providing, to an AUSF of the network of the UE, the Identifier. The method comprises obtaining, from the AUSF, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and is generated based on the Identifier. The method comprises providing, towards the UE, a response message to the request message. The response message comprises the RAND and the AUTN of the AV.

According to a sixth aspect there is presented a bootstrapping server function for enabling establishment of authentication and key agreement between a network and a UE. The UE has an Identifier. The bootstrapping server function comprises processing circuitry. The processing circuitry is configured to cause the bootstrapping server function to obtain, from the UE, a request message with the Identifier of the UE as username, as part of bootstrapping of the UE. The processing circuitry is configured to cause the bootstrapping server function to provide, to an AUSF of the network of the UE, the Identifier. The processing circuitry is configured to cause the bootstrapping server function to obtain, from the AUSF, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and is generated based on the Identifier. The processing circuitry is configured to cause the bootstrapping server function to provide, towards the UE, a response message to the request message. The response message comprises the RAND and the AUTN of the AV.

According to a seventh aspect there is presented a bootstrapping server function for enabling establishment of authentication and key agreement between a network and a UE. The UE has an Identifier. The bootstrapping server function comprises an obtain module configured to obtain, from the UE, a request message with the Identifier of the UE as username, as part of bootstrapping of the UE. The bootstrapping server function comprises a provide module configured to provide, to an AUSF of the network of the UE, the Identifier. The bootstrapping server function comprises an obtain module configured to obtain, from the AUSF, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and is generated based on the Identifier. The bootstrapping server function comprises a provide module configured to provide, towards the UE, a response message to the request message. The response message comprises the RAND and the AUTN of the AV.

According to an eighth aspect there is presented a computer program for enabling establishment of authentication and key agreement between a network and a UE. The UE has an Identifier. The computer program comprises computer program code which, when run on processing circuitry of a bootstrapping server function, causes the bootstrapping server function to perform a method according to the fifth aspect.

According to a ninth aspect there is presented a method for enabling establishment of authentication and key agreement between a network and a UE. The UE has an Identifier. The method is performed by an AUSF of the network of the UE. The method comprises obtaining, from a bootstrapping server function of the network of the UE, the Identifier. The method comprises providing, to an ARPF of the network of the UE, the Identifier in order for the AUSF to obtain a permanent identifier of the Identifier. The method comprises providing, to the bootstrapping server function, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and is based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE.

According to a tenth aspect there is presented an AUSF for enabling establishment of authentication and key agreement between a network and a UE. The UE has an Identifier. The AUSF comprises processing circuitry. The processing circuitry is configured to cause the AUSF to obtain, from a bootstrapping server function of the network of the UE, the Identifier. The processing circuitry is configured to cause the AUSF to provide, to an ARPF of the network of the UE, the Identifier in order for the AUSF to obtain a permanent identifier of the Identifier. The processing circuitry is configured to cause the AUSF to provide, to the bootstrapping server function, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and is based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE.

According to an eleventh aspect there is presented an AUSF for enabling establishment of authentication and key agreement between a network and a UE. The UE has an Identifier. The AUSF comprises an obtain module configured to obtain, from a bootstrapping server function of the network of the UE, the Identifier. The AUSF comprises a provide module configured to provide, to an ARPF of the network of the UE, the Identifier in order for the AUSF to obtain a permanent identifier of the Identifier. The AUSF comprises a provide module configured to provide, to the bootstrapping server function, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and is based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE.

According to a twelfth aspect there is presented a computer program for enabling establishment of authentication and key agreement between a network and a UE, the UE having an Identifier, the computer program comprising computer program code which, when run on processing circuitry of an AUSF, causes the AUSF to perform a method according to the ninth aspect.

According to a thirteenth aspect there is presented a computer program product comprising a computer program according to at least one of the fourth aspect, the eight aspect, and the twelfth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium can be a non-transitory computer readable storage medium.

Advantageously these methods, these UEs, these bootstrapping server functions, these AUSFs, and these computer programs provide efficient authentication and key agreement between the network and the UE.

Advantageously the disclosed authentication and key agreement procedure does not suffer from the issues noted above. Advantageously the disclosed authentication and key agreement procedure results in optimized resource consumption in the UE for performing the authentication and key agreement,

It is to be noted that any feature of the first, second, third, fourth, fifth, sixth seventh, eight, ninth, tenth, eleventh, twelfth, and thirteen aspects may be applied to any other aspect, wherever appropriate. Likewise, any advantage of the first aspect may equally apply to the second, third, fourth, fifth, sixth, seventh, eight, ninth, tenth, eleventh twelfth, and/or thirteenth aspect, respectively, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims 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. 1 is a signalling diagram of Authentication and Key Agreement for a UE in a 5G network;

Fig. 2 is a schematic diagram illustrating a network according to

embodiments;

Figs. 3, 4, and 5 are flowcharts of methods according to embodiments; Figs. 6, 7, and 8 are signalling diagram of Authentication and Key Agreement for a UE according to embodiments;

Fig. 9 is a schematic diagram showing functional units of a UE according to an embodiment;

Fig. 10 is a schematic diagram showing functional modules of a UE according to an embodiment;

Fig. li is a schematic diagram showing functional units of a bootstrapping server function according to an embodiment;

Fig. 12 is a schematic diagram showing functional modules of a bootstrapping server function according to an embodiment;

Fig. 13 is a schematic diagram showing functional units of an AUSF according to an embodiment;

Fig. 14 is a schematic diagram showing functional modules of an AUSF according to an embodiment; and

Fig. 15 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. 2 is a schematic diagram illustrating a network 100 where embodiments presented herein can be applied. The network 100 comprises a radio access network no in which radio access network nodes 140a, 140 provide network access in cells, a core network 120, and a service network 130. The radio access network node 140 is controlled by a network node 200. The radio access network 110 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 UEs 200 to access services and exchange data as provided by the service network 130.

Examples of UEs 200 include, but are not limited to, 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 too may comprise a plurality of radio access network nodes 140, each providing network access to a plurality of UEs 200, and each controlled by a network node 150.

The core network 120 at least comprises a bootstrapping server function 300 and an AUSF 400. Further functionality of the bootstrapping server function 300 and the AUSF 400 will be disclosed below.

As disclosed above there is still a need for an improved AKA procedure for a UE 200 and an object of embodiments herein is to provide efficient authentication and key agreement between the network too and the UE 200. In some aspects the embodiments disclosed herein enables generic bootstrapping architecture (GBA) services to be provided in the context of a 5G network. Some embodiments enables optimizations with regards to the resource consumption of the UE 200 for establishing the authentication and key agreement between the network too and the UE 200. The embodiments disclosed herein thus relate to mechanisms for

establishing authentication and key agreement between the network and the UE 200. In order to obtain such mechanisms there is provided a UE 200, a method performed by the UE 200, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the UE 200, causes the UE 200 to perform the method. In order to obtain such mechanisms there is further provided a bootstrapping server function 300, a method performed by the bootstrapping server function 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 bootstrapping server function 300, causes the bootstrapping server function 300 to perform the method. In order to obtain such mechanisms there is further provided an AUSF 400, a method performed by the AUSF 400, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the AUSF 400, causes the AUSF 400 to perform the method.

Reference is now made to Fig. 3 illustrating a method for establishing authentication and key agreement between the network and the UE 200 as performed by the UE 200 according to an embodiment. The UE 200 has an Identifier. Examples of such Identifiers will be provided below.

S102: The UE 200 provides, towards the bootstrapping server function 300 of the network of the UE 200, a request message with the Identifier of the UE 200 as username, as part of bootstrapping of the UE 200.

It is assumed that the bootstrapping server function 300 provides, towards the UE 200, a response message to the request message. The response message comprises a RAND and an AUTN of the AV. Thus:

S104: The UE 200 obtains, from the bootstrapping server function 300, a response message to the request message. The response message comprises a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV. The AV has been generated based on the Identifier. Sio6: The UE 200 verifies the AUTN, thereby authenticating the network, and derives its own instance of a bootstrapping server function key from a key, K_AUSF, of the AUSF 400 of the network of the UE 200. The key K_AUSF can be derived as described in 3GPP TS 33.501,“Security

architecture and procedures for 5G System” A.2, version 15.1.0

Embodiments relating to further details of establishing authentication and key agreement between the network and the UE 200 as performed by the UE 200 will now be disclosed.

There could be different types of Identifiers. According to an embodiment the Identifier provided towards the bootstrapping server function 300 is a Subscription Concealed Identifier, SUCI, having a Subscription Permanent Identifier , SUPI, that is encrypted with a public key of the network.

There could be different types of messages provided from, and obtained by, the UE 200.

According to an embodiment the request message as provided towards the bootstrapping server function 300 is a first HTTP GET message.

According to an embodiment the response message as obtained from the bootstrapping server function 300 is an HTTP Unauthorized message.

According to an embodiment the response message as obtained from the bootstrapping server function 300 indicates that authentication and key agreement, AKA, authentication needs to be run between the UE 200 and the bootstrapping server function 300.

There could be different ways for the UE to derive the bootstrapping server function key.

According to an embodiment the derivation of the bootstrapping server function key is based on K_AUSF and a string identifying purpose of the key derivation, and/or identity of the bootstrapping server function 300, and/or a freshness parameter. There could be different ways for the UE 200 to act once having verified the AUTN in step S106.

According to an embodiment the UE 200 is further configured to perform (optional) step S108: S108: The UE 200 provides, towards the bootstrapping server function 300, a second HTTP GET message with the Identifier as username and a response authentication parameter calculated using a user response, RES, as the password obtained from running authentication and key agreement. In other words, RES is the result of the UE 200 answering the challenge (given by RAND). RES can then be used as password e.g. during HTTP digest authentication, i.e. as password when calculating an authentication parameter such as the digest response.

According to an embodiment the UE 200 is further configured to perform (optional) step S110: S110: The UE 200 obtains, from the bootstrapping server function 300, an

OK message comprising a bootstrapping transaction identifier, B-TID.

According to an embodiment the UE 200 is further configured to perform (optional) step S112:

S112: The UE 200 derives a network application function, NAF, specific key, Ks_NAF.

According to an embodiment the UE 200 is further configured to perform (optional) step S114:

S114: The UE 200 provides, to a network application function, NAF, a third HTTP GET message with the B-TID as username and using the NAF specific key as password.

According to an embodiment all messages communicated between the UE 200 and the bootstrapping server function 300 are sent via a network application function, NAF. The Identifier as provided to the bootstrapping server function 300 via the NAF might then comprise unencrypted

information identifying the network.

According to an embodiment the second HTTP GET message is signed, e.g. keyed hash, with the NAF specific key, Ks_NAF. According to an

embodiment the AV has been generated from a home environment

authentication vector, HE AV, based on the Identifier.

Reference is now made to Fig. 4 illustrating a method for enabling

establishment of authentication and key agreement between the network and the UE 200, the UE 200 having an Identifier, as performed by the

bootstrapping server function 300 according to an embodiment.

It is assumed that the UE 200 provides, towards the bootstrapping server function 300 of the network of the UE 200, a request message with the Identifier of the UE 200 as username, as part of bootstrapping of the UE 200. Thus

S202: The bootstrapping server function 300 obtains, from the UE 200, a request message with the Identifier of the UE 200 as username, as part of bootstrapping of the UE 200.

S204: The bootstrapping server function 300 provides, to the AUSF 400 of the network of the UE 200, the Identifier.

It is assumed that the AUSF 400 provides, to the bootstrapping server function 300, an authentication vector, AV. Thus:

S206: The bootstrapping server function 300 obtains, from the AUSF 400, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and has been generated based on the Identifier.

S208: The bootstrapping server function 300 provides, towards the UE 200, a response message to the request message. The response message comprises the RAND and the AUTN of the AV. i6

Embodiments relating to further details of enabling establishment of authentication and key agreement between the network and the UE 200 as performed by the bootstrapping server function 300 will now be disclosed.

As disclosed above, according to an embodiment the Identifier as obtained from the UE 200 is a Subscription Concealed Identifier, SUCI, having a Subscription Permanent Identifier , SUPI, that is encrypted with a public key of the network.

As disclosed above, according to an embodiment the request message as obtained from the UE 200 is a first HTTP GET message.

As disclosed above, according to an embodiment the response message as provided towards the UE 200 is an HTTP Unauthorized message.

According to an embodiment the response message as provided towards the UE 200 indicates that authentication and key agreement, AKA,

authentication needs to be run between the UE 200 and the bootstrapping server function 300.

According to an embodiment the bootstrapping server function 300 is configured to perform (optional) step S210:

S210: The bootstrapping server function 300 obtains, from the UE 200, a second HTTP GET message with the Identifier as username and a response authentication parameter calculated using a user response, RES, as the password obtained from running authentication and key agreement.

According to an embodiment the bootstrapping server function 300 is configured to perform (optional) step S212:

S212: The bootstrapping server function 300 obtains verification of an expected user response, XRES, based on the RES obtained from the UE 200.

There could be different ways for the bootstrapping server function 300 to obtain verification of the expected user response, XRES. According to an embodiment the verification is obtained by the bootstrapping server function 300 itself verifying the XRES. According to another embodiment the verification is obtained by the bootstrapping server function 300 itself verifying a hashed user response, HRES, where the RES is provided to the AUSF 400 for verification of the XRES, and where a success response thereof is obtained from the AUSF 400.

According to an embodiment the bootstrapping server function 300 is configured to perform (optional) step S214:

S214: The bootstrapping server function 300 provides, towards the UE 200, an OK message comprising a bootstrapping transaction identifier, B-TID.

According to an embodiment the bootstrapping server function 300 is configured to perform (optional) step S216:

S216: The bootstrapping server function 300 provides, towards a network application function, NAF, a NAF specific key, Ks_NAF.

As disclosed above, according to an embodiment all messages communicated between the UE 200 and the bootstrapping server function 300 are sent via a network application function, NAF.

As disclosed above, according to an embodiment the Identifier as obtained from the UE 200 via the NAF comprises unencrypted information identifying the network.

There could be different ways for the AV to be generated. According to an embodiment the AV is generated from a home environment authentication vector, HE AV, where the HE AV has been generated based on the Identifier, and a bootstrapping server function key, K_BSF, where the bootstrapping server function key has been derived from a key, K_AUSF, of the AUSF 400.

Reference is now made to Fig. 5 illustrating a method for enabling establishment of authentication and key agreement between the network and i8 the UE 200, the UE 200 having an Identifier, as performed by the AUSF 400 according to an embodiment.

It is assumed that the bootstrapping server function 300 provides, to the AUSF 400 of the network of the UE 200, the Identifier. Thus:

S302: The AUSF 400 obtains, from the bootstrapping server function 300 of the network of the UE 200, the Identifier.

S304: The AUSF 400 provides, to an ARPF of the network of the UE 200, the Identifier in order for the AUSF 400 to obtain a permanent identifier of the Identifier.

S308: The AUSF 400 provides, to the bootstrapping server function 300, an authentication vector, AV. The AV comprises a challenge, RAND, and an authentication token, AUTN, and is based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE 200.

Embodiments relating to further details of enabling establishment of authentication and key agreement between a network and a UE 200 as performed by the AUSF 400 will now be disclosed.

According to an embodiment the AUSF 400 is configured to perform

(optional) step S306:

S306: The AUSF 400 obtains, from the ARPF, a home environment authentication vector, HE AV, for the UE 200. The HE AV is generated based on the Identifier. The AV is then generated from the HE AV, and a

bootstrapping server function key, K_BSF. The bootstrapping server function key is derived from a key, K_AUSF, of the AUSF 400.

According to an embodiment the HE AV is obtained together with the Identifier and generic bootstrapping architecture user security settings, GUSS, for the UE 200. According to an embodiment the AUSF 400 is configured to perform

(optional) steps S310, S312, S314:

S310: The AUSF 400 obtains, from the bootstrapping server function 300, a user response, RES, of the UE 200.

In this respect, the AUSF 400 might obtain a digest calculated with RES as password, and thus verifying the RES implies that the AUSF 400 performing a similar digest calculation using XRES as password. The RES is verified only when the digests match.

S312: The AUSF 400 verifies an expected user response, XRES, of the UE 200 based on the RES.

S314: The AUSF 400 provides a success response of the verified XRES and the Identifier to the bootstrapping server function 300 in response to having successfully verified the XRES.

In this respect, when sending the Identifier from the UE 200 towards the network (e.g. all the way from the UE 200 via the NAF, the BSF, the AUSF, and the ARPF, to the SIDF) it is the SUCI that is sent, but when send in the opposite direction it is the SUPI that is sent all the way to the BSF (but never all the way to UE) and then the SUCI is sent from the BSF to the UE 200.

According to an embodiment the derivation of the bootstrapping server function key is based on K_AUSF and a string identifying purpose of the key derivation, and/or identity of the bootstrapping server function 300, and/or a freshness parameter.

A first particular embodiment for authentication and key agreement between the network and the UE 200 based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram of Fig. 6.

S401: The UE contacts the NAF by sending an HTTP GET message for the resource which the UE wishes to access. Step S401 and step S402 can be skipped if the UE knows that the NAF supports GBA, in which case the procedure would start from step S403.

S402: The NAF replies to the UE with an HTTP 401 Unauthorized with WWW-Authenticate message, indicating that the NAF 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.

S403: The UE contacts the BSF of the home operator by sending an HTTP GET and using its SUCI as username. The bootstrapping interface could be a 5G specific one (e.g. /bsf/bootstrapsg) or the BSF can understand from the identity (SUCI) that 5G authentication is used.

8404a, S404I), S404C, S404d, S404e: The BSF sends the SUCI to the AUSF; the AUSF forwards the SUCI to the ARPF, and the ARPF forwards the SUCI to the SIDF in order to obtain the permanent identifier of the SUPI.

S405: Once the ARPF has obtained the SUPI, the ARPF generates the HE AV and send it to the AUSF together with the SUPI and the GUSS.

S406a, S406I): The AUSF generate the AV and send it to the BSF together with the SUPI and GUSS. Instead of generating key K_SEAF, the AUSF generates the key K_BSF, which could be used as the GBA master key (Ks) or the GBA master key can be generated from it.

Alternatively, the AVs generated by the AUSF could be similar, or identical, to 4G authentication vectors, without the need for verifying both hash of RES (by BSF) and RES (by the AUSF). In this case the BSF would obtain a regular 4G AV and it would be used as is done in LTE networks. Also, the SUPI would be included already at this stage. In this case steps S410 and S411 below would be simplified to the BSF verifying the RES. S407: The BSF uses the RAND and AUTN in the AVs received from the AUSF to generate an HTTP 401 response with the HTTP header containing algorithm=5G-AKA" indicating that 5G AKA authentication needs to be run.

S408: The UE upon receiving the message transmitted by the BSF in step S407 verifies the AUTN and thereby authenticates the network. The UE also responds to the authentication challenge, thus generating RES, K_AUSF, and K_BSF.

S409: The UE responds to the digest challenge using SUCI as username and password from AKA and provides the RES to the BSF.

S4ioa, S4iob: The BSF verifies that RES hashes as expected and forwards RES to the AUSF.

S4iia, S4iib: The AUSF verifies RES and provides the BSF with a success indication and the SUPI.

S412: The BSF provides the UE with B-TID and lifetime of the GBA bootstrapping context (i.e. how long the UE is allowed to use the B-TID) in an HTTP 200 OK message. The BSF and the UE now share the GBA master key, K s.

8413a, S4i3b: The UE generates a NAF specific key, Ks_NAF, establishes a connection to the NAF, and performs digest authentication using B-TID as username and Ks_NAF as password.

S414: The NAF obtains the key Ks_NAF based on the B-TID from the BSF over a mutually authenticated and secure channel.

S415: The NAF verifies the UE provided digest and responds with HTTP 200 OK.

S416: The NAF and the UE share Ks_NAF and can establish a secure connection. A second particular embodiment for authentication and key agreement between the network and the UE 200 based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram of Fig. 7. The number of messages is the same in Figs. 6 and 7, but in Fig. 7 the UE only communicates with the NAF. The UE may reveal the SUCI to the NAF as it is encrypted with the public key of the home operator and does thus not reveal the permanent identity of the UE.

S501: The UE contacts the NAF by sending an HTTP GET message for the resource which the UE wishes to access. Step S501 and step S502 can be skipped if the UE knows that the NAF supports GBA, in which case the procedure would start from step S503.

S502: The NAF replies to the UE with an HTTP 401 Unauthorized with WWW- Authenticate message, indicating that the NAF 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.

S503: The UE resends the HTTP GET, including its SUCI as username. The SUCI contains information identifying the home operator, as only part of the SUCI is encrypted; the fields Mobile Country Code (MCC) and Mobile Network Code (MNC) are not encrypted. The NAF has a trust relationship with at least one mobile network operator, and GBA allows for roaming type of trust chaining through the use of so-called Zn-proxies. The NAF sends a request for bootstrapping, or Ks_NAF, to its trusted mobile network operator (MNO), which through Zn-proxies and roaming agreements forwards the request to the target BSF. Thus, a NAF can always forward a GBA

bootstrapping request to its trusted BSF, which will be able to reach the target BSF through the Zn-proxies. However, the NAF does not necessarily understand the MCC and MNC codes and will thus not be able to identify the target BSF. Optionally, the UE might modify the SUCI before including it in the bootstrapping request to include the URL of the BSF, similar to the B- TID, such that SUCI:= SUCI@bsf.com. However, the NAF will in this embodiment anyway forward the request to a BSF it has a trust relationship with even if it can identify the target BSF from the SUCI. One benefit of including the uniform resource locator of the BSF is that the NAF can identify the BSF and a NAF with multiple trusted BSFs/MNOs can identify the correct one to contact in case the indicated BSF is one of the BSFs/MNOs trusted by the NAF.

S504: Based on the mobile network operator information (i.e., bsf.com) included in the request the NAF sends a request containing the SUCI (with or without the bsf.com suffix) towards a trusted BSF over a mutually

authenticated secure channel as in GBA typically. The interface between NAF and BSF might be implemented as RESTful (where REST is short for

Representational State Transfer) application programming interfaces (APIs) running the Hypertext Transfer Protocol (HTTP) version 1.1 or HTTP version 2.0 over the Transport Layer Security (TLS) protocol. If not the actual target BSF, the request is forwarded via Zn-proxies to the target BSF (assuming roaming agreements make this possible).

S505: The BSF forwards the SUCI (without suffix) to the AUSF.

S506a, S506b, S506C, Sso6d, Sso6e: The AUSF forwards the SUCI to the ARPF, which in turn forwards the SUCI to the SIDF for obtaining the associated SUPI, which is returned to the ARPF. The ARPF generates the HE AVs and forwards them to the AUSF, which in turn generates regular AVs.

Alternatively, the AVs generated by the AUSF could be similar, or identical, to 4G authentication vectors, without the need for verifying both hash of RES (by BSF) and RES (by AUSF). In this case the BSF would obtain a regular 4G AV and it would be used as is done in LTE networks. Also, the SUPI would be included already at this stage. In this case steps S511 and S512 below would be simplified to the BSF verifying the RES.

S507: The AUSF, instead of deriving K_SEAF, derives K_BSF and then forwards the AV to the BSF. S508: The BSF replies to the NAF with RAND and AUTN.

S509: The NAF replies to the UE with an HTTP 401 message that includes RAND and AUTN.

Ssioa, S5iob: The UE answers the AKA/ digest challenge and generates the corresponding key K_BSF (Ks) and uses this key to send a digest response using SUCI as username and RES as password.

S5iia, S5iib: The NAF forwards the result to the BSF, which verifies the hash of it.

S5i2a, S5i2b, S512C: The BSF forwards the result to the AUSF, which verifies the result. If successful, the AUSF indicates this to the BSF and includes the SUPI in the response to the BSF.

S513: The BSF generates B-TID and provides it, its lifetime, and Ks_NAF generated for the NAF to the NAF. This is an indication that the UE has been authenticated. S514: The NAF sends an HTTP 401 message to the UE, now including the B-

TID and lifetime. The UE could also itself generate the B-TID, so including the B-TID is optional.

8515a, S5i5b: The UE derives the key Ks_NAF and replies to the HTTP 401 message using the key Ks_NAF and with the received B-TID as username. S516: The NAF verifies the digest and replies with an HTTP 200 OK message.

S517: The UE and the NAF now share the key Ks_NAF and can establish a secure connection.

For future GBA based authentications the UE will use the B-TID as username as long as its lifetime is valid. The BSF will notice that the username used by the NAF in the key request is a still valid B-TID and can thus generate

Ks_NAF for the NAF without involving AUSF, etc. In case the B-TID is not valid, the BSF will indicate to the NAF that the username is not valid, which will trigger the NAF to send an HTTP 401 message to the UE, thus returning to step S501.

With respect to steps S406 and S506, the AV generation for GBA use could be further optimized. It is here assumed that the AUSF and BSF will reside in the same network and thus there is a trust between the two. The AUSF might therefore generate a special GBA AV that can be provided to the BSF. For this purpose a BSF key could be used.

The BSF key could be generated from the AUSF key, e.g. by

appending/prepending a string, such as“gba” and/or identity of the BSF, such as bsfi@operator.com, to the AUSF key and hashing the result using a key derivation function. The UE would have to generate the same BSF key in the same way for itself. The BSF key could be used directly as GBA master key (Ks) for generating NAF keys. Alternatively, the BSF key could be used for generating keys Ks by running the BSF key through a key derivation function with appropriate other input, such as a string“Ks”.

The 5G GBA AV sent to the BSF could be a regular 5G AV, but including the XRES parameter, and the BSF key. Then, the BSF could verify both HRES and XRES and then continue to use the BSF key for generating NAF keys. Verifying XRES would in this case be enough, which also means that HRES could be omitted from the AV. Alternatively, only HRES could be verified and XRES be omitted from the information sent to the BSF. The 5G GBA AV might contain the BSF key (generated by AUSF from the AUSF key) and the hash of the expected result (HXRES) which are provided to the BSF together with the other relevant AV parameters, but excluding the HRES. The BSF then verifies the received result against the HXRES in the AV and uses the BSF key as Ks.

A third particular embodiment for authentication and key agreement between the network and the UE 200 based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram of Fig. 8. Here the authentications to the BSF on the one hand and NAF on the other hand is combined, thus reducing the number of messages needed.

S6oi: The UE contacts the NAF by sending an HTTP GET message for the resource which the UE wishes to access. Step S6oi and step S602 can be skipped if the UE knows that the NAF supports GBA, in which case the procedure would start from step S603.

S602: The NAF replies to the UE with an HTTP 401 Unauthorized with WWW-Authenticate message, indicating that the NAF requires digest authentication for access to that resource. The HTTP response header also contains the realm prefixed (e.g., with”3GPP-Bootstrapping@”,“3GPP-5G- Bootstrapping”, or“5G-GBA”, etc.) to indicate that a GBA run can be performed to obtain the appropriate keys for digest authentication.

S603: The UE resends the HTTP GET, including its SUCI as username. The SUCI contains information identifying the home operator, as only part of the SUCI is encrypted; the fields Mobile Country Code (MCC) and Mobile

Network Code (MNC) are not encrypted. The NAF has a trust relationship with at least one mobile network operator, and GBA allows for roaming type of trust chaining through the use of Zn-proxies. The NAF sends a request for bootstrapping, or Ks_NAF, to its trusted mobile network operator (MNO), which, when needed, through Zn-proxies and roaming agreements forwards the request to the target BSF. Thus, a NAF can always forward a GBA bootstrapping request to its trusted BSF, which will be able to reach the target BSF through the Zn-proxies. However, the NAF does not necessarily understand the MCC and MNC codes and will thus not be able to identify the target BSF. Optionally, the UE might modify the SUCI before including it in the bootstrapping request to include the URL of the BSF, similar to the B- TID, such that SUCI:= SUCI@bsf.com. However, the NAF will in this embodiment anyway forward the request to a BSF it has a trust relationship with even if it can identify the target BSF from the SUCI. One benefit of including the uniform resource locator of the BSF is that the NAF can identify the BSF and a NAF with multiple trusted BSFs/MNOs can identify the correct one to contact in case the indicated BSF is one of the BSFs/MNOs trusted by the NAF.

S604: Based on the mobile network operator information (i.e., bsf.com) included in the request the NAF sends a request containing the SUCI (with or without the bsf.com suffix) towards a trusted BSF over a mutually

authenticated secure channel as in GBA typically. The interface between NAF and BSF might be implemented as RESTful APIs running HTGR/1.1 or HTGR/2.0 over the TLS protocol. If not the actual target BSF, the request is forwarded via Zn-proxies to the target BSF (assuming roaming agreements make this possible).

S605: The BSF forwards the SUCI (without suffix) to the AUSF.

S6o6a, S6o6b, S6o6c, S6o6d, S6o6e: The AUSF forwards the SUCI to the ARPF, which in turn forwards the SUCI to the SIDF for obtaining the associated SUPI, which is returned to the ARPF. The ARPF generates the HE AVs and forwards them to the AUSF, which in turn generates regular AVs.

Alternatively, the AVs generated by the AUSF could be 4G authentication vectors, without the need for verifying both hash of RES (by BSF) and RES (by AUSF). In this case the BSF would obtain a regular 4G AV and it would be used as is done in LTE networks. Also, the SUPI would be included already at this stage. In this case step S613 below would be simplified to the BSF verifying the RES.

S607a, S607b: The AUSF, instead of deriving K_SEAF, derives K_BSF and then forwards the AV to the BSF.

S608: The BSF replies to the NAF with RAND and AUTN.

S609: The NAF replies to the UE with an HTTP 401 message that includes RAND and AUTN. S610: When the UE receives the HTTP 401 message with AUTH and RAND it answers the AKA challenge and thus derives K_BSF. In addition it derives Ks_NAF.

S6na: The UE answers the digest challenge using the RES resulting from AKA and with SUCI as username, and in addition creates a digital signature (keyed hash) using the key Ks_NAF. The signature is included in the digest response message.

S612: The NAF stores the received response message, and then forwards the result to the BSF for verification, as in steps S511-S512 above. S6i3a, S6i3b, S613C, S6i3d: Once the BSF receives an OK for the verification (either from the AUSF or performed by itself if 4G AV is used) the BSF can generate B-TID and Ks_NAF for the NAF that sent the request.

S614: The BSF provides the B-TID, its lifetime, and the key Ks_NAF to the NAF. S615: The NAF uses the received Ks_NAF for verifying the signature of the received digest response message from the UE.

S616: If successful, the NAF replies to the UE with an HTTP 200 OK message and includes the B-TID and its lifetime.

S617: The UE and the NAF now share the key Ks_NAF and can use it for securing their communication.

The optimization of the procedure in Fig. 8 saves, in comparison to the procedure in Fig. 7, one round-trip (i.e., two messages). This is possible by the BSF presumptively deriving and using the key Ks_NAF for signing (keyed hash/Message authentication code (MAC)) the message header it sends to the NAF. This signed message is later verified by the NAF once it receives the B- TID and Ks_NAF from the BSF. The correct verification of the signature guarantees that both the UE and the NAF know the correct Ks_NAF and can begin secure communication (typically by establishing a transport layer security session). In this scenario, the UE never explicitly sends its B-TID to the NAF. Instead the NAF uses the B-TID it receives from the BSF and might also, optionally, send it to the UE; the UE could generate B-TID on its own, but since the NAF anyways will send an HTTP 200 OK message to the UE, including the B-TID there does not consume much additional resources.

Further, the NAF in some aspects does not produce a challenge nor directly authenticate the UE. Instead the fact that the BSF provides the NAF with the key Ks_NAF might act as an implicit authentication of the UE at the NAF. While this further optimizes the procedure, it also potentially reduces the security as the NAF has to trust another node to perform the authentication without having the possibility to challenge the UE itself. However, the NAF can challenge the UE later, after the bootstrapping procedure, using some other protocol. The UE might then sign the challenge response destined for the BSF using Ks_NAF. Under the assumption that the NAF includes an opaque generated by itself in a non-predictive manner (or at least without re using the same opaque), the signature of the message, covering also the opaque replayed by the UE, is a form of challenge response; the UE operates on a parameter generated by the NAF using a key that the NAF can later verify.

Fig. 9 schematically illustrates, in terms of a number of functional units, the components of a UE 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 1510a (as in Fig. 15), 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 UE 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 UE 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 UE 200 may further comprise a communications interface 220 for communications with other entities, nodes, functions, and devices of the network 100. 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 UE 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 UE 200 are omitted in order not to obscure the concepts presented herein.

Fig. 10 schematically illustrates, in terms of a number of functional modules, the components of a UE 200 according to an embodiment. The UE 200 of Fig. 10 comprises a number of functional modules; a provide module 210a configured to perform step S102, an obtain module 210b configured to perform step S106, and a verify module 210c configured to perform step S106. The UE 200 of Fig. 10 may further comprise a number of optional functional modules, such as any of a provide module 2iod configured to perform step S108, an obtain module 2ioe configured to perform step S110, a derive module 2iof configured to perform step S112, and a provide module 2iog configured to perform step S114. In general terms, each functional module 2ioa-2iog may be implemented in hardware or in software.

Preferably, one or more or all functional modules 2ioa-2iog may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and 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-2iog and to execute these instructions, thereby performing any steps of the UE 200 as disclosed herein.

Fig. 11 schematically illustrates, in terms of a number of functional units, the components of a bootstrapping server function 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 1510b (as in Fig. 15), 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

bootstrapping server function 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 bootstrapping server function 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 bootstrapping server function 300 may further comprise a

communications interface 320 for communications with other entities, nodes, functions, and devices of the network 100. 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

bootstrapping server function 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 bootstrapping server function 300 are omitted in order not to obscure the concepts presented herein.

Fig. 12 schematically illustrates, in terms of a number of functional modules, the components of a bootstrapping server function 300 according to an embodiment. The bootstrapping server function 300 of Fig. 12 comprises a number of functional modules; an obtain module 310a configured to perform step S202, a provide module 310b configured to perform step S204, an obtain module 310c configured to perform step S206, and a provide module 3iod configured to perform step S208. The bootstrapping server function 300 of Fig. 12 may further comprise a number of optional functional modules, such as any of an obtain module 3ioe configured to perform step S110, an obtain module 3iof configured to perform step S112, a provide module 3iog configured to perform step S114, and a provide module 3ioh configured to perform step S116. In general terms, each functional module 3ioa-3ioh may be implemented in hardware or in software. Preferably, one or more or all functional modules 3ioa-3ioh may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and 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-3ioh and to execute these instructions, thereby performing any steps of the bootstrapping server function 300 as disclosed herein. Fig. 13 schematically illustrates, in terms of a number of functional units, the components of an AUSF 400 according to an embodiment. Processing circuitry 410 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 1510c (as in Fig. 15), e.g. in the form of a storage medium 430. The processing circuitry 410 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

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

The AUSF 400 may further comprise a communications interface 420 for communications with other entities, nodes, functions, and devices of the network 100. As such the communications interface 420 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 410 controls the general operation of the AUSF 400 e.g. by sending data and control signals to the communications interface 420 and the storage medium 430, by receiving data and reports from the communications interface 420, and by retrieving data and instructions from the storage medium 430. Other components, as well as the related functionality, of the AUSF 400 are omitted in order not to obscure the concepts presented herein.

Fig. 14 schematically illustrates, in terms of a number of functional modules, the components of an AUSF 400 according to an embodiment. The AUSF 400 of Fig. 14 comprises a number of functional modules; an obtain module 410a configured to perform step S302, a provide module 410b configured to perform step S304, and a provide module 4iod configured to perform step S308. The AUSF 400 of Fig. 14 may further comprise a number of optional functional modules, such as any of an obtain module 410c configured to perform step S306, an obtain module 4ioe configured to perform step S310, a verify module 4iof configured to perform step S312, and a provide module 4iog configured to perform step S314. In general terms, each functional module 4ioa-4iog may be implemented in hardware or in software.

Preferably, one or more or all functional modules 4ioa-4iog may be implemented by the processing circuitry 410, possibly in cooperation with the communications interface 420 and the storage medium 430. The processing circuitry 410 may thus be arranged to from the storage medium 430 fetch instructions as provided by a functional module 4ioa-4iog and to execute these instructions, thereby performing any steps of the AUSF 400 as disclosed herein.

The bootstrapping server function 300 and/or AUSF 400 may be provided as a standalone device or as a part of at least one further device. For example, the bootstrapping server function 300 and/or AUSF 400 may be provided in a node of the radio access network or in a node of the core network or even the service network. Alternatively, functionality of the bootstrapping server function 300 and/or AUSF 400 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 (such as the radio access network, the core network, or the service network) or may be spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to the cell than instructions that are not required to be performed in real time. Thus, a first portion of the instructions performed by the bootstrapping server function 300 and/or AUSF 400 may be executed in a first device, and a second portion of the of the instructions performed by the bootstrapping server function 300 and/or AUSF 400 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 bootstrapping server function 300 and/or AUSF 400 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a Bootstrapping server function 300 and/or AUSF 400 residing in a cloud computational environment. As an example, the bootstrapping server function 300 and/or AUSF 400 might be hosted in a cloud computational environment as network slices. Therefore, although a single processing circuitry 210, 310 is illustrated in Figs. 9 and 11 the processing circuitry 210, 310 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 3ioa-3ioh and 4ioa-4iog of Figs. 12 and 14 and the computer programs 1520b, 1520c of Fig. 15.

Fig. 15 shows one example of a computer program product 1510a, 1510b, 1510c comprising computer readable means 1530. On this computer readable means 1530, a computer program 1520a can be stored, which computer program 1520a 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 1520a and/or computer program product 1510a may thus provide means for performing any steps of the UE 200 as herein disclosed. On this computer readable means 1530, a computer program 1520b can be stored, which computer program 1520b 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 1520b and/or computer program product 1510b may thus provide means for performing any steps of the bootstrapping server function 300 as herein disclosed. On this computer readable means 1530, a computer program 1520c can be stored, which computer program 1520c can cause the processing circuitry 410 and thereto operatively coupled entities and devices, such as the communications interface 420 and the storage medium 430, to execute methods according to embodiments described herein. The computer program 1520c and/or computer program product 1510c may thus provide means for performing any steps of the AUSF 400 as herein disclosed.

In the example of Fig. 15, the computer program product 1510a, 1510b, 1510c 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 1510a, 1510b, 1510c 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 1520a, 1520b, 1520c is here schematically shown as a track on the depicted optical disk, the computer program 1520a, 1520b, 1520c can be stored in any way which is suitable for the computer program product 1510a, 1510b, 1510c. 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 appended patent claims.

Claims

1. A method for establishing authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier the method being performed by the UE (200), the method comprising:

providing (S102), towards a bootstrapping server function, (300), of the network of the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

obtaining (S104), from the bootstrapping server function (300), a response message to the request message, the response message comprising a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV, the AV having been generated based on the Identifier; and

verifying (S106) the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an authentication server function, AUSF (400), of the network of the UE (200).

2. The method according to claim 1, wherein the Identifier provided towards the bootstrapping server function (300) is a Subscription Concealed Identifier, SUCI, encrypted with a public key of the network.

3. The method according to claim 1 or 2, wherein the request message as provided towards the bootstrapping server function (300) is a first HTTP GET message.

4. The method according to any of the preceding claims, wherein the response message as obtained from the bootstrapping server function (300) is an HTTP Unauthorized message.

5. The method according to any of the preceding claims, wherein the response message as obtained from the bootstrapping server function (300) indicates that authentication and key agreement, AKA, authentication needs to be run between the UE (200) and the bootstrapping server function (300).

6. The method according to any of the preceding claims, wherein the derivation of the bootstrapping server function key is based on K_AUSF and a string identifying purpose of the key derivation, and/or identity of the bootstrapping server function (300), and/or a freshness parameter.

7. The method according to any of the preceding claims, further comprising:

providing (S108), towards the bootstrapping server function (300), a second HTTP GET message with the Identifier as username and a response authentication parameter calculated using a user response, RES, as the password obtained from running authentication and key agreement.

8. The method according to any of the preceding claims, further comprising:

obtaining (S110), from the bootstrapping server function (300), an OK message comprising a bootstrapping transaction identifier, B-TID.

9. The method according to any of the preceding claims, further comprising:

deriving (S112) a network application function, NAF, specific key, Ks_NAF.

10. The method according to any of the preceding claims, further comprising:

providing (S114), to a network application function, NAF, a third HTTP GET message with the B-TID as username and using the NAF specific key as password.

11. The method according to any of the preceding claims, wherein all messages communicated between the UE (200) and the bootstrapping server function (300) are sent via a network application function, NAF.

12. The method according to claim 11, wherein the Identifier as provided to the bootstrapping server function (300) via the NAF comprises unencrypted information identifying the network.

13. The method according to claim 7, wherein the second HTTP GET message is signed with the NAF specific key, Ks_NAF.

14. The method according to any of the preceding claims, wherein the AV has been generated from a home environment authentication vector, HE AV, based on the Identifier.

15. A method for enabling establishment of authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the method being performed by a bootstrapping server function (300), the method comprising:

obtaining (S202), from the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

providing (S204), to an authentication server function, AUSF (400), of the network of the UE (200), the Identifier;

obtaining (S206), from the AUSF (400), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being generated based on the Identifier; and

providing (S208), towards the UE (200), a response message to the request message, the response message comprising the RAND and the AUTN of the AV.

16. The method according to claim 15, wherein the Identifier as obtained from the UE (200) is a Subscription Concealed Identifier, SUCI, encrypted with a public key of the network.

17. The method according to claim 15 or 16, wherein the request message as obtained from the UE (200) is a first HTTP GET message.

18. The method according to any of claims 15 to 17, wherein the response message as provided towards the UE (200) is an HTTP Unauthorized message.

19. The method according to any of claims 15 to 18, wherein the response message as provided towards the UE (200) indicates that authentication and key agreement, AKA, authentication needs to be run between the UE (200) and the bootstrapping server function (300).

20. The method according to any of claims 15 to 19, further comprising: obtaining (S210), from the UE (200), a second HTTP GET message with the Identifier as username and a response authentication parameter calculated using a user response, RES, as the password obtained from running authentication and key agreement.

21. The method according to claim 20, further comprising:

obtaining (S212) verification of an expected user response, XRES, based on the RES obtained from the UE (200).

22. The method according to claim 21, wherein the verification is obtained by the bootstrapping server function (300) itself verifying the XRES.

23. The method according to claim 21, wherein the verification is obtained by the bootstrapping server function (300) itself verifying a hashed user response, HRES, wherein the RES is provided to the AUSF (400) for verification of the XRES, and wherein a success response thereof is obtained from the AUSF (400).

24. The method according to any of claims 15 to 23, further comprising: providing (S214), towards the UE (200), an OK message comprising a bootstrapping transaction identifier, B-TID.

25. The method according to any of claims 15 to 24, further comprising: providing (S216), towards a network application function, NAF, a NAF specific key, Ks_NAF.

26. The method according to any of claims 15 to 25, wherein all messages communicated between the UE (200) and the bootstrapping server function (300) are sent via a network application function, NAF.

27. The method according to claim 26, wherein the Identifier as obtained from the UE (200) via the NAF comprises unencrypted information identifying the network.

28. The method according to any of claims 15 to 27 wherein the AV is generated from a home environment authentication vector, HE AV, the HE AV having been generated based on the Identifier, and a bootstrapping server function key, K_BSF, the bootstrapping server function key being derived from a key, K_AUSF, of the AUSF (400).

29. A method for enabling establishment of authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the method being performed by an authentication server function, AUSF, (400), of the network of the UE (200), the method comprising:

obtaining (S302), from a bootstrapping server function (300), of the network of the UE (200), the Identifier;

providing (S304), to an ARPF of the network of the UE (200), the Identifier in order for the AUSF (400) to obtain a permanent identifier of the Identifier; and

providing (S308), to the bootstrapping server function (300), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE (200).

30. The method according to claim 29, further comprising:

obtaining (S310), from the bootstrapping server function (300), a user response, RES, of the UE (200);

verifying (S312) an expected user response, XRES, of the UE (200) based on the RES; and

providing (S314) a success response of the verified XRES and the Identifier to the bootstrapping server function (300) in response to having successfully verified the XRES.

31. The method according to claim 29 or 31, wherein the derivation of the bootstrapping server function key is based on K_AUSF and a string identifying purpose of the key derivation, and/or identity of the

bootstrapping server function (300), and/or a freshness parameter.

32. The method according to any of claims 29 to 31, further comprising: obtaining (S306), from the ARPF, a home environment authentication vector, HE AV, for the UE (200), where the HE AV is generated based on the Identifier; and

wherein the AV is generated from the HE AV, and a bootstrapping server function key, K_BSF, the bootstrapping server function key being derived from a key, K_AUSF, of the AUSF (400).

33. The method according to claim 32, wherein the HE AV is obtained together with the Identifier and generic bootstrapping architecture user security settings, GUSS, for the UE (200).

34. A user equipment, UE, (200) for establishing authentication and key agreement between a network and the UE (200), the UE (200) having an Identity and comprising processing circuitry (210), the processing circuitry being configured to cause the UE (200) to:

provide, towards a bootstrapping server function, (300), of the network of the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

obtain, from the bootstrapping server function (300), a response message to the request message, the response message comprising a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV, the AV having been generated based on the Identifier; and

verify the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an authentication server function, AUSF (400), of the network of the UE (200).

35. A user equipment, UE, (200) for establishing authentication and key agreement between a network and the UE (200), the UE (200) having an Identity and comprising:

a provide module (210a) configured to provide, towards a bootstrapping server function, (300), of the network of the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

an obtain module (210b) configured to obtain, from the bootstrapping server function (300), a response message to the request message, the response message comprising a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV, the AV having been generated based on the Identifier; and

a verify module (210c) configured to verify the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an authentication server function, AUSF (400), of the network of the UE (200).

36. A bootstrapping server function (300) for enabling establishment of authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the bootstrapping server function (300) comprising processing circuitry (310), the processing circuitry being configured to cause the bootstrapping server function (300) to:

obtain, from the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

provide, to an authentication server function, AUSF (400), of the network of the UE (200), the Identifier;

obtain, from the AUSF (400), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being generated based on the Identifier; and

provide, towards the UE (200), a response message to the request message, the response message comprising the RAND and the AUTN of the AV.

37. A bootstrapping server function (300) for enabling establishment of authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the bootstrapping server function (300) comprising:

an obtain module (310a) configured to obtain, from the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

a provide module (310b) configured to provide, to an authentication server function, AUSF (400), of the network of the UE (200), the Identifier; an obtain module (310c) configured to obtain, from the AUSF (400), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being generated based on the Identifier; and

a provide module (3iod) configured to provide, towards the UE (200), a response message to the request message, the response message comprising the RAND and the AUTN of the AV.

38. An authentication server function, AUSF, (400) for enabling

establishment of authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the AUSF (400) comprising processing circuitry (410), the processing circuitry being configured to cause the AUSF (400) to:

obtain, from a bootstrapping server function (300), of the network of the UE (200), the Identifier;

provide, to an ARPF of the network of the UE (200), the Identifier in order for the AUSF (400) to obtain a permanent identifier of the Identifier; and

provide, to the bootstrapping server function (300), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE (200).

39. An authentication server function, AUSF, (400) for enabling

establishment of authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the AUSF (400) comprising:

an obtain module (410a) configured to obtain, from a bootstrapping server function (300), of the network of the UE (200), the Identifier;

a provide module (410b) configured to provide, to an ARPF of the network of the UE (200), the Identifier in order for the AUSF (400) to obtain a permanent identifier of the Identifier; and

a provide module (4iod) configured to provide, to the bootstrapping server function (300), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE (200).

40. A computer program (1520a) for establishing authentication and key agreement between a network and a user equipment, UE, (200), the UE having and Identity, the computer program comprising computer code which, when run on processing circuitry (210) of the UE (200), causes the UE (200) to:

provide (S102), towards a bootstrapping server function, (300), of the network of the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

obtain (S104), from the bootstrapping server function (300), a response message to the request message, the response message comprising a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV, the AV having been generated based on the Identifier; and

verify (S106) the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an authentication server function, AUSF (400), of the network of the UE (200).

41. A computer program (1520b) for enabling establishment of

authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the computer program comprising computer code which, when run on processing circuitry (310) of a bootstrapping server function (300), causes the bootstrapping server function (300) to:

obtain (S202), from the UE (200), a request message with the Identifier of the UE (200) as username, as part of bootstrapping of the UE (200);

provide (S204), to an authentication server function, AUSF (400), of the network of the UE (200), the Identifier;

obtain (S206), from the AUSF (400), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being generated based on the Identifier; and

provide (S208), towards the UE (200), a response message to the request message, the response message comprising the RAND and the AUTN of the AV.

42. A computer program (1520c) for enabling establishment of

authentication and key agreement between a network and a user equipment, UE, (200), the UE (200) having an Identifier, the computer program comprising computer code which, when run on processing circuitry (410) of an authentication server function, AUSF, (400), causes the AUSF (400) to: obtain (S302), from a bootstrapping server function (300), of the network of the UE (200), the Identifier;

provide (S304), to an ARPF of the network of the UE (200), the

Identifier in order for the AUSF (400) to obtain a permanent identifier of the Identifier; and

provide (S308), to the bootstrapping server function (300), an authentication vector, AV, the AV comprising a challenge, RAND, and an authentication token, AUTN, and being based on the Identifier, for provision of the RAND and the AUTN of the AV to the UE (200).

43. A computer program product (1510a, 1510b, 1510c) comprising a computer program (1520a, 1520b, 1520c) according to at least one of claims 40, 41 and 42, and a computer readable storage medium (1530) on which the computer program is stored.