5.4.1.2.2 EAP-AKA' related procedures

5.4.1.2.2.1 General

The UE shall support acting as EAP-AKA' peer as specified in IETF RFC 5448 [40]. The AUSF may support acting as EAP-AKA' server as specified in IETF RFC 5448 [40]. The AAA server of the Credentials Holder (CH) or the Default Credentials Server (DCS) may support acting as EAP-AKA' server as specified in IETF RFC 5448 [40].

The EAP-AKA' enables mutual authentication of the UE and the network.

The UE can reject the EAP-request/AKA'-challenge message sent by the network. The UE shall proceed with an EAP-request/AKA'-challenge message only if a USIM is present.

During a successful EAP based primary authentication and key agreement procedure, the CK and IK are computed by the USIM. CK and IK are then used by the ME as key material to generate an EMSK or MSK.

5.4.1.2.2.2 Initiation

In order to initiate the EAP based primary authentication and key agreement procedure using EAP-AKA', the AUSF or the AAA server of the CH or the DCS shall send an EAP-request/AKA'-challenge message as specified in IETF RFC 5448 [40]. The AUSF or the AAA server of the CH or the DCS shall set the AT_KDF_INPUT attribute of the EAP-request/AKA'-challenge message to the SNN. The SNN is in format described in clause 9.12.1. The AUSF or the AAA server of the CH or the DCS may include AT_RESULT_IND attribute in the EAP-request/AKA'-challenge message.

The network shall select an ngKSI value. If an ngKSI is contained in an initial NAS message during a 5GMM procedure, the network shall select a different ngKSI value. The network shall send the selected ngKSI value to the UE along with each EAP message. The network shall send the ABBA value as described in clause 9.11.3.10 to the UE along with the EAP request message and EAP-success message.

Upon receiving an EAP-request/AKA'-challenge message, the UE shall check whether the UE has a USIM, shall check the key derivation function indicated in AT_KDF attributes as specified in IETF RFC 5448 [40], and if the value of the Key derivation function field within the received AT_KDF attribute, is of value 1, shall check:

• whether the network name field of the AT_KDF_INPUT attribute is the SNN constructed according to clause 9.12.1; and
• whether the network name field of the AT_KDF_INPUT attribute matches the PLMN identity or the SNPN identity of the selected SNPN saved in the UE.

When not operating in SNPN access operation mode, the PLMN identity the UE uses for the above network name check is as follows:

• when the UE moves from 5GMM-IDLE mode to 5GMM-CONNECTED mode, until the first handover, the UE shall use the PLMN identity of the selected PLMN; and
• after handover or inter-system change to N1 mode in 5GMM-CONNECTED mode:
• if the target cell is not a shared network cell, the UE shall use the PLMN identity received as part of the broadcast system information;
• if the target cell is a shared network cell and the UE has a valid 5G-GUTI, the UE shall use the PLMN identity that is part of the 5G-GUTI; and
• if the target cell is a shared network cell and the UE has a valid 4G-GUTI, but not a valid 5G-GUTI, the UE shall use the PLMN identity that is part of the 4G-GUTI.

When operating in SNPN access operation mode, the SNPN identity the UE uses for the above network name check is the SNPN identity of the selected SNPN.

5.4.1.2.2.3 UE successfully authenticates network

If a USIM is present and the SNN check is successful, the UE shall handle the EAP-request/AKA'-challenge message as specified in IETF RFC 5448 [40]. The USIM shall derive CK and IK and compute the authentication response (RES) using the 5G authentication challenge data received from the ME, and pass RES to the ME. The ME shall derive CK' and IK' from CK and IK, and if the UE operates in SNPN access operation mode and the credentials in the USIM contain an indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure then derive MSK from CK' and IK' otherwise derive EMSK from CK' and IK'.

NOTE 1: When the UE is registering or registered for onboarding services in SNPN, credentials in the USIM do not contain an indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure.

Furthermore, if the UE operates in SNPN access operation mode and the credentials in the USIM contain an indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure then the ME may generate a new KAUSF from the MSK otherwise the ME may generate a new KAUSF from the EMSK.

