Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.501  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.4…   4.4.3…   4.5…   4.5.3…   4.6…   4.7…   4.9…   4.15…   5…   5.2…   5.3…   5.3.2…   5.3.7…   5.3.19…   5.4…   5.4.1.3…   5.4.2…   5.4.4…   5.4.5…   5.4.6…   5.5…   5.5.1.2.4   5.5.1.2.5…   5.5.1.3…   5.5.1.3.4   5.5.1.3.5…   5.5.2…   5.6…   5.6.2…   6…   6.1.4…   6.2…   6.3…   6.3.2…   6.3.3…   6.4…   6.4.1.4…   6.4.2…   6.5…   7…   8…   8.2.9…   8.3…   9…   9.11.2…   9.11.2.10…   9.11.3…   9.11.3.4…   9.11.3.8…   9.11.3.14…   9.11.3.18C…   9.11.3.29…   9.11.3.33…   9.11.3.39…   9.11.3.45…   9.11.3.50…   9.11.3.53A…   9.11.3.68…   9.11.3.75…   9.11.4…   9.11.4.10…   9.11.4.13…   9.11.4.16…   9.11.4.30…   9.12   10…   A…   B…   C…   D…   D.6…   D.6.3…   D.6.8   D.7…

 

5.4  5GMM common proceduresp. 220

5.4.1  Primary authentication and key agreement procedurep. 220

5.4.1.1  Generalp. 220

The purpose of the primary authentication and key agreement procedure is to enable mutual authentication between the UE and the network and to provide keying material that can be used between the UE and network in subsequent security procedures, as specified in TS 33.501.
Two methods are defined:
  1. EAP based primary authentication and key agreement procedure.
  2. 5G AKA based primary authentication and key agreement procedure.
The UE and the AMF shall support the EAP based primary authentication and key agreement procedure and the 5G AKA based primary authentication and key agreement procedure.
Up

5.4.1.2  EAP based primary authentication and key agreement procedurep. 220

5.4.1.2.1  Generalp. 220
The purpose of the EAP based primary authentication and key agreement procedure is to provide mutual authentication between the UE and the network and to agree on the keys KAUSF, KSEAF and KAMF (see TS 33.501).
Extensible authentication protocol (EAP) as specified in RFC 3748 enables authentication using various EAP methods.
EAP defines four types of EAP messages:
  1. an EAP-request message;
  2. an EAP-response message;
  3. an EAP-success message; and
  4. an EAP-failure message.
Several rounds of exchanges of an EAP-request message and a related EAP-response message can be required to achieve the authentication (see example in Figure 5.4.1.2.1.1).
The EAP based primary authentication and key agreement procedure is always initiated and controlled by the network.
The EAP-request message, the ngKSI and the ABBA are transported from the network to the UE using the AUTHENTICATION REQUEST message of the EAP message reliable transport procedure.
The EAP-response message is transported from the UE to the network using the AUTHENTICATION RESPONSE message of the EAP message reliable transport procedure.
If the authentication of the UE completes successfully, the serving AMF intends to initiate a security mode control procedure after the EAP based primary authentication and key agreement procedure and the security mode control procedure intends to bring into use the partial native 5G NAS security context created by the EAP based primary authentication and key agreement procedure, then the EAP-success message and the ngKSI are transported from the network to the UE using the SECURITY MODE COMMAND message of the security mode control procedure (see subclause 5.4.2).
If the authentication of the UE completes successfully and the serving AMF does not intend to initiate a security mode control procedure bringing into use the partial native 5G NAS security context created by the EAP based primary authentication and key agreement procedure, then the EAP-success message, and the ngKSI are transported from the network to the UE using the AUTHENTICATION RESULT message of the EAP result message transport procedure.
If the authentication of the UE completes unsuccessfully, the EAP-failure message is transported from the network to the UE using the AUTHENTICATION RESULT message or the AUTHENTICATION REJECT message of the EAP result message transport procedure or in a response of the initial 5GMM procedure as part of which the EAP based primary authentication and key agreement procedure is performed.
The AMF shall set the authenticator retransmission timer specified in Section 4.3 of RFC 3748 to infinite value.
The AUSF and the AMF support exchange of EAP messages using N12.
The UE shall detect and handle any duplication of EAP message as specified in RFC 3748.
Reproduction of 3GPP TS 24.501, Fig. 5.4.1.2.1.1: EAP based primary authentication and key agreement procedure
Up
5.4.1.2.2  EAP-AKA' related proceduresp. 223
5.4.1.2.2.1  Generalp. 223
The UE shall support acting as EAP-AKA' peer as specified in RFC 5448. The AUSF may support acting as EAP-AKA' server as specified in RFC 5448. The AAA server of the Credentials Holder (CH) or the Default Credentials Server (DCS) may support acting as EAP-AKA' server as specified in RFC 5448.
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.
Up
5.4.1.2.2.2  Initiationp. 223
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 RFC 5448. 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 subclause 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 subclause 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 RFC 5448, and if the value of the Key derivation function field within the received AT_KDF attribute, is of value 1, shall check:
  1. whether the network name field of the AT_KDF_INPUT attribute is the SNN constructed according to subclause 9.12.1; and
  2. 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:
  1. 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
  2. after handover or inter-system change to N1 mode in 5GMM-CONNECTED mode:
    1. 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;
    2. 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
    3. 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.
