6.1 Primary authentication and key agreement

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1.1 Authentication framework

6.1.1.1 General

The purpose of the primary authentication and key agreement procedures is to enable mutual authentication between the UE and the network and provide keying material that can be used between the UE and the serving network in subsequent security procedures. The keying material generated by the primary authentication and key agreement procedure results in an anchor key called the K_SEAF provided by the AUSF of the home network to the SEAF of the serving network.

Keys for more than one security context can be derived from the K_SEAF without the need of a new authentication run. A concrete example of this is that an authentication run over a 3GPP access network can also provide keys to establish security between the UE and a N3IWF used in untrusted non-3GPP access.

The anchor key K_SEAF is derived from an intermediate key called the K_AUSF. The K_AUSF is established between the UE and HN resulting from the primary authentication procedure. The K_AUSF may be securely stored in the AUSF based on the home operator’s policy on using such key e.g. if the control plane solution for Steering of Roaming (see clause 6.14) or UE Parameter Update procedures (see clause 6.15) or AKMA are supported by the HPLMN.

NOTE A: For standalone non-public networks when an authentication method other than 5G AKA or EAP-AKA’ is used, Annex I.2 applies.

NOTE 1: This feature is an optimization that might be useful, for example, when a UE registers to different serving networks for 3GPP-defined access and untrusted non-3GPP access (this is possible according to TS 23.501 [2]). The details of this feature are operator-specific and not in scope of this document.

NOTE 2: A subsequent authentication based on the K_AUSF stored in the AUSF gives somewhat weaker guarantees than an authentication directly involving the ARPF and the USIM. It is rather comparable to fast re-authentication in EAP-AKA’.

NOTE 2a: Void.

UE and serving network shall support EAP-AKA’ and 5G AKA authentication methods.

NOTE 2b: It is the home operator’s decision which authentication method is selected.

The USIM shall reside on a UICC. The UICC may be removable or non-removable.

NOTE 3: For non-3GPP access networks USIM applies in case of terminal with 3GPP access capabilities.

If the terminal supports 3GPP access capabilities, the credentials used with EAP-AKA’ and 5G AKA for non-3GPP access networks shall reside on the UICC.

NOTE 4: EAP-AKA’ and 5G AKA are the only authentication methods that are supported in UE and serving network, hence only they are described in sub-clause 6.1.3 of the present document. For a private network using the 5G system as specified in [7] an example of how additional authentication methods can be used with the EAP framework is given in the informative Annex B.

NOTE 5: For non-public network (NPN) security the Annex I of the present document provides details.

Upon successful completion of the 5G AKA primary authentication, the AMF shall initiate NAS security mode command procedure (see clause 6.7.2) with the UE.

NOTE 6: The reason to mandatory run the NAS SMC procedure after primary authentication is because the UE does not store the new derived K_AUSF until receiving the NAS SMC message. The new partial native NAS security context is taken into use. It is specified in clause 6.9.4.4 whether AS key re-keying is performed.

6.1.1.2 EAP framework

The EAP framework is specified in RFC 3748 [27]. It defines the following roles: peer, pass-through authenticator and back-end authentication server. The back-end authentication server acts as the EAP server, which terminates the EAP authentication method with the peer. In the 5G system, the EAP framework is supported in the following way:

– The UE takes the role of the peer.

– The SEAF takes the role of pass-through authenticator.

– The AUSF takes the role of the backend authentication server.

6.1.1.3 Granularity of anchor key binding to serving network

The primary authentication and key agreement procedures shall bind the K_SEAF to the serving network. The binding to the serving network prevents one serving network from claiming to be a different serving network, and thus provides implicit serving network authentication to the UE.

This implicit serving network authentication shall be provided to the UE irrespective of the access network technology, so it applies to both 3GPP and non-3GPP access networks.

Furthermore, the anchor key provided to the serving network shall also be specific to the authentication having taken place between the UE and a 5G core network, i.e. the K_SEAF shall be cryptographically separate from the key K_ASME delivered from the home network to the serving network in earlier mobile network generations.