If the ME generates a new KAUSF, the ME shall generate a new KSEAF from the new KAUSF, and the KAMF from the ABBA received together with the EAP-request/AKA'-challenge message, and the new KSEAF as described in 3GPP TS 33.501 [24], and create a partial native 5G NAS security context identified by the ngKSI value received together with the EAP-request/AKA'-challenge message in clause 5.4.1.2.4.2 in the volatile memory of the ME. If the KAMF and the partial native 5G NAS security context are created, the ME shall store the KAMF in the created partial native 5G NAS security context, and shall send an EAP-response/AKA'-challenge message as specified in IETF RFC 5448 [40].

NOTE 2: Generation of the new KAUSF and the new KSEAF does not result into deletion of the valid KAUSF and the valid KSEAF, if any.

The ME shall not use the new KAUSF in the verification of SOR transparent container and UE parameters update transparent container, if any are received, until receipt of an EAP-success message.

If the EAP-request/AKA'-challenge message contains AT_RESULT_IND attribute, the UE may include AT_RESULT_IND attribute in the EAP-response/AKA'-challenge message as specified in IETF RFC 5448 [40].

5.4.1.2.2.4 Errors when handling EAP-request/AKA'-challenge message

If a USIM is present, the SNN check fails or the UE does not accept AUTN during handling of the EAP-request/AKA'-challenge message as specified in IETF RFC 5448 [40], the UE shall send an EAP-response/AKA'-authentication-reject message as specified in IETF RFC 5448 [40].

If a USIM is present, the SNN check is successful but the UE detects that the sequence number in AUTN is not correct during handling of the EAP-request/AKA'-challenge message as specified in IETF RFC 5448 [40], the UE shall send an EAP-response/AKA'-synchronization-failure message as specified in IETF RFC 5448 [40].

If a USIM is present, the SNN check is successful, the sequence number in AUTN is correct and the UE detects another error during handling of the EAP-request/AKA'-challenge message as specified in IETF RFC 5448 [40], the UE shall send an EAP-response/AKA'-client-error message as specified in IETF RFC 5448 [40].

If a USIM is not present, the UE shall send an EAP-response/AKA'-client-error message as specified in IETF RFC 5448 [40].

For any of the above, the UE shall start timer T3520 when the AUTHENTICATION RESPONSE message containing the EAP-response message is sent. Furthermore, the UE shall stop any of the timers T3510, T3517 or T3521 (if they were running). Upon receiving an AUTHENTICATION REQUEST message with the EAP message IE containing an EAP-request/AKA'-challenge from the network, the UE shall stop timer T3520, if running, and then process the EAP-request/AKA'-challenge information as normal.

5.4.1.2.2.5 Network successfully authenticates UE

Upon reception of the EAP-response/AKA'-challenge message, if procedures for handling an EAP-response/AKA'-challenge message as specified in IETF RFC 5448 [40] are successful and:

• the AUSF acts as the EAP-AKA' server, the AUSF shall generate EMSK, the KAUSF from the EMSK, and the KSEAF from the KAUSF as described in 3GPP TS 33.501 [24]; or
• the AAA server of the CH or the DCS acts as the EAP-AKA' server, the AAA server of the CH or the DCS shall generate MSK as described in 3GPP TS 33.501 [24];

and:

• if the AUSF or the AAA server of the CH or the DCS included the AT_RESULT_IND attribute in the EAP-request/AKA'-challenge message and the AT_RESULT_IND attribute is included in the corresponding EAP-response/AKA'-challenge message, the AUSF or the AAA server of the CH or the DCS shall send an EAP-request/AKA'-notification message as specified in IETF RFC 5448 [40]; or
• if the AUSF or the AAA server of the CH or the DCS:
• included the AT_RESULT_IND attribute in the EAP-request/AKA'-challenge message and the AT_RESULT_IND attribute is not included in the EAP-response/AKA'-challenge message; or
• did not include the AT_RESULT_IND attribute in the EAP-request/AKA'-challenge message;