Up
5.4.1.2.2.3  UE successfully authenticates networkp. 224
If a USIM is present and the SNN check is successful, the UE shall handle the EAP-request/AKA'-challenge message as specified in RFC 5448. 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'.
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 TS 33.501, and create a partial native 5G NAS security context identified by the ngKSI value received together with the EAP-request/AKA'-challenge message in subclause 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 RFC 5448.
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 RFC 5448.
Up
5.4.1.2.2.4  Errors when handling EAP-request/AKA'-challenge messagep. 224
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 RFC 5448, the UE shall send an EAP-response/AKA'-authentication-reject message as specified in RFC 5448.
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 RFC 5448, the UE shall send an EAP-response/AKA'-synchronization-failure message as specified in RFC 5448.
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 RFC 5448, the UE shall send an EAP-response/AKA'-client-error message as specified in RFC 5448.
If a USIM is not present, the UE shall send an EAP-response/AKA'-client-error message as specified in RFC 5448.
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.
Up
5.4.1.2.2.5  Network successfully authenticates UEp. 224
Upon reception of the EAP-response/AKA'-challenge message, if procedures for handling an EAP-response/AKA'-challenge message as specified in RFC 5448 are successful and:
  1. 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 TS 33.501; or
  2. 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 TS 33.501;
and:
  1. 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 RFC 5448; or
  2. if the AUSF or the AAA server of the CH or the DCS:
    1. 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
    2. 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 RFC 5448 and shall consider the procedure complete.
Up
5.4.1.2.2.6  UE handling EAP-AKA' notification messagep. 225
Upon receiving an EAP-request/AKA'-notification message, the UE shall send an EAP-response/AKA'-notification message as specified in RFC 5448.
5.4.1.2.2.6A  EAP based Identification initiation by the networkp. 225
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 RFC 5448.
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 UEp. 225
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 TS 33.501 Annex F.2, in the UE identity in the EAP-Response/Identity message as specified in RFC 5448.
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 TS 33.501 Annex F.2, in the EAP-Response/AKA'-Identity message, as specified in RFC 5448.
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".
Up
5.4.1.2.2.7  Network sending EAP-success messagep. 226
Upon reception of the EAP-response/AKA'-notification message, if earlier procedures for handling an EAP-request/AKA'-challenge message as specified in RFC 5448 were successful, the AUSF or the AAA server of the CH or the DCS shall send an EAP-success message as specified in RFC 5448 and shall consider the procedure complete.
Up
5.4.1.2.2.8  UE handling EAP-success messagep. 227
Upon receiving an EAP-success message, the ME shall:
  1. delete the valid KAUSF and the valid KSEAF, if any;
  2. 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 subclause 5.4.1.2.2.3:
    1. 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;
    2. 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.
    3. 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 TS 33.501;
    4. create a partial native 5G NAS security context identified by the ngKSI value in the volatile memory of the ME; and
    5. store the KAMF in the created partial native 5G NAS security context; and
  3. 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.
