Content for TS 24.501 Word version: 19.0.0

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.1.3 5G AKA based primary authentication and key agreement procedure 5.4.1.3.1 General 5.4.1.3.2 Authentication initiation by the network 5.4.1.3.3 Authentication response by the UE 5.4.1.3.4 Authentication completion by the network 5.4.1.3.5 Authentication not accepted by the network 5.4.1.3.6 Authentication not accepted by the UE 5.4.1.3.7 Abnormal cases
...

5.4.1.3 5G AKA based primary authentication and key agreement procedure p. 255

5.4.1.3.1 General p. 255

The purpose of the 5G AKA 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). The cases when the 5G AKA based primary authentication and key agreement procedure is used are defined in TS 33.501.

The network initiates the 5G AKA based primary authentication and key agreement procedure by sending an AUTHENTICATION REQUEST message to the UE without the EAP message IE. The network shall include the ngKSI and the ABBA in AUTHENTICATION REQUEST message.

The 5G AKA based primary authentication and key agreement procedure is always initiated and controlled by the network. However, the UE can reject the 5G authentication challenge sent by the network.

The UE shall proceed with a 5G authentication challenge only if a USIM is present.

A partial native 5G NAS security context is established in the UE and the network when a 5G authentication is successfully performed. During a successful 5G AKA 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 compute new keys KAUSF, KSEAF and KAMF. KAMF is stored in the 5G NAS security contexts (see TS 33.501) of both the network and in the volatile memory of the ME while registered to the network, and is the root for the 5GS integrity protection and ciphering key hierarchy.

Upon successful completion of the 5G AKA based primary authentication, the AMF shall initiate a security mode control procedure (see subclause 5.4.2) to take the new partial native 5G NAS security context into use.

5.4.1.3.2 Authentication initiation by the network p. 255

The network may initiate a 5G AKA based primary authentication and key agreement procedure for a UE in 5GMM-CONNECTED mode at any time. For restrictions applicable after handover or inter-system change to N1 mode in 5GMM-CONNECTED mode, see subclause 5.5.1.3.3.

The network initiates the 5G AKA based primary authentication and key agreement procedure by sending an AUTHENTICATION REQUEST message to the UE and starting the timer T3560 (see example in Figure 5.4.1.3.2.1). The AUTHENTICATION REQUEST message shall contain the parameters necessary to calculate the authentication response (see TS 33.501). This message shall include the ngKSI that will be used by the UE and AMF to identify the KAMF and the partial native security context that is created if the authentication is successful. This message shall also include the ABBA parameter. In this release of specification, the network shall set 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.

If an ngKSI is contained in an initial NAS message during a 5GMM procedure, the network shall include a different ngKSI value in the AUTHENTICATION REQUEST message when it initiates a 5G AKA based primary authentication and key agreement procedure.

Reproduction of 3GPP TS 24.501, Fig. 5.4.1.3.2.1: 5G AKA based primary authentication and key agreement procedure

Figure 5.4.1.3.2.1: 5G AKA based primary authentication and key agreement procedure

5.4.1.3.3 Authentication response by the UE p. 256

The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in subclause 5.4.1.3.6 and 5.4.1.3.7 case l, the UE shall process the 5G authentication challenge data and respond with an AUTHENTICATION RESPONSE message to the network.

Upon a successful 5G authentication challenge, the UE shall determine the PLMN identity in case of PLMN or the SNPN identity in case of SNPN to be used for the calculation of the new KAMF from the 5G authentication challenge data according to the following rules:

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 or the SNPN identity of the selected SNPN; and
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 in case of PLMN or the SNPN identity in case of SNPN 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 in case of PLMN or the SNPN identity in case of SNPN 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.

Upon a successful 5G authentication challenge, the new KAMF calculated from the 5G authentication challenge data shall be stored in a new 5G NAS security context in the volatile memory of the ME.

The USIM will compute the authentication response (RES) using the 5G authentication challenge data received from the ME, and pass RES to the ME. From the RES, RES* is then generated according to Annex A of TS 33.501.