The anchor key binding shall be achieved by including a parameter called "serving network name" into the chain of key derivations that leads from the long-term subscriber key to the anchor key.

The value of serving network name is defined in sub-clause 6.1.1.4 of the present document.

The chain of key derivations that leads from the long-term subscriber key to the anchor key is specified in sub-clause 6.1.3 of the present document for each (class) of authentication methods. The key derivation rules are specified in Annex A.

NOTE: No parameter like ‘access network type’ is used for anchor key binding as 5G core procedures are supposed to be access network agnostic.

6.1.1.4 Construction of the serving network name

6.1.1.4.1 Serving network name

The serving network name is used in the derivation of the anchor key. It serves a dual purpose, namely:

– It binds the anchor key to the serving network by including the serving network identifier (SN Id).

– It makes sure that the anchor key is specific for authentication between a 5G core network and a UE by including a service code set to "5G".

In 5G AKA, the serving network name has a similar purpose of binding the RES* and XRES* to the serving network.

The serving network name is the concatenation of a service code and the SN Id with a separation character ":" such that the service code prepends the SN Id.

NOTE: No parameter like ‘access network type’ is used for serving network name as it relates to a 5G core procedure that is access network agnostic.

The SN Id identifies the serving PLMN and, except for standalone non-public networks, is defined as SNN-network-identifier in TS 24.501[35].

NOTE 1: For standalone non-public networks, the definition of SN Id is given in Annex I.3.

6.1.1.4.2 Construction of the serving network name by the UE

The UE shall construct the serving network name as follows:

– It shall set the service code to "5G".

– It shall set the network identifier to the SN Id of the network that it is authenticating to.

– Concatenate the service code and the SN Id with the separation character ":".

6.1.1.4.3 Construction of the serving network name by the SEAF

The SEAF shall construct the serving network name as follows:

– It shall set the service code to "5G".

– It shall set the network identifier to the SN Id of the serving network to which the authentication data is sent by the AUSF.

– It shall concatenate the service code and the SN Id with the separation character ":".

NOTE: AUSF gets the serving network name from the SEAF. Before using the serving network name, AUSF checks that the SEAF is authorized to use it, as specified in clause 6.1.2.

6.1.2 Initiation of authentication and selection of authentication method

The initiation of the primary authentication is shown in Figure 6.1.2-1.

Figure 6.1.2-1: Initiation of authentication procedure and selection of authentication method

The SEAF may initiate an authentication with the UE during any procedure establishing a signalling connection with the UE, according to the SEAF’s policy. The UE shall use SUCI or 5G-GUTI in the Registration Request.

The SEAF shall invoke the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate Request message to the AUSF whenever the SEAF wishes to initiate an authentication.

The Nausf_UEAuthentication_Authenticate Request message shall contain either:

– SUCI, as defined in the current specification, or

– SUPI, as defined in TS 23.501 [2].

The SEAF shall include the SUPI in the Nausf_UEAuthentication_Authenticate Request message in case the SEAF has a valid 5G-GUTI and re-authenticates the UE. Otherwise the SUCI is included in Nausf_UEAuthentication_Authenticate Request. SUPI/SUCI structure is part of stage 3 protocol design.

The Nausf_UEAuthentication_Authenticate Request shall furthermore contain:

– the serving network name, as defined in sub-clause 6.1.1.4 of the present document.

NOTE 2: The local policy for the selection of the authentication method does not need to be on a per-UE basis, but can be the same for all UEs.

The Nausf_UEAuthentication_Authenticate Request may furthermore contain:

– Disaster Roaming service indication, as specified in TS 23.502[8] clause 4.2.2.2.

Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the AUSF shall check that the requesting SEAF in the serving network is entitled to use the serving network name in the Nausf_UEAuthentication_Authenticate Request by comparing the serving network name with the expected serving network name. The AUSF shall store the received serving network name temporarily. If the serving network is not authorized to use the serving network name, the AUSF shall respond with "serving network not authorized" in the Nausf_UEAuthentication_Authenticate Response.