Up
5.4.1.2.2.9  Network not successfully authenticates UEp. 227
Upon reception of the EAP-response/AKA'-challenge message, if procedures for handling an EAP-response/AKA'-challenge message as specified in RFC 5448 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 RFC 5448.
5.4.1.2.2.10  Network sending EAP-failure messagep. 227
Upon reception of the EAP-response/AKA'-notification message, if earlier procedures for handling an EAP-request/AKA'-challenge message as specified in RFC 5448 were not successful, the AUSF or the AAA server of the CH or the DCS shall send an EAP-failure message as specified in RFC 5448 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 subclause. 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.
Up
5.4.1.2.2.11  UE handling EAP-failure messagep. 228
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 subclause 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:
  1. if the AUTHENTICATION REJECT message has been successfully integrity checked by the NAS:
    • 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 or the UICC containing the USIM is removed.
      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 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 or the entry is updated. Additionally, the UE shall consider the USIM as invalid for the current SNPN until switching off or the UICC containing the USIM is removed.
      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 or the entry is updated. Additionally, the UE shall consider the USIM as invalid for the entry until switching off or the UICC containing the USIM is removed.
      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" list for onboarding services, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to TS 23.122;
    • if the UE is neither registered for onboarding services in SNPN nor performing initial registration for onboarding services in SNPN, the UE shall set:
      1. 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
      2. 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 TS 24.301 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
  2. if the AUTHENTICATION REJECT message is received without integrity protection, 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 subclause 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:
    1. 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 subclause 5.3.20, list item 1)-a) of subclause 5.3.20.2 (if the UE is not operating in SNPN access operation mode) or list item a)-1) of subclause 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;
    2. 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 subclause 5.3.20, list item 1)-b) of subclause 5.3.20.2 (if the UE is not operating in SNPN access operation mode) or list item a)-2) of subclause 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;
    3. otherwise:
      1. 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 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 TS 24.301 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
      2. 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 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:
    1. 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
    2. 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" list for onboarding services, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to TS 23.122.
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.
Up
5.4.1.2.2.12  Abnormal cases in the UEp. 228
The following abnormal cases can be identified:
  1. 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 Section 3.2 of RFC 5448 for the case when the AUTN had been incorrect.
5.4.1.2.3  EAP-TLS related proceduresp. 230
5.4.1.2.3.1  Generalp. 230
The UE may support acting as EAP-TLS peer as specified in TS 33.501. The AUSF may support acting as EAP-TLS server as specified in TS 33.501. The AAA server of the CH or the DCS may support acting as EAP server of such EAP method as specified in TS 23.501.
The EAP-TLS enables mutual authentication of the UE and the network.
When initiating an EAP based primary authentication and key agreement procedure using EAP-TLS, 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 subclause 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 EAP-TLS:
  1. if the UE operates in SNPN access operation mode and:
    1. the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
    2. 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 TS 33.501 otherwise the ME shall generate EMSK as described in TS 33.501;
  2. if the AUSF acts as the EAP-TLS server, the AUSF shall generate EMSK as described in TS 33.501; and
  3. if the AAA server of the CH or the DCS acts as the EAP-TLS server, the AAA server of the CH or the DCS shall generate MSK as described in TS 33.501.
When handling of an EAP-request message results into generation of MSK or EMSK, if the UE operates in SNPN access operation mode and:
  1. the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
  2. 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 TS 33.501, and create a partial native 5G NAS security context identified by the ngKSI value received together with the EAP-request message in subclause 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.
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-TLS 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 TS 33.501.
If the UE does not accept the server certificate of 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 does not accept the client certificate of 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.
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 subclause. 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.
If the EAP-failure message is received in an AUTHENTICATION REJECT message:
  1. if the AUTHENTICATION REJECT message has been successfully integrity checked by the NAS:
    1. 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 or the UICC containing the USIM is removed.
      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 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 or the entry is updated;
      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 or the entry is updated.
      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" list for onboarding services, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to TS 23.122;
    2. if the UE is neither registered for onboarding services in SNPN nor performing initial registration for onboarding services in SNPN, the UE shall set:
      1. 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
      2. 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
    3. 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 TS 24.301 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
  2. if the AUTHENTICATION REJECT message is received without integrity protection, 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 subclause 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:
    1. 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 subclause 5.3.20, list item 1)-a) of subclause 5.3.20.2 (if the UE is not SNPN enabled or is not operating in SNPN access operation mode) or list item a) 1) of subclause 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;
    2. 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 subclause 5.3.20, list item 1)-b) of subclause 5.3.20.2 (if the UE is not operating in SNPN access operation mode) or list item a)-2) of subclause 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
    3. otherwise:
      1. if the AUTHENTICATION REJECT message is received over 3GPP access:
        1. 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 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;
          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;
        2. 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; and
        3. If the UE is operating in single-registration mode, the UE shall handle 4G-GUTI, TAI list and eKSI as specified in TS 24.301 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
      2. if the AUTHENTICATION REJECT message is received over non-3GPP access:
        1. 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 USIM shall be considered 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 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
        2. the UE shall set 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 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:
      1. 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
      2. 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" list for onboarding services, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to TS 23.122.
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:
  1. delete the valid KAUSF and the valid KSEAF, if any;
  2. 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 or MSK as described above:
    1. if the UE operates in SNPN access operation mode and:
      1. the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
      2. 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;
    2. 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 TS 33.501;
    3. create a partial native 5G NAS security context identified by the ngKSI value in the volatile memory of the ME; and
    4. store the KAMF in the created partial native 5G NAS security context; and
  3. 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.