In order to avoid a synchronisation failure, when the UE receives an AUTHENTICATION REQUEST message, the UE shall store the received RAND together with the RES*, in the volatile memory of the ME. When the UE receives a subsequent AUTHENTICATION REQUEST message, if the stored RAND value is equal to the new received value in the AUTHENTICATION REQUEST message, then the ME shall not pass the RAND to the USIM, but shall send the AUTHENTICATION RESPONSE message with the stored RES*. If there is no valid stored RAND in the ME or the stored RAND is different from the new received value in the AUTHENTICATION REQUEST message, the ME shall pass the RAND to the USIM, shall override any previously stored RAND and RES* with the new ones and start, or reset and restart timer T3516.

The RAND and RES* values stored in the ME shall be deleted and timer T3516, if running, shall be stopped:

upon receipt of a
1. SECURITY MODE COMMAND message,
2. SERVICE REJECT message,
3. REGISTRATION REJECT message,
4. REGISTRATION ACCEPT message,
5. AUTHENTICATION REJECT message, or
6. SERVICE ACCEPT message;
upon expiry of timer T3516;
if the UE enters the 5GMM state 5GMM-DEREGISTERED or 5GMM-NULL; or
if the UE enters 5GMM-IDLE mode.

5.4.1.3.4 Authentication completion by the network p. 257

Upon receipt of an AUTHENTICATION RESPONSE message, the network stops the timer T3560 and checks the correctness of RES* (see TS 33.501).

If the 5G AKA based primary authentication and key agreement procedure has been completed successfully and the related ngKSI is stored in the 5G NAS security context of the network, the network shall include a different ngKSI value in the AUTHENTICATION REQUEST message when it initiates a new 5G AKA based primary authentication and key agreement procedure.

Upon receipt of an AUTHENTICATION FAILURE message, the network stops the timer T3560. In the case where the 5GMM cause #21 "synch failure" is received, the core network may renegotiate with the UDM/AUSF and provide the UE with new authentication parameters.

5.4.1.3.5 Authentication not accepted by the network p. 257

If the authentication response (RES) returned by the UE is not valid, the network response 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 initiate an identification procedure to retrieve SUCI from the UE and restart the 5G AKA 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 5G AKA 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 5G AKA based primary authentication and key agreement procedure, the network should send an AUTHENTICATION REJECT message to the UE. The network shall maintain, if any, the 5GMM-context and 5G NAS security context of the UE unchanged.

Upon receipt of an AUTHENTICATION REJECT message,

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 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 until switching off or the UICC containing the USIM is removed.
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 TS 23.122; 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:
  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
if the AUTHENTICATION REJECT message is received without integrity protection and if timer T3516 or T3520 is running, 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 non-EPS service 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 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.
    - 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 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 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, T3516, T3517, T3519, T3520 or T3521 (if they were running), enter state 5GMM-DEREGISTERED and delete any stored SUCI.

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 the authentication failure in the present subclause. The AMF may continue a current 5GMM specific procedure.

5.4.1.3.6 Authentication not accepted by the UE p. 260

In the 5G authentication challenge, the UE shall check the 5G authentication challenge data (RAND, AUTN and ngKSI) received in the AUTHENTICATION REQUEST message to verify authenticity of the 5G core network.

The ME shall check that ngKSI received in the AUTHENTICATION REQUEST message is not already in use. The ME shall forward the RAND and AUTN to the USIM to check.

The UE may reject the core network due to an incorrect AUTN or ngKSI parameter. If the UE has to reject the 5G authentication challenge, the UE shall return AUTHENTICATION FAILURE message to the network with a cause value indicating the reason for the failure (see TS 33.501).

Incorrect 5G authentication challenge data contains four possible causes for authentication failure:

