Content for  TS 33.501  Word version:  18.4.0

One state machine in the UE and AMF is handling the registration states over 3GPP access and a second state machine is handling the registration states over non-3GPP access. This clause and its subclauses applies to both 3GPP access and non-3GPP access. UDM manages separate/independent UE Registration procedure for each access. The AMF shall associate Registration state per access type with the UE.

There are different reasons for transition to the RM-DEREGISTERED state. If a NAS messages leads to state transition to RM-DEREGISTERED, it shall be security protected by the current 5G NAS security context (mapped or native), if such exists in the UE or the AMF. On transitioning to RM-DEREGISTERED, the UE and AMF shall do the following:

1. If they have a full non-current native 5G NAS security context and a current mapped 5G NAS security context, then they shall make the non-current native 5G NAS security context the current one.
2. They shall delete any mapped or partial 5G NAS security contexts they hold.

Handling of the remaining security parameters for each of these cases are given below:

1. Registration reject: All remaining security parameters shall be removed from the UE and AMF
2. Deregistration:
   1. UE-initiated
      1. If the reason is switch off then all the remaining security parameters shall be removed from the UE and AMF with the exception of the current native 5G NAS security context (as in clause 6.1.1), which should remain stored in the AMF and UE.
      2. If the reason is not switch off then AMF and UE shall keep all the remaining security parameters.
   2. AMF-initiated
      1. Explicit: all the remaining security parameters shall be kept in the UE and AMF if the de-registration type is "re-registration required".
      2. Implicit: all the remaining security parameters shall be kept in the UE and AMF.
   3. UDM/ARPF-initiated: If the message is "subscription withdrawn" then all the remaining security parameters shall be removed from the UE and AMF.
3. Registration reject: There are various reasons for Registration reject. The action to be taken shall be as given in TS 24.501.

Storage of the full native 5G NAS security context including the pair(s) of distinct NAS COUNT values associated with each access together with respective NAS connection identifier, excluding the UE security capabilities and the keys KNASint and KNASenc, in the UE when the UE transitions to RM-DEREGISTERED state is done as follows:

1. If the ME does not have a full native 5G NAS security context in volatile memory, any existing native 5G NAS security context stored on the USIM or in non-volatile memory of the ME shall be marked as invalid.
2. If the USIM supports RM parameters storage, then the ME shall store the full native 5G NAS security context parameters on the USIM (except for KNASint and KNASenc), mark the native 5G NAS security context on the USIM as valid, and not keep any native 5G NAS security context in non-volatile ME memory.
3. If the USIM does not support RM parameters storage, then the ME shall store the full native 5G NAS security context (except for KNASint and KNASenc) in a non-volatile part of its memory and mark the native 5G NAS security context in its non-volatile memory as valid.
   d) For the case that the AMF or the UE enter RM-DEREGISTERED state without using any of the above procedures, the handling of the remaining security parameters shall be as specified in TS 24.501.

One state machine in the UE and AMF is handling the connection states over 3GPP access and a second state machine is handling the connection states over non-3GPP access. This clause and its subclauses applies to both 3GPP access and non-3GPP access when not explicitly stated.