Up
5.4.1.2.3A  Procedures related to EAP methods other than EAP-AKA' and EAP-TLS |R16|p. 234
5.4.1.2.3A.1  Generalp. 234
This subclause applies when an EAP method:
  1. supporting mutual authentication;
  2. supporting EMSK or MSK generation; and
  3. 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 TS 33.501. The AUSF may support acting as EAP server of such EAP method as specified in TS 33.501. The AAA server of the CH or the DCS may support acting as EAP server of such EAP method as specified in TS 23.501.
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 subclause 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:
  1. if:
    1. the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
    2. 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 TS 33.501 otherwise the ME shall generate EMSK as described in TS 33.501;
  2. if the AUSF acts as the EAP server, the AUSF shall generate EMSK as described in TS 33.501; and
  3. 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 TS 33.501.
When handling of an EAP-request message results into generation of MSK or EMSK, if:
  1. the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
  2. 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 TS 33.501, and create a partial native 5G NAS security context identified by the ngKSI value received together with the EAP-request message in subclause 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.
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 TS 33.501.
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:
  1. if the AUTHENTICATION REJECT message has been successfully integrity checked by the NAS:
    1. 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 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 or the entry is updated;
      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 or the entry is updated.
      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" list for onboarding services, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to TS 23.122; and
    2. 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
  2. if the AUTHENTICATION REJECT message is received without integrity protection, 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 subclause 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:
    1. 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 subclause 5.3.20.3 for the case that the 5GMM cause value received is #3;
    2. 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 subclause 5.3.20.3 for the case that the 5GMM cause value received is #3; or
    3. otherwise:
      1. 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 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
      2. 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 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:
      1. 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
      2. 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" list for onboarding services, enter state 5GMM-DEREGISTERED.PLMN-SEARCH, and perform an SNPN selection or an SNPN selection for onboarding services according to TS 23.122.
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:
  1. delete the valid KAUSF and the valid KSEAF, if any;
  2. 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:
    1. if:
      1. the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
      2. 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;
    2. 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 TS 33.501;
    3. create a partial native 5G NAS security context identified by the ngKSI value in the volatile memory of the ME; and
    4. store the KAMF in the created partial native 5G NAS security context; and
  3. 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.
Up
5.4.1.2.3A.2  EAP-TTLS with two phases of authentication p. 238
The UE may support acting as EAP peer of EAP-TTLS with two phases of authentication as specified in TS 33.501 and acting as peer of a legacy authentication protocol as specified in TS 33.501. The AUSF may support acting as EAP server of EAP-TTLS with two phases of authentication as specified in TS 33.501. The AAA server of the CH or the DCS may support acting a server of a legacy authentication protocol as specified in TS 33.501.
When EAP-TTLS with two phases of authentication as specified in TS 33.501 is used for primary authentication and key agreement in an SNPN:
  1. requirements in subclause 5.4.1.2.3A.1 shall apply in addition to requirements specified in TS 33.501 Annex U;
  2. indication to use MSK for derivation of KAUSF after success of primary authentication and key agreement procedure is not included in:
    1. the default UE credentials for primary authentication, if the UE is registering or registered for onboarding services in SNPN; or
    2. 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
  3. the SUPI of the UE is in the form of a SUPI with the SUPI format "network specific identifier" containing a network-specific identifier.
Up
5.4.1.2.3B  Procedures related to EAP methods used for primary authentication of an N5GC device |R16|p. 238
5.4.1.2.3B.1  Generalp. 238
This subclause applies when an EAP method:
  1. supporting mutual authentication; and
  2. other than EAP-AKA',
