6.8 Security handling in state transitions

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.8.1 Key handling at connection and registration state transitions

6.8.1.1 Key handling at transitions between RM-DEREGISTERED and RM-REGISTERED states

6.8.1.1.0 General

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

6.8.1.1.1 Transition from RM-REGISTERED to RM-DEREGISTERED

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.

NOTE: The present document only considers the states RM-DEREGISTERED and RM REGISTERED and transitions between these two states. Other documents define additional RM states (see, e.g. 5GMM states in TS 24.501 [35]).

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:

a. UE-initiated

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

ii. If the reason is not switch off then AMF and UE shall keep all the remaining security parameters.

b. AMF-initiated

i. Explicit: all the remaining security parameters shall be kept in the UE and AMF if the de-registration type is "re-registration required".

ii. Implicit: all the remaining security parameters shall be kept in the UE and AMF.

c. 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 [35].

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 K_NASint and K_NASenc, in the UE when the UE transitions to RM-DEREGISTERED state is done as follows:

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

b) 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 K_NASint and K_NASenc), 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.

c) If the USIM does not support RM parameters storage, then the ME shall store the full native 5G NAS security context (except for K_NASint and K_NASenc) 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 [35].

6.8.1.1.2 Transition from RM-DEREGISTERED to RM-REGISTERED

6.8.1.1.2.1 General

When starting the transition away from RM DEREGISTERED state with the intent to eventually transitioning to RM-REGISTERED state, if no current 5G NAS security context is available in the ME, the ME shall retrieve native 5G NAS security context stored on the USIM if the USIM supports RM parameters storage and if the stored native 5G NAS security context on the USIM is marked as valid. If the USIM does not support RM parameters storage the ME shall retrieve stored native 5G NAS security context from its non-volatile memory if the native 5G NAS security context is marked as valid. The ME shall derive the K_NASint and K_NASenc from the K_AMF after retrieving the stored 5G NAS security context; see Annex A on NAS key derivation. The retrieved native 5G NAS security context with the derived K_NASint and K_NASenc shall then become the current 5G NAS security context.

When the ME is transitioning away from RM DEREGISTERED state with the intent to eventually transitioning to RM-REGISTERED state, if the USIM supports RM parameters storage, the ME shall mark the stored 5G NAS security context on the USIM as invalid. If the USIM does not support RM parameters storage, the ME shall mark the stored 5G NAS security context in its non-volatile memory as invalid.

If the ME uses a 5G NAS security context to protect NAS messages, the distinct NAS COUNT values together with the NAS connection identifier associated with this access, are updated in the volatile memory of the ME. If the attempt to transition away from RM DEREGISTERED state with the intent to eventually transitioning to RM-REGISTERED state fails, the ME shall store the (possibly updated) 5G NAS security context including the distinct NAS COUNT values together with the NAS connection identifier associated with this access, on the USIM or non-volatile ME memory and mark it as valid.

When the UE transits from RM-DEREGISTERED to RM-REGISTERED/CM-CONNECTED, there are two cases to consider, either a full native 5G NAS security context exists, or it does not.

6.8.1.1.2.2 Full native 5G NAS security context available

The UE shall transmit a NAS Registration Request message. This message is integrity protected using the distinct NAS COUNT values and the NAS connection identifier associated with this access. For the case that the 5G NAS security context used by the UE is non-current in the AMF, the AMF shall delete any existing current 5G security context and make the used 5G security context the current 5G security contex. Furthermore, provided that the NAS Registration Request was with "PDU session(s) to be re-activated" and there is no NAS SMC procedure before the AS SMC the NAS COUNT of the Registration Request message shall be used to derive the K_gNB/K_eNB with the KDF as specified in Annex A.

As a result of the NAS Registration Request with "PDU session(s) to be re-activated", the gNB/ng-eNB shall send an AS SMC to the UE to activate AS security. The K_gNB/K_eNB used, is derived in the current 5G NAS security context.