then the AUSF or the AAA server of the CH or the DCS shall send an EAP-success message as specified in IETF RFC 5448 [40] and shall consider the procedure complete.

NOTE 1: When the AAA server of the CH or the DCS acts as the EAP-AKA' server, the AAA server of the CH or the DCS provides (via the NSSAAF) the MSK and the SUPI to the AUSF. Upon reception of the MSK, the AUSF generates the KAUSF from the MSK, and the KSEAF from the KAUSF as described in 3GPP TS 33.501 [24].

NOTE 2: The AUSF provides the KSEAF and optionally the SUPI (unless the SEAF provided the AUSF with the SUPI before) to the SEAF as described in 3GPP TS 33.501 [24]. Upon reception of the KSEAF and optionally the SUPI, the SEAF generates the KAMF based on the ABBA, the KSEAF and the SUPI as described in 3GPP TS 33.501 [24] and provides ngKSI and the KAMF to the AMF. Upon reception of the ngKSI and the KAMF, the AMF creates a partial native 5G NAS security context identified by the ngKSI and stores the KAMF in the created partial native 5G NAS security context.

5.4.1.2.2.6 UE handling EAP-AKA' notification message

Upon receiving an EAP-request/AKA'-notification message, the UE shall send an EAP-response/AKA'-notification message as specified in IETF RFC 5448 [40].

5.4.1.2.2.6A EAP based Identification initiation by the network

If the AUSF or the AAA server of the CH or the DCS decides to initiate the EAP based identification procedure, the AUSF or the AAA server of the CH or the DCS shall send an EAP-Request/Identity or EAP-Request/AKA'-Identity message as specified in IETF RFC 5448 [40].

The AMF shall encapsulate the EAP-Request/Identity or EAP-Request/AKA'-Identity message in the AUTHENTICATION REQUEST message and send it to the UE.

5.4.1.2.2.6B EAP based Identification response by the UE

Upon receipt of the AUTHENTICATION REQUEST message with EAP-Request/Identity message the UE shall send an AUTHENTICATION RESPONSE message with EAP-Response/Identity to the network. In the EAP-Response/Identity message, the UE shall provide the requested identity according to 3GPP TS 33.501 [24] clause F.2, in the UE identity in the EAP-Response/Identity message as specified in IETF RFC 5448 [40].

Upon receipt of the AUTHENTICATION REQUEST message with EAP-Request/AKA'-Identity message the UE shall send an AUTHENTICATION RESPONSE message with EAP-Response/AKA'-Identity to the network. Based on the attribute received in the EAP-Request/AKA'-Identity, the UE shall provide the requested identity according to 3GPP TS 33.501 [24] clause F.2, in the EAP-Response/AKA'-Identity message, as specified in IETF RFC 5448 [40].

If the EAP-Request/AKA'-Identity carries the AT_PERMANENT_REQ, the UE shall respond with EAP-Response/AKA'-Client-Error with the error code "unable to process packet".

5.4.1.2.2.7 Network sending EAP-success message

Upon reception of the EAP-response/AKA'-notification message, if earlier procedures for handling an EAP-request/AKA'-challenge message as specified in IETF RFC 5448 [40] were successful, the AUSF or the AAA server of the CH or the DCS shall send an EAP-success message as specified in IETF RFC 5448 [40] and shall consider the procedure complete.

NOTE: The AUSF provides the KSEAF to the SEAF. Upon reception of the KSEAF, the SEAF generates the KAMF based on the ABBA and the KSEAF as described in 3GPP TS 33.501 [24], and provides ngKSI and the KAMF to the AMF. Upon reception of the ngKSI and the KAMF, the AMF creates a partial native 5G NAS security context identified by the ngKSI, and stores the KAMF in the created partial native 5G NAS security context.

5.4.1.2.2.8 UE handling EAP-success message

Upon receiving an EAP-success message, the ME shall:

• delete the valid KAUSF and the valid KSEAF, if any;
• if the ME has not generated a new KAUSF and a new KSEAF and has not created a partial native 5G NAS security context as described in clause 5.4.1.2.2.3:
• if the UE operates in SNPN access operation mode and the credentials in the USIM contain an indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure then generate a new KAUSF from the MSK otherwise generate a new KAUSF from the EMSK;