NOTE 2: The AUSF and the UDM may be configured with Disaster Condition via OAM based on operator policy and the request by the government agencies.

For the Disaster Roaming, the AUSF shall check the local configuration and, if allowed, the AUSF sends Nudm_UEAuthentication_Get Request to the UDM.

The Nudm_UEAuthentication_Get Request sent from AUSF to UDM includes the following information:

– SUCI or SUPI;

– the serving network name;

– if received from SEAF, Disaster Roaming service indication;

Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall invoke SIDF if a SUCI is received. SIDF shall de-conceal SUCI to gain SUPI before UDM can process the request.

Based on SUPI, the UDM/ARPF shall choose the authentication method.

NOTE 3: The Nudm_UEAuthentication_Get Response in reply to the Nudm_UEAuthentication_Get Request and the Nausf_UEAuthentication_Authenticate Response message in reply to the Nausf_UEAuthentication_Authenticate Request message are described as part of the authentication procedures in clause 6.1.3.

For the Disaster Roaming, the UDM shall check the local configuration and, if allowed, the UDM proceeds with the chosen authentication method.

6.1.3 Authentication procedures

6.1.3.1 Authentication procedure for EAP-AKA’

EAP-AKA’ is specified in RFC 5448 [12]. The 3GPP 5G profile for EAP-AKA’ is specified in the normative Annex F.

The selection of using EAP-AKA’ is described in sub-clause 6.1.2 of the present document.

Figure 6.1.3.1-1: Authentication procedure for EAP-AKA’

The authentication procedure for EAP-AKA’ works as follows, cf. also Figure 6.1.3.1-1:

1. The UDM/ARPF shall first generate an authentication vector with Authentication Management Field (AMF) separation bit = 1 as defined in TS 33.102 [9]. The UDM/ARPF shall then compute CK’ and IK’ as per the normative Annex A and replace CK and IK by CK’ and IK’.

2. The UDM shall subsequently send this transformed authentication vector AV’ (RAND, AUTN, XRES, CK’, IK’) to the AUSF from which it received the Nudm_UEAuthentication_Get Request together with an indication that the AV’ is to be used for EAP-AKA’ using a Nudm_UEAuthentication_Get Response message.

NOTE: The exchange of a Nudm_UEAuthentication_Get Request message and an Nudm_UEAuthentication_Get Response message between the AUSF and the UDM/ARPF described in the preceding paragraph is the same as for trusted access using EAP-AKA’ described in TS 33.402 [11], sub-clause 6.2, step 10, except for the input parameter to the key derivation, which is the value of <network name>. The "network name" is a concept from RFC 5448 [12]; it is carried in the AT_KDF_INPUT attribute in EAP-AKA’. The value of <network name> parameter is not defined in RFC 5448 [12], but rather in 3GPP specifications. For EPS, it is defined as "access network identity" in TS 24.302 [71], and for 5G, it is defined as "serving network name" in sub-clause 6.1.1.4 of the present document.

In case SUCI was included in the Nudm_UEAuthentication_Get Request, UDM will include the SUPI in the Nudm_UEAuthentication_Get Response.

If a subscriber has an AKMA subscription, the UDM shall include the AKMA indication and Routing indicator in the Nudm_UEAuthentication_Get Response.

3. The AUSF shall send the EAP-Request/AKA’-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message.

4. The SEAF shall transparently forward the EAP-Request/AKA’-Challenge message to the UE in a NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in EAP-Request/AKA’-Challenge message to the USIM. This message shall include the ngKSI and ABBA parameter. In fact, SEAF shall include the ngKSI and ABBA parameter in all EAP-Authentication request message. The ngKSI will be used by the UE and AMF to identify the partial native security context that is created if the authentication is successful. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During an EAP authentication, the value of the ngKSI and the ABBA parameter sent by the SEAF to the UE shall not be changed.