When the UE receives the AS SMC without having received a NAS Security Mode Command after the Registration Request with "PDU session(s) to be re-activated", it shall use the uplink NAS COUNT of the Registration Request message that triggered the AS SMC to be sent as freshness parameter in the derivation of the initial K_gNB/K_eNB. From this initial K_gNB/K_eNB the RRC protection keys and the UP protection keys shall be derived as described in sub-clause 6.2.3.1.

The same procedure for generating initial K_gNB/K_eNB can be used regardless of the fact if the UE is connecting to the same AMF to which it was connected previously or to a different AMF. In case UE connects to a different AMF and this AMF selects different NAS algorithms, the NAS keys have to be re-derived in the AMF with the new algorithm IDs as input using the KDF as specified in Annex A.

In addition, there is a need for the AMF to send a NAS SMC to the UE to indicate the change of NAS algorithms and to take the re-derived NAS keys into use. The UE shall assure that the NAS keys used to verify the integrity of the NAS SMC are derived using the algorithm ID specified in the NAS SMC. The NAS SMC Command and NAS SMC Complete messages are protected with the new NAS keys.

If there is a NAS Security Mode Command after the Registration Request with "PDU session(s) to be re-activated" but before the AS SMC, the UE and AMF use the uplink NAS COUNT of the most recent NAS Security Mode Complete and the related KAMF as the parameter in the derivation of the K_gNB/K_eNB. From this K_gNB/K_eNB the RRC protection keys and the UP protection keys are derived as described in sub-clause 6.2.3.1.

6.8.1.1.2.3 Full native 5G NAS security context not available

If in the process described in clause 6.8.1.1.2.2, there is no full native 5G NAS security context available in the AMF (i.e. either the UE has sent an unprotected Registration Request message or the UE has protected the Registration Request message with a current native 5G security context which no longer is stored in the AMF) a primary authentication run is required. If there is a full native 5G NAS security context available in the AMF, then the AMF may (according to AMF policy) decide to run a new primary authentication and a NAS SMC procedure (which activates the new 5G NAS security context based on the K_AMF derived during the primary authentication run) after the Registration Request.

If the Registration Request was with "PDU session(s) to be re-activated", the NAS SMC procedure is executed before the corresponding AS SMC. The NAS (uplink and downlink) COUNTs are set to start values, and the start value of the uplink NAS COUNT shall be used as freshness parameter in the K_gNB/K_eNB derivation from the fresh K_AMF (after primary authentication) when UE receives AS SMC the K_gNB/K_eNB is derived from the current 5G NAS security context, i.e., the fresh K_AMF is used to derive the K_gNB/K_eNB. The KDF as specified in clause Annex A shall be used to derive the K_gNB/K_eNB.

NOTE: Using the start value for the uplink NAS COUNT in this case cannot lead to the same combination of K_AMF and NAS COUNT being used twice. This is guaranteed by the fact that the first integrity protected NAS message the UE sends to the AMF after primary authentication is the NAS SMC complete message.

The NAS SMC complete message shall include the start value of the uplink NAS COUNT that is used as freshness parameter in the K_gNB/K_eNB derivation and the K_AMF is fresh. After a primary authentication, a NAS SMC needs to be sent from the AMF to the UE in order to take the new NAS keys into use. Both NAS SMC and NAS SMC Complete messages are protected with the new NAS keys.

6.8.1.1.2.4 UE registration over a second access type to the same AMF

It is assumed in this clause that the UE is already registered over a first access type (say access A). Clauses 6.8.1.1.2.1 and 6.8.1.1.2.2 applies as well when the UE attempts to register over a new access type (access B) to the same AMF with the following addition/exception:

Whenever the UE registers over a second access type (access B) to the same AMF, with the intention to transitioning from RM-DEREGISTERED to RM-REGISTERED state, then a full native 5G NAS security context is already available in the UE and the AMF. In this case, the UE shall directly take into use the available full 5G NAS security context and use it to protect the Registration Request over the second access using the distinct pair of NAS COUNTs for this second access type (access B).