MAC code failure:
If the UE finds the MAC code (supplied by the core network in the AUTN parameter) to be invalid, the UE shall send an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #20 "MAC failure". The UE shall then follow the procedure described in subclause 5.4.1.3.7, item c.
Non-5G authentication unacceptable:
If the UE finds that the "separation bit" in the AMF field of AUTN supplied by the core network is set to 0, the UE shall send an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #26 "non-5G authentication unacceptable" (see subclause 6.1.3 in TS 33.501). The UE shall then follow the procedure described in subclause 5.4.1.3.7, item d.
ngKSI already in use:
If the UE detects that ngKSI received in the AUTHENTICATION REQUEST message is already in use in the UE shall send an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #71 "ngKSI already in use". The UE shall then follow the procedure described in subclause 5.4.1.3.7, item e.
SQN failure:
If the UE finds the sequence number SQN (supplied by the core network in the AUTN parameter) to be out of range, the UE shall send an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #21 "synch failure" and a re-synchronization token AUTS provided by the USIM (see TS 33.102). The UE shall then follow the procedure described in subclause 5.4.1.3.7, item f.

If the UE returns an AUTHENTICATION FAILURE message to the network, the UE shall delete any previously stored RAND and RES* and shall stop timer T3516, if running.

If the UE has an emergency PDU session established or is establishing such a PDU session, additional UE requirements are specified in subclause 5.4.1.3.7, under "for items c, d, e and f".

5.4.1.3.7 Abnormal cases p. 260

Lower layer failure.

Upon detection of lower layer failure before the AUTHENTICATION RESPONSE message is received, the network shall abort the procedure.

Expiry of timer T3560.

The network 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 network shall abort the 5G AKA based primary authentication and key agreement procedure and any ongoing 5GMM specific procedure and release the N1 NAS signalling connection.