NOTE 1: The SEAF needs to understand that the authentication method used is an EAP method by evaluating the type of authentication method based on the Nausf_UEAuthentication_Authenticate Response message.

5. At receipt of the RAND and AUTN, the USIM shall verify the freshness of the AV’ by checking whether AUTN can be accepted as described in TS 33.102 [9]. If so, the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102 [9], and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME shall derive CK’ and IK’ according to Annex A.3.

If the verification of the AUTN fails on the USIM, then the USIM and ME shall proceed as described in sub-clause 6.1.3. 3.

6. The UE shall send the EAP-Response/AKA’-Challenge message to the SEAF in a NAS message Auth-Resp message.

7. The SEAF shall transparently forward the EAP-Response/AKA’-Challenge message to the AUSF in Nausf_UEAuthentication_Authenticate Request message.

8. The AUSF shall verify the message by comparing the XRES and RES, and if the AUSF has successfully verified this message it shall continue as follows, otherwise it shall return an error to the SEAF. AUSF shall inform UDM about the authentication result (see sub-clause 6.1.4 of the present document for details on linking authentication confirmation).

9. The AUSF and the UE may exchange EAP-Request/AKA’-Notification and EAP-Response /AKA’-Notification messages via the SEAF. The SEAF shall transparently forward these messages.

NOTE 2: EAP Notifications as described in RFC 3748 [27] and EAP-AKA Notifications as described in RFC 4187 [21] can be used at any time in the EAP-AKA exchange. These notifications can be used e.g. for protected result indications or when the EAP server detects an error in the received EAP-AKA response.

10. The AUSF derives EMSK from CK’ and IK’ as described in RFC 5448[12] and Annex F. The AUSF uses the most significant 256 bits of EMSK as the K_AUSF and then calculates K_SEAF from K_AUSF as described in clause A.6. The AUSF shall send an EAP Success message to the SEAF inside Nausf_UEAuthentication_Authenticate Response, which shall forward it transparently to the UE. Nausf_UEAuthentication_Authenticate Response message contains the K_SEAF. If the AUSF received a SUCI from the SEAF when the authentication was initiated (see sub-clause 6.1.2 of the present document), then the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message. The AUSF stores the K_AUSF based on the home network operator’s policy according to clause 6.1.1.1.

NOTE 3: For lawful interception, the AUSF sending SUPI to SEAF is necessary but not sufficient. By including the SUPI as input parameter to the key derivation of K_AMF from K_SEAF, additional assurance on the correctness of SUPI is achieved by the serving network from both, home network and UE side.

11. The SEAF shall send the EAP Success message to the UE in the N1 message. This message shall also include the ngKSI and the ABBA parameter. The SEAF shall set the ABBA parameter as defined in Annex A.7.1.

NOTE 4: Step 11 could be NAS Security Mode Command or Authentication Result.

NOTE 5: The ABBA parameter is included to enable the bidding down protection of security features that may be introduced later.

The key received in the Nausf_UEAuthentication_Authenticate Response message shall become the anchor key, K_SEAF in the sense of the key hierarchy in sub-clause 6.2 of the present document. The SEAF shall then derive the K_AMF from the K_SEAF, the ABBA parameter and the SUPI according to Annex A.7 and send it to the AMF. On receiving the EAP-Success message, the UE derives EMSK from CK’ and IK’ as described in RFC 5448 and Annex F. The ME uses the most significant 256 bits of the EMSK as the K_AUSF and then calculates K_SEAF in the same way as the AUSF. The UE shall derive the K_AMF from the K_SEAF, the ABBA parameter and the SUPI according to Annex A.7.

NOTE 6: As an implementation option, the UE creates the temporary security context as described in step 11 after receiving the EAP message that allows EMSK to be calculated. The UE turns this temporary security context into a partial security context when it receives the EAP Success. The UE removes the temporary security context if the EAP authentication fails.

The further steps taken by the AUSF upon receiving a successfully verified EAP-Response/AKA’-Challenge message are described in sub-clause 6.1.4 of the present document.