The AMF may decide to run a new primary authentication as part of the Registration procedure on this second access (access B). If a new primary authentication is run, then the new derived partial 5G NAS security context needs to be taken into use on this second access (access B) with a NAS SMC using the distinct pair of NAS COUNTs for this second access. As the UE is already registered on the first access (access A), then the AMF needs to run a NAS SMC procedure on the first access in order to take the partial 5G NAS security context into use as described in clause 6.4.2.2.

If there is a need for the AMF to take a new partial 5G NAS security context into use, derived from primary authentication executed on the first access (access A), then the AMF needs to send a NAS SMC to the UE on the second access (access B) in order to take the new partial 5G NAS security context into use as described in clause 6.4.2.2.

6.8.1.2 Key handling at transitions between CM-IDLE and CM-CONNECTED states

6.8.1.2.0 General

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 sub-clauses applies to both 3GPP access and non-3GPP access when not explicitly stated.

6.8.1.2.1 Transition from CM-IDLE to CM-CONNECTED

The UE sends an initial NAS message to initiate transition from CM-IDLE to CM-CONNECTED state (see TS 24.501 [35].

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 sub-clause 6.2.3.1 while K_AMF 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.

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

6.8.1.2.2 Establishment of keys for cryptographically protected radio bearers in 3GPP access

This sub-clause 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 K_gNB/K_eNB as specified in Annex A using the uplink NAS COUNT (see TS 24.501 [35]) corresponding to the NAS message that initiated transition from CM-IDLE to CM-CONNECTED state and the K_AMF of the current 5G NAS security context.

The AMF shall communicate the K_gNB/K_eNB to the serving gNB/ng-eNB in the NGAP procedure INITIAL CONTEXT SETUP. The UE shall derive the K_gNB/K_eNB from the K_AMF 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 K_gNB/K_eNB. The KDF as specified in Annex A shall be used for the K_gNB/K_eNB derivation using the K_AMF of the current 5G NAS security context. From the K_gNB/K_eNB the RRC protection keys and the UP protection keys are derived by the UE and the gNB/ng-eNB as described in sub-clause 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 K_AMF 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 K_gNB/K_eNB derivation from fresh K_AMF of the current 5G NAS security context when executing an AS SMC. The KDF as specified in Annex A shall be used for the K_gNB/K_eNB 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 5.31.4 of TS 23.501 [2]) 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 K_eNB 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 K_eNB.

6.8.1.2.3 Establishment of keys for cryptographically protected traffic in non-3GPP access

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 [25].

6.8.1.2.4 Transition from CM-CONNECTED to CM-IDLE

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.

6.8.1.3 Key handling for the Registration procedure when registered in NG-RAN

NOTE: This clause applies to both 3GPP access and non-3GPP access.

Before the UE can initiate the Registration procedure, the UE needs to transition to CM-CONNECTED state. The UE shall use the current 5G security context to protect the Registration Request and include the corresponding 5G-GUTI and ngKSI value. The Registration Request shall be integrity-protected, but not confidentiality-protected. UE shall use the current 5G security context algorithms to protect the Registration Request message. For the case that this security context is non-current in the AMF, the AMF shall delete any existing current 5G security context and make the used 5G NAS security context the current 5G security context.

If "PDU session(s) to be re-activated" is included in the Registration request message or if the AMF chooses to establish radio bearers when there is pending downlink UP data or pending downlink signalling, radio bearers will be established as part of the Registration procedure and a K_gNB/K_eNB will be derived. If there was no subsequent NAS SMC, the value of the uplink NAS COUNT, associated with the 3GPP access over which the Registration request message was sent from the UE to the AMF, is used as freshness parameter in the K_gNB/K_eNB derivation using the KDF as specified in clause Annex A.9.

In the case a primary authentication is run successfully, the uplink and downlink NAS COUNT shall be set to the start values (i.e. zero).