Authentication failure (5GMM cause #20 "MAC failure").

The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #20 "MAC failure" according to subclause 5.4.1.3.6, to the network and start 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 #20 "MAC failure", the network may initiate the identification procedure described in subclause 5.4.3. This is to allow the network to obtain the SUCI from the UE. The network may then check that the 5G-GUTI originally used in the 5G authentication challenge corresponded to the correct SUPI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall proceed as specified in subclause 5.4.3.3.

If the mapping of 5G-GUTI to SUPI in the network was incorrect, the network should respond by sending a new AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST message from the network, the UE shall stop the timer T3520, if running, and then process the 5G challenge information as normal. If the mapping of 5G-GUTI to SUPI in the network was correct, the network should terminate the 5G AKA based primary authentication and key agreement procedure by sending an AUTHENTICATION REJECT message (see subclause 5.4.1.3.5).

If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid SQN and MAC 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.

If the UE receives the second AUTHENTICATION REQUEST message, and the MAC value cannot be resolved, the UE shall follow the procedure specified in this subclause, item c, starting again from the beginning, or if the message contains a UMTS authentication challenge, the UE shall follow the procedure specified in item d. If the SQN is invalid, the UE shall proceed as specified in item f.

Reproduction of 3GPP TS 24.501, Fig. 5.4.1.3.7.1: Authentication failure during 5G AKA based primary authentication and key agreement procedure

Figure 5.4.1.3.7.1: Authentication failure during 5G AKA based primary authentication and key agreement procedure

Authentication failure (5GMM cause #26 "non-5G authentication unacceptable").

The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #26 "non-5G authentication unacceptable", 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 #26 "non-5G authentication unacceptable", the network may initiate the identification procedure described in subclause 5.4.3. This is to allow the network to obtain the SUCI from the UE. The network may then check that the 5G-GUTI originally used in the 5G authentication challenge corresponded to the correct SUPI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall proceed as specified in subclause 5.4.3.3.

If the mapping of 5G-GUTI to SUPI in the network was incorrect, the network should respond by sending a new AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST message from the network, the UE shall stop the timer T3520, if running, and then process the 5G challenge information as normal. If the mapping of 5G-GUTI to SUPI in the network was correct, the network should terminate the 5G AKA based primary authentication and key agreement authentication procedure by sending an AUTHENTICATION REJECT message (see subclause 5.4.1.3.5).

If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid 5G authentication challenge 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.

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 5G authentication challenge to the UE.

Upon receiving the new AUTHENTICATION REQUEST message from the network, the UE shall stop the timer T3520, if running, and then process the 5G challenge information as normal.

If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid ngKSI, SQN and MAC 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.

Authentication failure (5GMM cause #21 "synch failure").

The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #21 "synch failure", 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 the 5GMM cause #21 "synch failure", the network shall use the returned AUTS parameter from the authentication failure parameter IE in the AUTHENTICATION FAILURE message, to re-synchronise. The re-synchronisation procedure requires the AMF to delete all unused authentication vectors for that SUPI and obtain new vectors from the UDM/AUSF. When re-synchronisation is complete, the network shall initiate the 5G AKA based primary authentication and key agreement procedure. Upon receipt of the AUTHENTICATION REQUEST message, the UE shall stop the timer T3520, if running.

If the network is validated successfully (a new AUTHENTICATION REQUEST message is received which contains a valid SQN and MAC) while T3520 is running, 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.

Upon receipt of an AUTHENTICATION REJECT message, the UE shall perform the actions as specified in subclause 5.4.1.3.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 incorrect authentication challenge data causing authentication failure.

Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication from lower layers (if the 5G AKA 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.

Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication with change in the current TAI (if the 5G AKA 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 5G AKA 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 5G AKA based primary authentication and key agreement procedure.

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 5G AKA based primary authentication and key agreement procedure.

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.

Change in the current TAI.

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

AUTHENTICATION REJECT message is received without integrity protection and neither timer T3516 nor T3520 is running.

If an AUTHENTICATION REJECT message is received without integrity protection and if neither timer T3516 nor T3520 is running, then the UE shall discard the AUTHENTICATION REJECT message. Additionally, the UE may request RRC to locally release the RRC connection and treat the active cell as barred (see TS 38.304 or TS 36.304).

For items c, d, e, and f 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 g above if any of the following occurs:

the timer T3520 expires;
the UE detects any combination of the 5G authentication failures: 5GMM causes #20 "MAC failure", #21 "synch failure", #26 "non-5G authentication unacceptable" or #71 "ngKSI already in use", during three consecutive authentication challenges. The 5G authentication challenges shall be considered as consecutive only, if the 5G authentication challenges causing the second and third 5G authentication failure are received by the UE, while the timer T3520 started after the previous 5G authentication failure is running.

For items c, d, e, and f if there is an emergency service started or is ongoing:

If there is an ongoing:

service request procedure for emergency services fallback the UE shall abort the service request procedure, stop timer T3517 and locally release any resources allocated for the service request procedure and enter state 5GMM-REGISTERED; or
registration procedure for mobility and periodic registration update triggered upon a request from the upper layers to perform an emergency services fallback procedure the UE shall abort the registration procedure for mobility and periodic registration update, stop timer T3510 and locally release any resources allocated for the registration procedure for mobility and periodic registration update and enter the state 5GMM-REGISTERED; and

the UE shall attempt to select an E-UTRA cell connected to EPC or 5GCN according to the domain priority and selection rules specified in TS 23.167. If the UE finds a suitable E-UTRA cell, it proceeds with the appropriate EMM or 5GMM procedures. If the UE operating in single-registration mode has changed to S1 mode, it shall disable the N1 mode capability for 3GPP access.

Depending on local requirements or operator preference for emergency services, if the UE has an emergency PDU session established or is establishing an emergency PDU session, the AMF need not follow the procedures specified for the authentication failure specified in the present subclause. The AMF may respond to the AUTHENTICATION FAILURE message by initiating the security mode control procedure selecting the "null integrity protection algorithm" 5G-IA0, "null ciphering algorithm" 5G-EA0 or may abort the 5G AKA based primary authentication and key agreement procedure and continue using the current security context, if any. The AMF shall indicate to the SMF to perform the release of all non-emergency PDU sessions, if any. If there is an ongoing PDU session establishment procedure, the AMF shall indicate to the SMF to perform the release of all non-emergency PDU sessions upon completion of the PDU session establishment procedure. The network shall behave as if the UE is registered for emergency services.

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 these cases (#20, #21, #26, or #71 respectively) 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 g. 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 behave as if the UE is registered for emergency services.