The UE sends an initial NAS message to initiate transition from CM-IDLE to CM-CONNECTED state (see TS 24.501. If a full native 5G NAS security context is already available in the UE and the AMF, then the UE shall directly take into use the available full 5G NAS security context and use it to protect the initial NAS message using the distinct pair of NAS COUNTs together with the NAS connection identifier for this access. If the UE is simultaneously registered over both 3GPP access and non-3GPP access in the same AMF, then if there is a need for the AMF to take a new partial 5G NAS security context into use on this access (access A), derived from primary authentication executed on a different access, then the AMF needs to send a NAS SMC to the UE on this access (access A) in order to take the new partial 5G NAS security context also into use on this access as described in clause 6.4.2.2. On transitions to CM-CONNECTED, the AMF should be able to check whether a new authentication is required, e.g. because of prior inter-provider handover. If the UE is simultaneously registered over both 3GPP access and non-3GPP access in the same AMF, then if a new primary authentication is run, then the new derived partial 5G NAS security context needs to be taken into use on this access (access A) with a NAS SMC using the distinct pair of NAS COUNTs for this access. But the new derived partial 5G NAS security context also needs to be taken into use on the other accesses (access B) with a NAS SMC using the distinct pair of NAS COUNTs for the respective access as part of the NAS procedure as described in clause 6.4.2.2. When cryptographic protection for radio bearers is established RRC protection keys and UP protection keys shall be generated as described in subclause 6.2.3.1 while KAMF is assumed to be already available in the AMF. The initial NAS message shall be integrity protected by the current 5G NAS security context if such exists using the distinct pair of NAS COUNTs together with the NAS connection identifier for this access. If no current 5G NAS security context exists the ME shall signal "no key available" in the initial NAS message. KAMF may have been established in the AMF as a result of a primary authentication run on this access or on a different access, or as a result of a 5G security context transfer from another AMF during N2 handover or idle mode mobility. When the gNB/ng-eNB releases the RRC connection, the UE and the gNB/ng-eNB shall delete the keys they store such that state in the network for CM-IDLE state UEs will only be maintained in the AMF.

This subclause applies to establishment of keys for cryptographically protected radio bearers in 3GPP access only. The procedure the UE uses to establish cryptographic protection for radio bearers is initiated by an NAS Service Request message or Registration Request message with "PDU session(s) to be re-activated" included from the UE to the AMF. The AMF may initiate the procedure to establish cryptographic protection for radio bearers when "PDU session(s) to be re-activated" is not included in the Registration request and but there is pending downlink UP data or pending downlink signalling. Upon receipt of the NAS message, if the AMF does not require a NAS SMC procedure before initiating the NGAP procedure INITIAL CONTEXT SETUP, the AMF shall derive key KgNB/KeNB as specified in Annex A using the uplink NAS COUNT (see TS 24.501) corresponding to the NAS message that initiated transition from CM-IDLE to CM-CONNECTED state and the KAMF of the current 5G NAS security context. The AMF shall communicate the KgNB/KeNB to the serving gNB/ng-eNB in the NGAP procedure INITIAL CONTEXT SETUP. The UE shall derive the KgNB/KeNB from the KAMF of the current 5G NAS security context using the NAS uplink COUNT corresponding to the NAS message that initiated transition from CM-IDLE to CM-CONNECTED state. As a result of the NAS Service Request or Registration procedure, with "PDU session(s) to be re-activated" radio bearers are established, and the gNB/ng-eNB sends an AS SMC to the UE. When the UE receives the AS SMC without having received a NAS Security Mode Command, it shall use the NAS uplink COUNT corresponding to the NAS message that initiated transition from CM-IDLE to CM-CONNECTED state as freshness parameter in the derivation of the KgNB/KeNB. The KDF as specified in Annex A shall be used for the KgNB/KeNB derivation using the KAMF of the current 5G NAS security context. From the KgNB/KeNB the RRC protection keys and the UP protection keys are derived by the UE and the gNB/ng-eNB as described in subclause 6.2. If the NAS procedure establishing radio bearers contains a primary authentication run (which is optional), the NAS uplink and downlink COUNT for the new KAMF shall be set to the start values (i.e. zero). If the NAS procedure establishing radio bearers contains a NAS SMC (which is optional), the value of the uplink NAS COUNT corresponding to the most recent NAS Security Mode Complete shall be used as freshness parameter in the KgNB/KeNB derivation from fresh KAMF of the current 5G NAS security context when executing an AS SMC. The KDF as specified in Annex A shall be used for the KgNB/KeNB derivation also in this case. The case that the UE is using Control Plane CIoT 5GS optimisation to send data over NAS and N3 bearers are established (due to either a request from the UE or decided by the AMF - see clause 5.31.4 of TS 23.501) works as follows. The UE and AMF shall always use the value of the uplink NAS COUNT from the Control Plane Service Request that was sent to transition the UE from idle to active as freshness parameter in the derivation of the KeNB unless there has been a subsequent NAS Security Mode Complete. If there was a subsequent NAS Security Mode Complete, then the UE and AMF use the value of the uplink NAS COUNT from the latest NAS Security Mode Complete message as freshness parameter in the derivation of the KeNB.

In the case of non-3GPP access, there are no individual radio bearers set up between the UE and N3IWF. For non-3GPP access, an IPsec tunnel is established between the UE and the interworking function N3IWF. The main SA is used solely for the transport of NAS messages between the UE and the AMF/SMF. Corresponding to the PDU session of the UE, based on the policies and configuration, N3IWF determines the number of IPsec child SAs to be established and the QoS profiles associated with each IPsec child SA. For example, the N3IWF may decide to establish one IPsec child SA and associate all QoS profiles with this IPsec child SA. In this case, all QoS Flows of the PDU Session would be transferred over one IPsec child SA. N3IWF may also decide to establish different child SAs corresponding to the different QoS flows. Corresponding to radio bearers in 3GPP access which are mapped to QoS values, for non-3GPPaccess there are only child SAs mapped to QoS values. Cryptographically each child SA is different with distinct key materials exchanged as per RFC 7296.

On CM-CONNECTED to CM-IDLE transitions the gNB/ng-eNB does no longer need to store state information about the corresponding UE. In particular, on CM-CONNECTED to CM-IDLE transitions:

• The gNB/ng-eNB and the UE shall release all radio bearers and delete the AS security context.
• AMF and the UE shall keep the 5G NAS security context stored.

In 5G, the RRC_INACTIVE state allows gNB/ng-eNB to suspend the UE's RRC connection while the gNB/ng-eNB and the UE continue to maintain the UE 5G AS security context. The UE RRC connection can be resumed at a later time by allowing the UE to transition into RRC__CONNECTED state. The UE may transition from RRC_INACTIVE state to RRC_CONNECTED state to the same last serving gNB/ng-eNB which sent the UE into RRC_INACTIVE state or to a different gNB/ng-eNB. While the UE is in RRC_INACTIVE state, the UE and last serving gNB/ng-eNB store the UE 5G AS security context which can be reactivated when the UE transitions from RRC_INACTIVE to RRC_CONNECTED. The gNB/ng-eNB and the UE shall behave as defined in following subclauses. The ng-eNB connected to 5GC shall also support the same security handling at RRC state transitions.

The gNB/ng-eNB shall send to the UE an RRCRelease with suspendConfig message that is ciphered and integrity protected in PDCP layer using a current AS security context. The gNB/ng-eNB shall include a fresh I-RNTI, and an NCC in that RRCRelease with suspendConfig message. The I-RNTI is used for context identification, and the UE ID part of the I-RNTI assigned by the gNB/ng-eNB shall be different in consecutive suspends of the same UE. This is to avoid tracking of UEs based on the I-RNTI. If the gNB/ng-eNB has a fresh and unused pair of {NCC, NH}, the gNB/ng-eNB shall include the NCC in the RRCRelease with suspendConfig message. Otherwise, the gNB/ng-eNB shall include the same NCC associated with the current KgNB in the RRCRelease with suspendConfig message. The NCC is used for AS security. The gNB/ng-eNB shall delete the current AS keys KRRCenc, KUPenc (if available), and KUPint (if available) after sending the RRCRelease with suspendConfig message to the UE, but shall keep the current AS key KRRCint. If the sent NCC value is fresh and belongs to an unused pair of {NCC, NH}, the gNB/ng-eNB shall save the pair of {NCC, NH} in the current UE AS security context and shall delete the current AS key KgNB. If the sent NCC value is equal to the NCC value associated with the current KgNB, the gNB/ng-eNB shall keep the current AS key KgNB and NCC. The gNB/ng-eNB shall store the sent I-RNTI together with the current UE context including the remainder of the AS security context. Upon receiving the RRC Release with suspendConfig message from the gNB/ng-eNB, the UE shall verify that the integrity of the received RRCRelease with suspendConfig message is correct by checking the PDCP MAC-I. If this verification is successful, then the UE shall take the received NCC value and save it as stored NCC with the current UE context. The UE shall delete the current AS keys KRRCenc, KUPenc (if available), and KUPint (if available), but keep the current AS key KRRCint key. If the stored NCC value is different from the NCC value associated with the current KgNB, the UE shall delete the current AS key KgNB. If the stored NCC is equal to the NCC value associated with the current KgNB, the UE shall keep the current AS key KgNB. The UE shall store the received I-RNTI together with the current UE context including the remainder of the AS security context, for the next state transition.

When the UE decides to resume the RRC connection to transit from RRC_INACTIVE to RRC_CONNECTED, the UE sends RRCResumeRequest message on SRB0 and hence it is not integrity protected. However, the RRCResumeRequest message shall include the I-RNTI and a ResumeMAC-I/shortResumeMAC-I. The I-RNTI (short or full I-RNTI) is used for context identification and its value shall be the same as the I-RNTI that the UE had received from the source gNB/ng-eNB in the RRCRelease with suspendConfig message. The ResumeMAC-I/shortResumeMAC-I is a 16-bit message authentication token, the UE shall calculate it using the integrity algorithm (NIA or EIA) in the stored AS security context, which was negotiated between the UE and the source gNB/ng-eNB and the current KRRCint with the following inputs:

• KEY : it shall be set to current KRRCint;
• BEARER : all its bits shall be set to 1.
• DIRECTION : its bit shall be set to 1;
• COUNT : all its bits shall be set to 1;
• MESSAGE : it shall be set to VarResumeMAC-Input/VarShortInactiveMAC-Input as defined in TS 38.331 for gNB and in TS 36.331 for ng-eNB with following inputs:
  source PCI, target Cell-ID, source C-RNTI.

For protection of all RRC messages except RRCReject message following the sent RRCResumeRequest message, the UE shall derive a KNG-RAN* using the target PCI, target ARFCN-DL/EARFCN-DL and the KgNB/NH based on either a horizontal key derivation or a vertical key derivation as defined in clause 6.9.2.1.1 and Annex A.11/Annex A.12. The UE shall further derive KRRCint, KRRCenc, KUPenc (optionally), and KUPint (optionally) from the newly derived KNG-RAN*. When the target gNB/ng-eNB receives the RRCResumeRequest message from the UE, the target gNB/ng-eNB extracts the I-RNTI from the RRCResumeRequest message. The target gNB/ng-eNB contacts the source gNB/ng-eNB based on the information in the I-RNTI by sending an Xn-AP Retrieve UE Context Request message with the following included: I-RNTI, the ResumeMAC-I/shortResumeMAC-I and target Cell-ID, in order to allow the source gNB/ng-eNB to validate the UE request and to retrieve the UE context including the UE 5G AS security context. The source gNB/ng-eNB retrieves the stored UE context including the UE 5G AS security context from its database using the I-RNTI. The source gNB/ng-eNB verifies the ResumeMAC-I/shortResumeMAC-I using the current KRRCint key stored in the retrieved UE 5G AS security context (calculating the ResumeMAC-I/shortResumeMAC-I in the same way as described above). If the verification of the ResumeMAC-I/shortResumeMAC-I is successful, then the source gNB/ng-eNB calculates KNG-RAN* using the target cell PCI, target ARFCN-DL/EARFCN-DL and the KgNB/NH in the current UE 5G AS security context based on either a horizontal key derivation or a vertical key derivation according to whether the source gNB/ng-eNB has an unused pair of {NCC, NH} as described in Annex A.11/Annex A.12. The source gNB/ng-eNB can obtain the target PCI and target ARFCN-DL/EARFCN-DL from a cell configuration database by means of the target Cell-ID which was received from the target gNB/ng-eNB. Then the source gNB/ng-eNB shall respond with an Xn-AP Retrieve UE Context Response message to the target gNB/ng-eNB including the UE context that contains the UE 5G AS security context. The UE 5G AS security context sent to the target gNB/ng-eNB shall include the newly derived KNG-RAN*, the NCC associated to the KNG-RAN*, the UE 5G security capabilities, UP security policy, the UP security activation status with the corresponding PDU session ID(s), and the ciphering and integrity algorithms used by the UE with the source cell. The target gNB/ng-eNB shall check if it supports the ciphering and integrity algorithms the UE used with the last source cell. If the target gNB/ng-eNB does not support the ciphering and integrity algorithms used in the last source cell or if the target gNB/ng-eNB prefers to use different algorithms than the source gNB/ng-eNB, then the target gNB/ng-eNB shall send an RRC Setup/RRCSetup message on SRB0 to the UE in order to proceed with RRC connection establishment as if the UE was in RRC_IDLE (i.e., a fallback procedure). If the target gNB/ng-eNB supports the ciphering and integrity algorithms used with the last source cell and these algorithms are the chosen algorithms by the target gNB/ng-eNB, the target gNB/ng-eNB shall derive new AS keys (RRC integrity key, RRC encryption key and UP keys) using the algorithms the UE used with the source cell and the received KNG-RAN*. The target gNB/ng-eNB shall reset all PDCP COUNTs to 0 and activate the new keys in PDCP layer. The target gNB/ng-eNB shall respond to the UE with an RRC Resume message on SRB1 which is integrity protected and ciphered in PDCP layer using the new RRC keys. If the UP security activation status can be supported in the target gNB/ng-eNB, the target gNB/ng-eNB shall use the UP security activations that the UE used at the last source cell. Otherwise, the target gNB/ng-eNB shall respond with an RRC Setup message to establish a new RRC connection with the UE. When the UE receives the RRCResume message, the UE shall decrypt the message using the KRRCenc that was derived based on the newly derived KNG-RAN*. The UE shall also verify the <RRC Connection Resume> message by verifying the PDCP MAC-I using the KRRCint that was derived from the newly derived KNG-RAN* If verification of the RRCResume message is successful, the UE shall delete the current KRRCint key and the UE shall save the KRRCint, KRRCenc, KUPenc (optionally), and KUPint (optionally) from the newly derived KNG-RAN* as part of the UE current AS security context. In this case, the UE shall send the RRCResumeComplete message both integrity protected and ciphered to the target gNB/ng-eNB on SRB1 using the current KRRCint and KRRCenc. The UE shall use the UP security activations that were used before tansition to the RRC Inactive. If the UE receives RRCReject message from the target gNB/ng-eNB in response to the UE <RRC Resume Request> message, the UE shall delete newly derived AS keys used for connection resumption attempt, including newly derived KNG-RAN*, newly derivedRRC integrity key, RRC encryption key and UP keys, and keep the current KRRCint and the KgNB/NH in its current AS context. Security is fully resumed on UE side after reception and processing of RRCResume message. The UE can receive data on DRB(s) after having received and processed RRC connection resume message. UL data on DRB(s) can be sent after RRCResumeComplete message has been successfully sent. After a successful transition from RRC_INACTIVE to RRC_CONNECTED the target gNB/ng-eNB shall perform Path Switch procedure with the AMF. The AMF shall verify the UE security capability as described in the clause 6.7.3.1, and the SMF shall veirfy the UE security policy as described in the clause 6.6.1.

The target gNB/ng-eNB may be the same as the source gNB/ng-eNB in the description in the previous subclause. If so, the single gNB/ng-eNB performs the roles of both the source and target gNB/ng-eNB.

The purpose of this procedure is to allow the UE to notify the network if it moves out of the configured RNA (RAN-based Notification Area) or if UE initiates a periodic RAN-based notification area update procedure. The UE and gNB store the AS security context in RRC_INACTIVE state and reactivate the AS security context when the UE initiates the RAN-based Notification Area Update (RNAU) procedure. The ng-eNB connected to 5GC shall also support the same key handling during mobility in RRC_INACTIVE.

When the UE decides to initiate the RANU procedure the UE may initiate the procedure with a new gNB/ng-eNB. In this case, the UE, the target gNB/ng-eNB and the source gNB/ng-eNB follow the detailed procedure as described in clause 6.8.2.1.3 with the following deviations: The target gNB/ng-eNB shall check if it supports the ciphering and integrity algorithms the UE used with the last source cell. If the target gNB/ng-eNB does not support the ciphering and integrity algorithms used in the last source cell or if the target gNB/ng-eNB prefers to use different algorithms than the source gNB/ng-eNB, then the target gNB/ng-eNB shall send an RRCSetup message on SRB0 to the UE in order to proceed with RRC connection establishment as if the UE was in RRC_IDLE (i.e., fallback procedure). If the target gNB/ng-eNB selects the ciphering and integrity protection algorithms which the UE used with the last source cell and the target gNB/ng-eNB decides to send the UE directly back to RRC_INACTIVE state without bringing the UE to RRC_CONNECTED state, the target gNB/ng-eNB shall perform a Path Switch procedure with the AMF to get a fresh {NCC, NH} pair before sending the RRCRelease message to the UE. After the target gNB/ng-eNB receives a fresh {NCC, NH} pair in the Path Switch Acknowledgement message from the AMF, the target gNB/ng-eNB shall set the value of NCC in the RRCRelease message to the NCC value of the received fresh {NCC, NH} pair. After the source gNB/ng-eNB (old gNB/ng-eNB) validates the ResumeMAC-I/shortResumeMAC-I received from the target gNB/ng-eNB (new gNB/ng-eNB) in the RETRIEVE UE CONTEXT REQUEST message, the old gNB/ng-eNB may decide not to relocate the UE context to the new gNB/ng-eNB. In this case, the old gNB/ng-eNB builds the RRCRelease message (MSG4) with a fresh I-RNTI, integrity protect it and encrypt it using the RRC keys that were derived from the new KgNB* similar to RRCResume message (MSG4) protection as specified in clause 6.8.2.1.3. Then, the old gNB/ng-eNB sends the integrity protected and encrypted RRCRelease message to the new gNB/ng-eNB in the RETRIEVE UE CONTEXT FAILURE message.

When the UE decides to initiate a periodic RNAU procedure, the target gNB/ng-eNB may be the same as the source gNB/ng-eNB. If so the single gNB/ng-eNB (same gNB/ng-eNB) performs the roles of both the source gNB/ng-eNB and the target gNB/ng-eNB.