If the EAP-Response/AKA’-Challenge message is not successfully verified, the subsequent AUSF behaviour is determined according to the home network’s policy.

If AUSF and SEAF determine that the authentication was successful, then the SEAF provides the ngKSI and the K_AMF to the AMF.

6.1.3.2 Authentication procedure for 5G AKA

6.1.3.2.0 5G AKA

5G AKA enhances EPS AKA [10] by providing the home network with proof of successful authentication of the UE from the visited network. The proof is sent by the visited network in an Authentication Confirmation message.

The selection of using 5G AKA is described in sub-clause 6.1.2 of the present document.

NOTE 1: 5G AKA does not support requesting multiple 5G AVs, neither the SEAF pre-fetching 5G AVs from the home network for future use.

Figure 6.1.3.2-1: Authentication procedure for 5G AKA

The authentication procedure for 5G AKA works as follows, cf. also Figure 6.1.3.2-1:

1. For each Nudm_Authenticate_Get Request, the UDM/ARPF shall create a 5G HE AV. The UDM/ARPF does this by generating an AV with the Authentication Management Field (AMF) separation bit set to "1" as defined in TS 33.102 [9]. The UDM/ARPF shall then derive K_AUSF (as per Annex A.2) and calculate XRES* (as per Annex A.4). Finally, the UDM/ARPF shall create a 5G HE AV from RAND, AUTN, XRES*, and K_AUSF.

2. The UDM shall then return the 5G HE AV to the AUSF together with an indication that the 5G HE AV is to be used for 5G AKA in a Nudm_UEAuthentication_Get Response. In case SUCI was included in the Nudm_UEAuthentication_Get Request, UDM will include the SUPI in the Nudm_UEAuthentication_Get Response after deconcealment of SUCI by SIDF.

If a subscriber has an AKMA subscription, the UDM shall include the AKMA indication and Routing indicator in the Nudm_UEAuthentication_Get Response.

3. The AUSF shall store the XRES* temporarily together with the received SUCI or SUPI.

4. The AUSF shall then generate the 5G AV from the 5G HE AV received from the UDM/ARPF by computing the HXRES* from XRES* (according to Annex A.5) and K_SEAF from K_AUSF(according to Annex A.6), and replacing the XRES* with the HXRES* and K_AUSF with K_SEAF in the 5G HE AV.

5. The AUSF shall then remove the K_SEAF and return the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response.

6. The SEAF shall send RAND, AUTN to the UE in a NAS message Authentication Request. This message shall also include the ngKSI that will be used by the UE and AMF to identify the K_AMF and the partial native security context that is created if the authentication is successful. This message shall also include the ABBA parameter. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. The ME shall forward the RAND and AUTN received in NAS message Authentication Request to the USIM.

NOTE 2: The ABBA parameter is included to enable the bidding down protection of security features.

7. At receipt of the RAND and AUTN, the USIM shall verify the freshness of the received values by checking whether AUTN can be accepted as described in TS 33.102[9]. If so, the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102 [9], and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then shall compute RES* from RES according to Annex A.4. The ME shall calculate K_AUSF from CK||IK according to clause A.2. The ME shall calculate K_SEAF from K_AUSF according to clause A.6. An ME accessing 5G shall check during authentication that the "separation bit" in the AMF field of AUTN is set to 1. The "separation bit" is bit 0 of the AMF field of AUTN.

NOTE 3: This separation bit in the AMF field of AUTN cannot be used anymore for operator specific purposes as described by TS 33.102 [9], Annex F.

8. The UE shall return RES* to the SEAF in a NAS message Authentication Response.

9. The SEAF shall then compute HRES* from RES* according to Annex A.5, and the SEAF shall compare HRES* and HXRES*. If they coincide, the SEAF shall consider the authentication successful from the serving network point of view. If not, the SEAF proceed as described in sub-clause 6.1.3.2.2. If the UE is not reached, and the RES* is never received by the SEAF, the SEAF shall consider authentication as failed, and indicate a failure to the AUSF.