NOTE: When the UE is registering or registered for onboarding services in SNPN, credentials in the USIM do not contain an indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure.

• generate a new KSEAF from the new KAUSF, and the KAMF from the ABBA that was received with the EAP-success message, and the new KSEAF as described in 3GPP TS 33.501 [24];
• create a partial native 5G NAS security context identified by the ngKSI value in the volatile memory of the ME; and
• store the KAMF in the created partial native 5G NAS security context; and
• consider the new KAUSF to be the valid KAUSF, and the new KSEAF to be the valid KSEAF, reset the SOR counter and the UE parameter update counter to zero, and store the valid KAUSF, the valid KSEAF, the SOR counter and the UE parameter update counter as specified in annex C, and use the valid KAUSF in the verification of SOR transparent container and UE parameters update transparent container, if any are received.

The UE shall consider the procedure complete.

5.4.1.2.2.9 Network not successfully authenticates UE

Upon reception of the EAP-response/AKA'-challenge message, if procedures for handling an EAP-response/AKA'-challenge message as specified in IETF RFC 5448 [40] are not successful, the AUSF or the AAA server of the CH or the DCS shall send an EAP-request/AKA'-notification message that implies failure as specified in IETF RFC 5448 [40].

5.4.1.2.2.10 Network sending EAP-failure message

Upon reception of the EAP-response/AKA'-notification message, if earlier procedures for handling an EAP-request/AKA'-challenge message as specified in IETF RFC 5448 [40] were not successful, the AUSF or the AAA server of the CH or the DCS shall send an EAP-failure message as specified in IETF RFC 5448 [40] and shall consider the procedure complete.

If the authentication response (RES) returned by the UE in the AT_RES attribute of the EAP-response/AKA'-challenge message is not valid, the network handling depends upon the type of identity used by the UE in the initial NAS message, that is:

• if the 5G-GUTI was used; or
• - if the SUCI was used.

If the 5G-GUTI was used, the network should transport the EAP-failure message in the AUTHENTICATION RESULT message of the EAP result message transport procedure, initiate an identification procedure to retrieve SUCI from the UE and restart the EAP based primary authentication and key agreement procedure with the received SUCI.

If the SUCI was used for identification in the initial NAS message or in a restarted EAP based primary authentication and key agreement procedure, or the network decides not to initiate the identification procedure to retrieve SUCI from the UE after an unsuccessful EAP based primary authentication and key agreement procedure, the network should transport the EAP-failure message in an AUTHENTICATION REJECT message of the EAP result message transport procedure.

Depending on local requirements or operator preference for emergency services, if the UE initiates a registration procedure with 5GS registration type IE set to "emergency registration" and the AMF is configured to allow emergency registration without user identity, the AMF needs not follow the procedures specified for transporting the EAP-failure message in the AUTHENTICATION REJECT message of the EAP result message transport procedure in the present clause. The AMF may include the EAP-failure message in a response of the current 5GMM specific procedure or in the AUTHENTICATION RESULT of the EAP result message transport procedure.

5.4.1.2.2.11 UE handling EAP-failure message

Upon receiving an EAP-failure message, the UE shall delete the partial native 5G NAS security context and shall delete the new KAUSF and the new KSEAF, if any were created as described in clause 5.4.1.2.2.3.

The UE shall consider the procedure complete.

If the EAP-failure message is received in an AUTHENTICATION REJECT message:

• if the AUTHENTICATION REJECT message has been successfully integrity checked by the NAS or the UE is configured to use timer T3245 (see 3GPP TS 24.368 [17] or 3GPP TS 31.102 [22]):
• the UE shall set the update status to 5U3 ROAMING NOT ALLOWED, delete the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI.

In case of PLMN, the USIM shall be considered invalid until switching off the UE, the UICC containing the USIM is removed, or the timer T3245 expires as described in clause 5.3.19A.1.

