5.4.1.2.3A Procedures related to EAP methods other than EAP-AKA' and EAP-TLS

5.4.1.2.3A.1 General

This clause applies when an EAP method:

• supporting mutual authentication;
• supporting EMSK or MSK generation; and
• other than EAP-AKA' and EAP-TLS;

is used for primary authentication and key agreement in an SNPN.

The UE may support acting as EAP peer of such EAP method as specified in 3GPP TS 33.501 [24]. The AUSF may support acting as EAP server of such EAP method as specified in 3GPP TS 33.501 [24]. The AAA server of the CH or the DCS may support acting as EAP server of such EAP method as specified in 3GPP TS 23.501 [8].

When initiating an EAP based primary authentication and key agreement procedure using such EAP method, 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.

When the EAP based primary authentication and key agreement procedure uses such EAP method:

• if:
• the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
• credentials in the selected entry of the "list of subscriber data", if the UE is not registering or registered for onboarding services in SNPN;

contain an indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure then the ME shall generate MSK as described in 3GPP TS 33.501 [24] otherwise the ME shall generate EMSK as described in 3GPP TS 33.501 [24];

• if the AUSF acts as the EAP server, the AUSF shall generate EMSK as described in 3GPP TS 33.501 [24]; and
• if the AAA server of the CH or the DCS acts as the EAP server, the AAA server of the CH or the DCS shall generate MSK as described in 3GPP TS 33.501 [24].

When handling of an EAP-request message results into generation of MSK or EMSK, if:

• the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
• credentials in the selected entry of the "list of subscriber data", if the UE is not registering or registered for onboarding services in SNPN;

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 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 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.

NOTE 1: 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.

When the AUSF acts as the EAP server and handling of an EAP response message results into generation of EMSK, the AUSF shall generate the KAUSF from the EMSK, and the KSEAF from the KAUSF as described in 3GPP TS 33.501 [24].

NOTE 2: When the AAA server of the CH or the DCS acts as the EAP server and handling of an EAP response message results into generation of MSK, 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 3: 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.

If the UE fails to authenticate the network, 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 retransmission timers that are running (e.g. T3510, T3517 or T3521). Upon receiving an AUTHENTICATION REQUEST message with the EAP message IE containing an EAP-request message from the network, the UE shall stop timer T3520, if running, and then process the EAP-request message as normally.

If the network fails to authenticate the UE, 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 the 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.

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 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;

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.

In case of SNPN, 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]; and

• 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 "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 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 "the entry for the current SNPN considered invalid for 3GPP access" events has a value less than a UE implementation-specific maximum value, proceed as specified in list item a) 1) of clause 5.3.20.3 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 "the entry for the current SNPN considered invalid for non-3GPP access" events has a value less than a UE implementation-specific maximum value, proceed as specified in list item a)-2) of clause 5.3.20.3 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 SNPN, if 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 for 3GPP access until the UE is switched off or the entry is updated;

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 until the UE is switched off or the entry is updated; and

• the UE shall set the counter for "the entry for the current SNPN considered invalid for 3GPP access" events to UE implementation-specific maximum value; 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. The selected entry of the "list of subscriber data" with the SNPN identity of the current SNPN shall be considered invalid for non-3GPP access until the UE is switched off or the entry is updated; and
• the UE shall set the counter for "the entry for the current SNPN considered invalid for non-3GPP access" events 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:

• 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.

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 when handling the EAP-request message which resulted into generation of EMSK as described above:
• if:
• the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
• credentials in the selected entry of the "list of subscriber data", if the UE is not registering or registered for onboarding services in SNPN;

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;

• generate a new KSEAF from the new KAUSF, and the KAMF from the ABBA that was received with the EAP-success message, and the 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, 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.

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 when handling the EAP-request message which resulted into generation of EMSK or MSK as described above.

The UE shall consider the procedure complete.

5.4.1.2.3A.2 EAP-TTLS with two phases of authentication

The UE may support acting as EAP peer of EAP-TTLS with two phases of authentication as specified in 3GPP TS 33.501 [24] and acting as peer of a legacy authentication protocol as specified in 3GPP TS 33.501 [24]. The AUSF may support acting as EAP server of EAP-TTLS with two phases of authentication as specified in 3GPP TS 33.501 [24]. The AAA server of the CH or the DCS may support acting a server of a legacy authentication protocol as specified in 3GPP TS 33.501 [24].

When EAP-TTLS with two phases of authentication as specified in 3GPP TS 33.501 [24] is used for primary authentication and key agreement in an SNPN:

• requirements in clause 5.4.1.2.3A.1 shall apply in addition to requirements specified in 3GPP TS 33.501 [24] annex U;
• indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure is not included in:
• the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
• credentials in the selected entry of the "list of subscriber data", if the UE is not registering or registered for onboarding services in SNPN; and
• the SUPI of the UE is in the form of a SUPI with the SUPI format "network specific identifier" containing a network-specific identifier.

NOTE: Support of EAP-TTLS with two phases of authentication is based on the informative requirements as specified in 3GPP TS 33.501 [24].