is used for primary authentication of an N5GC device, when an W-AGF supports acting on behalf of the N5GC device, the AMF supports serving the W-AGF acting on behalf of the N5GC device and the AUSF supports authentication of the N5GC device. EAP-TLS is an example of such EAP method.
The AUSF supporting authentication of the N5GC device shall support acting as EAP server of at least one such EAP method as specified in Annex O of TS 33.501.
The W-AGF acting on behalf of the N5GC device provides to the N5GC device an EAP-request message, an EAP-success message or an EAP-failure message received from the network according to subclause 5.4.1.2.1 and sends to the network according to subclause 5.4.1.2.1 an EAP-response provided by the N5GC device. The N5GC device can inform the W-AGF acting on behalf of the N5GC device that the N5GC device fails to authenticate the network. Details of communication between the N5GC device and the W-AGF acting on behalf of the N5GC device are out of scope of this specification.
When initiating an EAP based primary authentication and key agreement procedure using such EAP method, the network shall select an ngKSI value. The network shall send the selected ngKSI value to the W-AGF acting on behalf of the N5GC device along with each EAP message. The network shall send the ABBA value as described in subclause 9.11.3.10 to the W-AGF acting on behalf of the N5GC device along with the EAP-request message and EAP-success message. The W-AGF acting on behalf of the N5GC device shall not forward the ngKSI value or the ABBA value to the N5GC device.
If the N5GC device fails to authenticate the network, the W-AGF acting on behalf of the N5GC device shall start timer T3520 when the AUTHENTICATION RESPONSE message containing the EAP-response message is sent. Furthermore, the W-AGF acting on behalf of the N5GC device 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 W-AGF acting on behalf of the N5GC device shall stop timer T3520, if running, and then provides the EAP-request message to the N5GC device as normally.
If the network fails to authenticate the N5GC device, the network handling depends upon the type of identity used by the W-AGF acting on behalf of the N5GC device in the initial NAS message, that is:
  1. if the 5G-GUTI was used; or
  2. 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 W-AGF acting on behalf of the N5GC device 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 W-AGF acting on behalf of the N5GC device 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.
If the EAP-failure message is received in an AUTHENTICATION REJECT message, the W-AGF acting on behalf of the N5GC device 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 subclause 5.3.20). Additionally, the W-AGF acting on behalf of the N5GC device shall:
  1. if the counter for "USIM considered invalid for 5GS services over non-3GPP access" events has a value less than a W-AGF implementation-specific maximum value, proceed as specified in list item 1)-b) of subclause 5.3.20.2 for the case that the 5GMM cause value received is #3; or
  2. otherwise, set the update status to 5U3 ROAMING NOT ALLOWED, delete the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI. The USIM shall be considered invalid for 5GS services via non-3GPP access until switching off or the UICC containing the USIM is removed.
If the AUTHENTICATION REJECT message is received by the W-AGF acting on behalf of the N5GC device, the W-AGF acting on behalf of the N5GC device 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 W-AGF acting on behalf of the N5GC device shall consider the procedure complete.
Upon receiving an EAP-failure message, the W-AGF acting on behalf of the N5GC device shall consider the procedure complete.
Up
5.4.1.2.3C  Procedures related to EAP methods used for primary authentication of an AUN3 device |R18|p. 240
5.4.1.2.3C.1  Generalp. 240
This subclause applies when an EAP method is used for primary authentication of an AUN3 device, when a 5G-RG supports acting on behalf of the AUN3 device, the AMF supports serving the 5G-RG acting on behalf of the AUN3 device and the AUSF supports authentication of the AUN3 device. EAP-AKA' and EAP-TLS are examples of such EAP method.
The AUSF supporting authentication of the AUN3 device shall support acting as EAP server of at least one such EAP method as specified in annex Z of TS 33.501.
The 5G-RG acting on behalf of the AUN3 device provides to the AUN3 device an EAP-request message, an EAP-success message or an EAP-failure message received from the network according to subclause 5.4.1.2.1 and sends to the network according to subclause 5.4.1.2.1 an EAP-response provided by the AUN3 device. Details of communication between the AUN3 device and the 5G-RG acting on behalf of the AUN3 device are out of scope of this specification.
When initiating an EAP based primary authentication and key agreement procedure using such EAP method, the network shall select an ngKSI value. The network shall send the selected ngKSI value to the 5G-RG acting on behalf of the AUN3 device along with each EAP message. The network shall send the ABBA value as described in subclause 9.11.3.10 to the 5G-RG acting on behalf of the AUN3 device along with the EAP-request message and EAP-success message. The 5G-RG acting on behalf of the AUN3 device shall not forward the ngKSI value or the ABBA value to the AUN3 device.
If the 5G-RG acting on behalf of the AUN3 device is informed by AUN3 about failure to authenticate the network, the 5G-RG acting on behalf of the AUN3 device shall start timer T3520 when the AUTHENTICATION RESPONSE message containing the EAP-response message is sent. Furthermore, the 5G-RG acting on behalf of the AUN3 device 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 5G-RG acting on behalf of the AUN3 device shall stop timer T3520, if running, and then provides the EAP-request message to the AUN3 device as normally.
If the network fails to authenticate the AUN3 device, the network handling depends upon the type of identity used by the 5G-RG acting on behalf of the AUN3 device in the initial NAS message, that is:
  1. if the 5G-GUTI was used; or
  2. if the SUCI was used.