In the case source and target AMF use different NAS algorithms, the target AMF re-derives the NAS keys from K_AMF with the new algorithm identities as input and provides the new algorithm identifiers within a NAS SMC. The UE shall assure that the NAS keys used to verify the integrity of the NAS SMC are derived using the algorithm identity specified in the NAS SMC.

If there is a NAS Security Mode Command after the Registration Request over 3GPP access, the UE and AMF shall use the value of the uplink NAS COUNT associated with the 3GPP access of the most recent NAS Security Mode Complete and the related K_AMF as the parameter in the derivation of the K_gNB/K_eNB. From this K_gNB/K_eNB the RRC protection keys and the UP protection keys are derived as described in sub-clause 6.2.3.1.

In the case of Registration over non-3GPP access, the UE and AMF shall use the uplink NAS COUNT associated with the non-3GPP access of the most recent NAS Security Mode Complete and the related K_AMF as the parameter in the derivation of the K_N3IWF. IPsec SA is established between the UE and N3IWF using the K_N3IWFas described in sub-clause 7.2.1 of this document.

6.8.2 Security handling at RRC state transitions

6.8.2.1 Security handling at transitions between RRC_INACTIVE and RRC_CONNECTED states

6.8.2.1.1 General

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 sub-clauses. The ng-eNB connected to 5GC shall also support the same security handling at RRC state transitions.

6.8.2.1.2 State transition from RRC_CONNECTED to RRC_INACTIVE

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 K_gNB in the RRCRelease with suspendConfig message. The NCC is used for AS security.

The gNB/ng-eNB shall delete the current AS keys K_RRCenc, K_UPenc (if available), and K_UPint (if available) after sending the RRCRelease with suspendConfig message to the UE, but shall keep the current AS key K_RRCint. 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 K_gNB. If the sent NCC value is equal to the NCC value associated with the current K_gNB, the gNB/ng-eNB shall keep the current AS key K_gNBand 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 K_RRCenc, K_UPenc (if available), and K_UPint (if available), but keep the current AS key K_RRCint key. If the stored NCC value is different from the NCC value associated with the current K_gNB, the UE shall delete the current AS key K_gNB. If the stored NCC is equal to the NCC value associated with the current K_gNB, the UE shall keep the current AS key K_gNB. 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.

6.8.2.1.3 State transition from RRC_INACTIVE to RRC_CONNECTED to a new gNB/ng-eNB

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 K_RRCintwith the following inputs:

– KEY : it shall be set to current K_RRCint;

– 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 [22] for gNB and in TS 36.331 [69] 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 K_NG-RAN* using the target PCI, target ARFCN-DL/EARFCN-DL and the K_gNB/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 K_RRCint, K_RRCenc, K_UPenc (optionally), and K_UPint (optionally) from the newly derived K_NG-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 K_RRCint 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 K_NG-RAN* using the target cell PCI, target ARFCN-DL/EARFCN-DL and the K_gNB/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 K_NG-RAN*, the NCC associated to the K_NG-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 K_NG-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 K_RRCenc that was derived based on the newly derived K_NG-RAN*. The UE shall also verify the <RRC Connection Resume> message by verifying the PDCP MAC-I using the K_RRCint that was derived from the newly derived K_NG-RAN* If verification of the RRCResume message is successful, the UE shall delete the current K_RRCint key and the UE shall save the K_RRCint, K_RRCenc, K_UPenc (optionally), and K_UPint (optionally) from the newly derived K_NG-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 K_RRCint and K_RRCenc. 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 K_NG-RAN*, newly derivedRRC integrity key, RRC encryption key and UP keys, and keep the current K_RRCint and the K_gNB/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.

6.8.2.1.4 State transition from RRC_INACTIVE to RRC_CONNECTED to the same gNB/ng-eNB

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.

6.8.2.2 Key handling during mobility in RRC_INACTIVE state

6.8.2.2.1 General

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.

6.8.2.2.2 RAN-based notification area update to a new gNB/ng-eNB

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

6.8.2.2.3 RAN-based notification area update to the same gNB/ng-eNB

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.