10. The SEAF shall send RES*, as received from the UE, in a Nausf_UEAuthentication_Authenticate Request message to the AUSF.

11. When the AUSF receives as authentication confirmation the Nausf_UEAuthentication_Authenticate Request message including a RES* it may verify whether the 5G AV has expired. If the 5G AV has expired, the AUSF may consider the authentication as unsuccessful from the home network point of view. Upon successful authentication, the AUSF stores the K_AUSFbased on the home network operator’s policy according to clause 6.1.1.1. AUSF shall compare the received RES* with the stored XRES*. If the RES* and XRES* are equal, the AUSF shall consider the authentication as successful from the home network point of view. AUSF shall inform UDM about the authentication result (see sub-clause 6.1.4 of the present document for linking with the authentication confirmation).

NOTE 4: It is left to implementation to temporarily store the K_AUSF received in step 2 in AUSF until the RES* verification is done successfully (i.e., at step 11).

12. The AUSF shall indicate to the SEAF in the Nausf_UEAuthentication_Authenticate Response whether the authentication was successful or not from the home network point of view. If the authentication was successful, the K_SEAF shall be sent to the SEAF in the Nausf_UEAuthentication_Authenticate Response. In case the AUSF received a SUCI from the SEAF in the authentication request (see sub-clause 6.1.2 of the present document), and if the authentication was successful, then the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message.

If the authentication was successful, the key K_SEAF received in the Nausf_UEAuthentication_Authenticate Response message shall become the anchor key in the sense of the key hierarchy as specified in sub-clause 6.2 of the present document. Then the SEAF shall derive the K_AMF from the K_SEAF, the ABBA parameter and the SUPI according to Annex A.7. The SEAF shall provide the ngKSI and the K_AMF to the AMF. If the AUSF indicates that the authentication was successful from the home network point of view, then the AMF shall initiate NAS security mode command procedure (see clause 6.7.2) with the UE, to take the newly generated partial native 5G NAS security context into use. Upon receiving the valid NAS Security Mode Command message from the AMF, the UE shall consider the performed primary authentication as successful.

If a SUCI was used for this authentication, then the SEAF shall only provide ngKSI and K_AMF to the AMF after it has received the Nausf_UEAuthentication_Authenticate Response message containing K_SEAF and SUPI; no communication services will be provided to the UE until the SUPI is known to the serving network.

The further steps taken by the AUSF after the authentication procedure are described in sub-clause 6.1.4 of the present document.

6.1.3.2.1 Void

6.1.3.2.2 RES* verification failure in SEAF or AUSF or both

This clause describes how RES* verification failure in the SEAF or in the AUSF shall be handled.

In step 9 in Figure 6.1.3.2-1, the SEAF shall compute HRES* from RES* according to Annex A.5, and the SEAF shall compare HRES* and HXRES*. If they don’t coincide, then the SEAF shall consider the authentication as unsuccessful.

The SEAF shall proceed with step 10 in Figure 6.1.3.2-1 and after receiving the Nausf_UEAuthentication_Authenticate Response message from the AUSF in step 12in Figure 6.1.3.2-1, proceed as described below:

– If the AUSF has indicated in the Nausf_UEAuthentication_Authenticate Response message to the SEAF that the verification of the RES* was not successful in the AUSF, or

– if the verification of the RES* was not successful in the SEAF,

then the SEAF shall either reject the authentication by sending an Authentication Reject to the UE if the SUCI was used by the UE in the initial NAS message or the SEAF/AMF shall initiate an Identification procedure with the UE if the 5G-GUTI was used by the UE in the initial NAS message to retrieve the SUCI and an additional authentication attempt may be initiated.

Also, if the SEAF does not receive any Nausf_UEAuthentication_Authenticate Response message from the AUSF as expected, then the SEAF shall either reject the authentication to the UE or initiate an Identification procedure with the UE.

6.1.3.3 Synchronization failure or MAC failure

6.1.3.3.1 Synchronization failure or MAC failure in USIM