If the 5G-GUTI was used, the network should transport the EAP-failure message in the AUTHENTICATION RESULT message as specified in the EAP result message transport procedure, initiate an identification procedure to retrieve SUCI from the 5G-RG acting on behalf of the AUN3 device 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 5G-RG acting on behalf of the AUN3 device after an unsuccessful EAP based primary authentication and key agreement procedure, the network should transport the EAP-failure message in an AUTHENTICATION REJECT message as specified in the EAP result message transport procedure.
If the EAP-failure message is received in an AUTHENTICATION REJECT message, the 5G-RG acting on behalf of the AUN3 device 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 subclause 5.3.20). Additionally, the 5G-RG acting on behalf of the AUN3 device shall:
  1. if the counter for "USIM considered invalid for 5GS services over non-3GPP access" events has a value less than a 5G-RG implementation-specific maximum value, proceed as specified in list item 1)-b) of subclause 5.3.20.2 for the case that the 5GMM cause value received is #3; or
  2. otherwise, set the update status to 5U3 ROAMING NOT ALLOWED, delete the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI. The USIM shall be considered invalid for 5GS services via non-3GPP access until switching off or the UICC containing the USIM is removed.
If the AUTHENTICATION REJECT message is received by the 5G-RG acting on behalf of the AUN3 device, the 5G-RG acting on behalf of the AUN3 device 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 from the network, the 5G-RG acting on behalf of the AUN3 device shall consider the procedure complete. The network shall provide:
  1. the Master session key, if the AUN3 device does not support 5G key hierarchy; or
  2. the KWAGF key, if the AUN3 device supports 5G key hierarchy;
to the 5G-RG along with the EAP-success message as specified in subclauses 5.4.1.2.5.2 and 5.4.2.2. The 5G-RG acting on behalf of the AUN3 device shall derive the Pairwise master key from the Master session key or the KWAGF key as specified in subclause 7B.7 of TS 33.501. The 5G-RG acting on behalf of the AUN3 device provides the EAP-success message to the AUN3 device.
Upon receiving an EAP-failure message from the network, the 5G-RG acting on behalf of the AUN3 device shall consider the procedure complete.
Up
5.4.1.2.4  EAP message reliable transport procedurep. 241
5.4.1.2.4.1  Generalp. 241
The purpose of the EAP message reliable transport procedure is to provide a reliable transport of an EAP-request message, the ngKSI and the ABBA from the network to the UE and of an EAP-response message from the UE to the network.
The EAP message reliable transport procedure is initiated by an AUTHENTICATION REQUEST message with the EAP message IE.
5.4.1.2.4.2  EAP message reliable transport procedure initiation by the networkp. 241
In order to initiate the EAP message reliable transport procedure, the AMF shall create an AUTHENTICATION REQUEST message.
The AMF shall set the EAP message IE of the AUTHENTICATION REQUEST message to the EAP-request message to be sent to the UE. The AMF shall set the ngKSI IE of the AUTHENTICATION REQUEST message to the ngKSI value selected in subclause 5.4.1.2.2.2, subclause 5.4.1.2.3.1 or subclause 5.4.1.2.3A.1. In this release of specification, the AMF shall set the ABBA IE of the AUTHENTICATION REQUEST message with the length of ABBA IE to 2 and the ABBA contents to be 2 octets in length with value 0000H as described in subclause 9.11.3.10.
The AMF shall send the AUTHENTICATION REQUEST message to the UE, and the AMF shall start timer T3560 (see example in Figure 5.4.1.2.4.2.1).
Reproduction of 3GPP TS 24.501, Fig. 5.4.1.2.4.2.1: EAP message reliable transport procedure
Up
Upon receipt of an AUTHENTICATION REQUEST message with the EAP message IE, the UE handles the EAP message received in the EAP message IE and the ABBA of the AUTHENTICATION REQUEST message.
5.4.1.2.4.3  EAP message reliable transport procedure accepted by the UEp. 242
The UE shall create an AUTHENTICATION RESPONSE message.
If the received EAP message is an EAP-request message, the UE shall set the EAP message IE of the AUTHENTICATION RESPONSE message to the EAP-response message responding to the received EAP-request message.
The UE shall send the AUTHENTICATION RESPONSE message to the AMF.
Upon receipt of an AUTHENTICATION RESPONSE message, the AMF shall stop timer T3560. If the EAP message IE is included in the AUTHENTICATION RESPONSE message, the AMF handles the EAP message received in the EAP message IE of the AUTHENTICATION RESPONSE message.
Up
5.4.1.2.4.4  Abnormal cases on the network sidep. 242
The following abnormal cases can be identified:
  1. Expiry of timer T3560.
    The AMF shall, on the first expiry of the timer T3560, retransmit the AUTHENTICATION REQUEST message and shall reset and start timer T3560. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3560, the AMF shall abort the EAP based primary authentication and key agreement procedure and any ongoing 5GMM specific procedure, and release the N1 NAS signalling connection.
  2. Lower layers indication of non-delivered NAS PDU due to handover.
    If the AUTHENTICATION REQUEST message could not be delivered due to an intra AMF handover and the target TA is included in the TAI list, then upon successful completion of the intra AMF handover the AMF shall retransmit the AUTHENTICATION REQUEST message. If a failure of handover procedure is reported by the lower layer and the N1 NAS signalling connection exists, the AMF shall retransmit the AUTHENTICATION REQUEST message.