In case of SNPN, if the UE is neither registered for onboarding services in SNPN nor performing initial registration for onboarding services in SNPN and the UE does not support access to an SNPN using credentials from a credentials holder and does not support equivalent SNPNs, the selected entry of the "list of subscriber data" with the SNPN identity of the current SNPN shall be considered invalid until the UE is switched off, the entry is updated, or the timer T3245 expires as described in clause 5.3.19A.2. Additionally, the UE shall consider the USIM as invalid for the current SNPN until switching off, the UICC containing the USIM is removed, or the timer T3245 expires as described in clause 5.3.19A.2.

In case of SNPN, if the UE is neither registered for onboarding services in SNPN nor performing initial registration for onboarding services in SNPN and the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs, or both, the UE shall consider the selected entry of the "list of subscriber data" as invalid until the UE is switched off, the entry is updated, or the timer T3245 expires as described in clause 5.3.19A.2. Additionally, the UE shall consider the USIM as invalid for the entry until switching off, the UICC containing the USIM is removed, or the timer T3245 expires as described in clause 5.3.19A.2.

If the UE is registered for onboarding services in SNPN or is performing initial registration for onboarding services in SNPN, the UE shall store the SNPN identity in the "permanently forbidden SNPNs" for onboarding services in SNPN" list, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to 3GPP TS 23.122 [5];

• if the UE is neither registered for onboarding services in SNPN nor performing initial registration for onboarding services in SNPN, the UE shall set:
• the counter for "SIM/USIM considered invalid for GPRS services" events, the counter for "USIM considered invalid for 5GS services over non-3GPP access" events, and the counter for "SIM/USIM considered invalid for non-GPRS services" events if maintained by the UE, in case of PLMN; or
• the counter for "the entry for the current SNPN considered invalid for 3GPP access" events and the counter for "the entry for the current SNPN considered invalid for non-3GPP access" events in case of SNPN;

to UE implementation-specific maximum value.

If the UE is registered for onboarding services in SNPN or performing initial registration for onboarding services in SNPN, the UE shall set the SNPN-specific attempt counter for the current SNPN to the UE implementation-specific maximum value; and

• if the UE is operating in single-registration mode, the UE shall handle EMM parameters, 4G-GUTI, last visited registered TAI, TAI list and eKSI as specified in 3GPP TS 24.301 [15] for the case when the authentication procedure is not accepted by the network. The USIM shall be considered as invalid also for non-EPS services until switching off, the UICC containing the USIM is removed, or the timer T3245 expires as described in clause 5.3.7a in 3GPP TS 24.301 [15]; and
• if the AUTHENTICATION REJECT message is received without integrity protection and the UE is not configured to use timer T3245 (see 3GPP TS 24.368 [17] or 3GPP TS 31.102 [22]), the UE shall start timer T3247 with a random value uniformly drawn from the range between 30 minutes and 60 minutes, if the timer is not running (see clause 5.3.20).

Additionally, if the UE is neither registered for onboarding services in SNPN nor performing initial registration for onboarding services in SNPN, the UE shall:

• if the AUTHENTICATION REJECT message is received over 3GPP access, and the counter for "SIM/USIM considered invalid for GPRS services" events in case of PLMN or the counter for "the entry for the current SNPN considered invalid for 3GPP access" events in case of SNPN has a value less than a UE implementation-specific maximum value, proceed as specified in clause 5.3.20, list item 1)-a) of clause 5.3.20.2 (if the UE is not operating in SNPN access operation mode) or list item a)-1) of clause 5.3.20.3 (if the UE is operating in SNPN access operation mode) for the case that the 5GMM cause value received is #3;
• if the AUTHENTICATION REJECT message is received over non-3GPP access, and the counter for "USIM considered invalid for 5GS services over non-3GPP access" events in case of PLMN or the counter for "the entry for the current SNPN considered invalid for non-3GPP access" events in case of SNPN has a value less than a UE implementation-specific maximum value, proceed as specified in clause 5.3.20, list item 1)-b) of clause 5.3.20.2 (if the UE is not operating in SNPN access operation mode) or list item a)-2) of clause 5.3.20.3 (if the UE is operating in SNPN access operation mode) for the case that the 5GMM cause value received is #3; or
• otherwise:
• if the AUTHENTICATION REJECT message is received over 3GPP access:
• The UE shall set the update status for 3GPP access to 5U3 ROAMING NOT ALLOWED, delete for 3GPP access only the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI.
• In case of PLMN, the UE shall consider the USIM as invalid for 5GS services via 3GPP access and invalid for non-EPS service until switching off the UE or the UICC containing the USIM is removed.