This clause describes synchronisation failure or MAC failure in USIM.

In step 7 in Figure 6.1.3.2-1 when 5G AKA is used; or in step 5 in Figure 6.1.3.1-1 when EAP-AKA’ is used, at the receipt of the RAND and AUTN, if the verification of the AUTN fails, then the USIM indicates to the ME the reason for failure and in the case of a synchronisation failure passes the AUTS parameter (see TS 33.102 [9]) to the ME.

If 5G AKA is used: The ME shall respond with NAS message Authentication Failure with a CAUSE value indicating the reason for failure. In case of a synchronisation failure of AUTN (as described in TS 33.102 [9]), the UE also includes AUTS that was provided by the USIM. Upon receipt of an authentication failure message, the AMF/SEAF may initiate new authentication towards the UE. (see TS 24.501 [35]).

If EAP-AKA’ is used: The ME shall proceed as described in RFC 4187 [21] and RFC 5448 [12] for EAP-AKA’.

6.1.3.3.2 Synchronization failure recovery in Home Network

Upon receiving an authentication failure message with synchronisation failure (AUTS) from the UE, the SEAF sends an Nausf_UEAuthentication_Authenticate Request message with a "synchronisation failure indication" to the AUSF and the AUSF sends an Nudm_UEAuthentication_Get Request message to the UDM/ARPF, together with the following parameters:

– RAND sent to the UE in the preceding Authentication Request, and

– AUTS received by the SEAF in the response from the UE to that request, as described in subsection 6.1.3.2.0 and 6.1.3.3.1.

An SEAF will not react to unsolicited "synchronisation failure indication" messages from the UE.

The SEAF does not send new authentication requests to the UE before having received the response to its Nausf_UEAuthentication_Authenticate Request message with a "synchronisation failure indication" from the AUSF (or before it is timed out).

When the UDM/ARPF receives an Nudm_UEAuthentication_Get Request message with a "synchronisation failure indication" it acts as described in TS 33.102 [9], clause 6.3.5 where ARPF is mapped to HE/AuC. The UDM/ARPF sends an Nudm_UEAuthentication_Get Response message with a new authentication vector for either EAP-AKA’ or 5G-AKA depending on the authentication method applicable for the user to the AUSF. The AUSF runs a new authentication procedure with the UE according to clauses 6.1.3.1 or 6.1.3.2 depending on the authentication method applicable for the user.

6.1.4 Linking increased home control to subsequent procedures

6.1.4.1 Introduction

The 5G authentication and key agreement protocols provide increased home control. Compared to EPS AKA in EPS, this provides better security useful in preventing certain types of fraud as explained in more detail below.

This increased home control comes in the following forms in 5GS:

– In the case of EAP-AKA’, the AUSF in the home network obtains confirmation that the UE has been successfully authenticated when the EAP-Response/AKA’-Challenge received by the AUSF has been successfully verified, cf. sub-clause 6.1.3.1 of the present document.

– In the case of 5G AKA, the AUSF in the home network obtains confirmation that the UE has been successfully authenticated when the authentication confirmation received by the AUSF in Nausf_UEAuthentication_Authenticate Request message has been successfully verified, cf. sub-clause 6.1.3.2 of the present document.

When 3GPP credentials are used in above cases, the result is reported to the UDM. Details are described in clause 6.1.4.1a.

The feature of increased home control is useful in preventing certain types of fraud, e.g. fraudulent Nudm_UECM_Registration Request for registering the subscriber’s serving AMF in UDM that are not actually present in the visited network. But an authentication protocol by itself cannot provide protection against such fraud. The authentication result needs to be linked to subsequent procedures, e.g. the Nudm_UECM_Registration procedure from the AMF in some way to achieve the desired protection.

The actions taken by the home network to link authentication confirmation (or the lack thereof) to subsequent procedures are subject to operator policy and are not standardized.

But informative guidance is given in sub-clause 6.1.4.2 as to what measures an operator could usefully take. Such guidance may help avoiding a proliferation of different solutions.