Up
5.4.1.2.4.5  Abnormal cases in the UEp. 242
The following abnormal cases can be identified:
  1. Authentication failure (5GMM cause #71 "ngKSI already in use").
    The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #71 "ngKSI already in use", to the network and start the timer T3520 (see example in Figure 5.4.1.3.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3510, T3517 or T3521). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with 5GMM cause #71 "ngKSI already in use", the network performs necessary actions to select a new ngKSI and send the same EAP-request message to the UE.
    Upon receiving a new AUTHENTICATION REQUEST message with the EAP message IE containing an EAP-request message from the network, the UE shall stop timer T3520, if running, process the EAP-request message as normal.
    If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid ngKSI and EAP-request message is received), the UE shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3510, T3517 or T3521) if they were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message.
  2. Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication from lower layers (if the EAP based primary authentication and key agreement procedure is triggered by a registration procedure).
    The UE shall stop the timer T3520, if running, and re-initiate the registration procedure.
  3. Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication with change in the current TAI (if the EAP based primary authentication and key agreement procedure is triggered by a service request procedure).
    The UE shall stop the timer T3520, if running.
    If the current TAI is not in the TAI list, the EAP based primary authentication and key agreement procedure shall be aborted and a registration procedure for mobility and periodic registration update shall be initiated.
    If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing procedure that triggered the EAP based primary authentication and key agreement procedure.
  4. Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication without change in the current TAI (if the authentication procedure is triggered by a service request procedure).
    The UE shall stop the timer T3520, if running. It is up to the UE implementation how to re-run the ongoing procedure that triggered the EAP based primary authentication and key agreement procedure.
  5. Network failing the authentication check.
    If the UE deems that the network has failed the authentication check, then it shall request RRC to locally release the RRC connection and treat the active cell as barred (see TS 38.304 or TS 36.304). The UE shall start any retransmission timers (e.g. T3510, T3517 or T3521), if they were running and stopped when the UE received the first AUTHENTICATION REQUEST message containing an ngKSI that was already in use.
  6. Change in the current TAI.
    If that the current TAI is not in the TAI list before the AUTHENTICATION RESPONSE message is sent, the UE may discard sending the AUTHENTICATION RESPONSE message to the network and continue with the initiation of the registration procedure for mobility and periodic registration update as described in subclause 5.5.1.3.2.
For item e, if no emergency service is started or is ongoing:
The UE shall stop timer T3520, if the timer is running and the UE enters 5GMM-IDLE mode, e.g. upon detection of a lower layer failure, release of the N1 NAS signalling connection, or as the result of an inter-system change in 5GMM-CONNECTED mode from N1 mode to S1 mode.
The UE shall deem that the network has failed the authentication check or assume that the authentication is not genuine and proceed as described in item e above if any of the following occurs:
  • the timer T3520 expires;
  • the UE detects any combination of the EAP-based authentication failures: transmission of AUTHENTICATION FAILURE message with 5GMM cause #71 "ngKSI already in use", transmission of AUTHENTICATION RESPONSE message with an EAP-response message after detecting an error as described in subclause 5.4.1.2.2.4, with an EAP-response message after not accepting of the server certificate as described in subclause 5.4.1.2.3.1 or with an EAP-response message after failing to authenticate the network as described in subclause 5.4.1.2.3A.1, during three consecutive authentication challenges. The EAP-request/AKA'-challenge challenges shall be considered as consecutive only, if the EAP-request/AKA'-challenge challenges causing the second and third EAP-based authentication failure are received by the UE, while the timer T3520 started after the previous EAP-based authentication failure is running. Not accepting of the server certificate shall be considered as consecutive only, if the EAP-request messages causing the second and third not accepting of the server certificate are received by the UE, while the timer T3520 started after the previous EAP request message causing the previous not accepting of the server certificate is running.