In case of SNPN, if the UE does not support access to an SNPN using credentials from a credentials holder and does not support equivalent SNPNs, the UE shall consider the selected entry of the "list of subscriber data" with the SNPN identity of the current SNPN as invalid for 3GPP access until the UE is switched off or the entry is updated. Additionally, the UE shall consider the USIM as invalid for the current SNPN via 3GPP access until switching off or the UICC containing the USIM is removed.

In case of SNPN, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs, or both, the UE shall consider the selected entry of the "list of subscriber data" as invalid for 3GPP access until the UE is switched off or the entry is updated. Additionally, the UE shall consider the USIM as invalid for the entry via 3GPP access until switching off or the UICC containing the USIM is removed.

• The UE shall set:
• the counter for "SIM/USIM considered invalid for GPRS services" events and the counter for "SIM/USIM considered invalid for non-GPRS services" events if maintained by the UE, in case of PLMN; or
• the counter for "the entry for the current SNPN considered invalid for 3GPP access" events in case of SNPN;

to UE implementation-specific maximum value.

• If the UE is operating in single-registration mode, the UE shall handle 4G-GUTI, TAI list and eKSI as specified in 3GPP TS 24.301 [15] for the case when the authentication procedure is not accepted by the network. The USIM shall be considered as invalid also for non-EPS services until switching off or the UICC containing the USIM is removed; and
• if the AUTHENTICATION REJECT message is received over non-3GPP access:
• the UE shall set the update status for non-3GPP access to 5U3 ROAMING NOT ALLOWED, delete for non-3GPP access only the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI;
• in case of PLMN, the UE shall consider the USIM as invalid for 5GS services via non-3GPP access until switching off the UE or the UICC containing the USIM is removed.

In case of SNPN, the UE shall consider the selected entry of the "list of subscriber data" with the SNPN identity of the current SNPN as invalid for non-3GPP access until the UE is switched off or the entry is updated. Additionally, the UE shall consider the USIM as invalid for the current SNPN and for non-3GPP access until switching off or the UICC containing the USIM is removed; and

• the UE shall set:
• the counter for "USIM considered invalid for 5GS services over non-3GPP access" events to UE implementation-specific maximum value in case of PLMN; or
• the counter for "the entry for the current SNPN considered invalid for non-3GPP access" events to UE implementation-specific maximum value in case of SNPN.

If the UE is registered for onboarding services in SNPN or performing initial registration for onboarding services in SNPN, the UE shall:

• if the SNPN-specific attempt counter for the SNPN sending the AUTHENTICATION REJECT message has a value less than a UE implementation-specific maximum value, increment the SNPN-specific attempt counter for the SNPN; or
• otherwise, the UE shall set the update status to 5U3.ROAMING NOT ALLOWED, delete the stored 5G-GUTI, TAI list, last visited registered TAI, and ngKSI, store the SNPN identity in the "permanently forbidden SNPNs for onboarding services in SNPN" list, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to 3GPP TS 23.122 [5].

If the AUTHENTICATION REJECT message is received by the UE, the UE shall abort any 5GMM signalling procedure, stop any of the timers T3510, T3517, T3519 or T3521 (if they were running), enter state 5GMM-DEREGISTERED and delete any stored SUCI.

5.4.1.2.2.12 Abnormal cases in the UE

The following abnormal cases can be identified:

• EAP-request/AKA'-challenge message with the key derivation function indicated in AT_KDF attributes set to a value other than 1.

The UE shall act as specified in IETF RFC 5448 [40] clause 3.2 for the case when the AUTN had been incorrect.