The feature of increased home control is also used to allow the UDM to keep track of the AUSF that stores the K_AUSF to be used during e.g. the control plane solution for Steering of Roaming or UE Parameter Update procedures; i.e. the AUSF that stores the latest K_AUSF generated after successful completion of the latest primary authentication reported to the UDM.

After the UDM is informed that the UE has been successfully (re-)authenticated, the UDM shall store the AUSF instance which reported the successful authentication. If the UDM has been previously informed that the UE was authenticated by a different AUSF instance, the UDM may request the old AUSF to clear the stale security parameters (K_AUSF, SOR counter and UE parameter update counter). If the UDM determines to delete the security parameters in the old AUSF, then the UDM shall use the Nausf_UEAuthentication_deregister service operation (see clause 14.1.5).

6.1.4.1a Linking authentication confirmation to Nudm_UECM_Registration procedure from AMF

The information sent from the AUSF to the UDM that a successful or unsuccessful authentication of a subscriber has occurred, shall be used to link authentication confirmation to subsequent procedures. The AUSF shall send the Nudm_UEAuthentication_ResultConfirmation service operation for this purpose as shown in figure6.1.4.1a-1.

Figure 6.1.4.1a-1: Linking increased Home control to subsequent procedures

1. The AUSF shall inform UDM about the result and time of an authentication procedure with a UE using a Nudm_UEAuthentication_ResultConfirmation Request. This shall include the SUPI, a timestamp of the authentication, the authentication type (e.g. EAP method or 5G-AKA), and the serving network name.

NOTE: It may be sufficient for the purposes of fraud prevention to send only information about successful authentications, but this is up to operator policy.

2. The UDM shall store the authentication status of the UE (SUPI, authentication result, timestamp, and the serving network name).

3. UDM shall reply to AUSF with a Nudm_UEAuthentication_ResultConfirmation Response.

4. Upon reception of subsequent UE related procedures (e.g. Nudm_UECM_Registration_Request from AMF) UDM may apply actions according to home operator’s policy to detect and achieve protection against certain types of fraud (e.g. as proposed in section 6.1.4.2).

6.1.4.2 Guidance on linking authentication confirmation to Nudm_UECM_Registration procedure from AMF

This sub-clause gives informative guidance on how a home operator could link authentication confirmation (or the lack thereof) to subsequent Nudm_UECM_Registration procedures from AMF to achieve protection against certain types of fraud, as mentioned in the preceding sub-clause.

Approach 1:

The home network records the time of the most recent successfully verified authentication confirmation of the subscriber together with the identity of the 5G visited network that was involved in the authentication. When a new Nudm_UECM_Registration Request arrives from a visited network, the home network checks whether there is a sufficiently recent authentication of the subscriber by this visited network. If not, the Nudm_UECM_Registration Request is rejected. The rejection message may include, according to the home networks policy, an indication that the visited network should send a new Nausf_UEAuthentication_Authenticate Request (cf. sub-clause 6.1.2 of the present document) for fetching a new authentication vector before repeating the Nudm_UECM_Registration Request.

NOTE 1: With this approach, the authentication procedure and the Nudm_UECM_Registration procedure are performed independently. They are coupled only through linking information in the home network.

NOTE 2: It is up to the home network to set the time threshold to define what ‘sufficiently recent’ is.

Approach 2:

As a variant of the above Approach 1, Approach 2 is based on a more fine-grained policy applied by the home network; the home network could classify roaming partners into different categories, depending on the trust – e.g. derived from previous experience placed in them, for example as follows:

– For a visited network in the first category, the home network would require a successful authentication ‘immediately preceding’ the Nudm_UECM_Registration Request from an AMF.

– For a visited network in the second category, the home network would only check that an authentication in a network visited by the subscriber was sufficiently recent (taking into account that there may have been a security context transfer between the visited networks).

– For a visited network in the third category, the home network would perform no checks regarding Nudm_UECM_Registration Requests and authentication at all.

Further approaches are possible, depending on the home operator’s policy.