For item e if there is an emergency service started or is ongoing:
The UE shall stop timer T3520, if the timer is running and the UE enters 5GMM-IDLE mode, e.g. upon detection of a lower layer failure, release of the N1 NAS signalling connection, or as the result of an inter-system change in 5GMM-CONNECTED mode from N1 mode to S1 mode.
If a UE has an emergency PDU session established or is establishing an emergency PDU session, and sends an AUTHENTICATION FAILURE message to the AMF with the 5GMM cause appropriate for this cases (i.e. #71) or an AUTHENTICATION RESPONSE message containing an EAP-response message as described in subclause 5.4.1.2.2.4, containing an EAP-response message after not accepting of the server certificate as described in subclause 5.4.1.2.3.1 or containing an EAP-response message after failing to authenticate the network as described in subclause 5.4.1.2.3A.1, and receives the SECURITY MODE COMMAND message before the timeout of timer T3520, the UE shall deem that the network has passed the authentication check successfully, stop timer T3520, respectively, and execute the security mode control procedure.
If a UE has an emergency PDU session established or is establishing an emergency PDU session when timer T3520 expires, the UE shall not deem that the network has failed the authentication check and not behave as described in item e. Instead the UE shall continue using the current security context, if any, release all non-emergency PDU sessions, if any, by initiating UE-requested PDU session release procedure. If there is an ongoing PDU session establishment procedure, the UE shall release all non-emergency PDU sessions upon completion of the PDU session establishment procedure.
The UE shall start any retransmission timers (e.g. T3510, T3517 or T3521) if:
  • they were running and stopped when the UE received the AUTHENTICATION REQUEST message and detected an authentication failure; and
  • the procedures associated with these timers have not yet been completed.
The UE shall consider itself to be registered for emergency services.
Up
5.4.1.2.5  EAP result message transport procedurep. 244
5.4.1.2.5.1  Generalp. 244
The purpose of the EAP result message transport procedure is to provide an EAP-success message or an EAP-failure message, and ngKSI from the network to the UE, when the EAP message cannot be piggybacked by another NAS message.
The EAP result message transport procedure is initiated:
  • by an AUTHENTICATION RESULT message with the EAP message IE carrying the EAP-success message or the EAP-failure message; or
  • by an AUTHENTICATION REJECT message with the EAP message IE carrying the EAP-failure message.
5.4.1.2.5.2  EAP result message transport procedure initiation by the networkp. 244
In order to initiate the EAP result message transport procedure, the AMF shall create an AUTHENTICATION RESULT message or an AUTHENTICATION REJECT message.
The AMF shall set the EAP message IE of the AUTHENTICATION RESULT message to an EAP-success message or an EAP-failure message to be sent to the UE. If the AUTHENTICATION RESULT message is provided to a 5G-RG that is acting on behalf of an AUN3 device and the EAP message IE is set to an EAP-success message, the AMF shall include the AUN3 device security key IE in the AUTHENTICATION RESULT message with its value set to:
  1. the Master session key, if the AUN3 device does not support 5G key hierarchy; or
  2. the KWAGF key, if the AUN3 device supports 5G key hierarchy.
The AMF shall set the EAP message IE of the AUTHENTICATION REJECT message to an EAP-failure message to be sent to the UE. The AMF shall set the ngKSI IE of the AUTHENTICATION RESULT message or the AUTHENTICATION REJECT message to the ngKSI value selected in subclause 5.4.1.2.2.2, subclause 5.4.1.2.3.1 or subclause 5.4.1.2.3A.1.
The AMF shall send the AUTHENTICATION RESULT message or the AUTHENTICATION REJECT message to the UE (see example in Figure 5.4.1.2.5.2.1).
Reproduction of 3GPP TS 24.501, Fig. 5.4.1.2.5.2.1: EAP result message transport procedure
Up
Upon receipt of an AUTHENTICATION RESULT message or an AUTHENTICATION REJECT message with the EAP message IE, the UE handles the EAP message received in the EAP message IE and the ABBA if received of the AUTHENTICATION RESULT message or in the AUTHENTICATION REJECT message, and the 5G-RG that is acting on behalf of an AUN3 device handles the AUN3 device security key IE if received in the AUTHENTICATION RESULT message.

Up   Top   ToC