Content for  TS 33.501  Word version:  16.3.0

6.9.1  General

6.9.2  Key handling in handover

6.9.2.1  General

6.9.2.1.1  Access stratum

The general principle of key handling for K NG-RAN*/NH at handovers is depicted in Figure 6.9.2.1.1-1.

[not reproduced yet]

Figure 6.9.2.1.1-1: Model for the handover key chaining

The following is an outline of the key handling model to clarify the intended structure of the key derivations. The detailed specification is provided in subclauses 6.9.2.2 and 6.9.2.3.

Whenever an initial AS security context needs to be established between UE and gNB/ng-eNB, AMF and the UE shall derive a K gNB and a Next Hop parameter (NH). The K gNB and the NH are derived from the K AMF. A NH Chaining Counter (NCC) is associated with each K gNB and NH parameter. Every K gNB is associated with the NCC corresponding to the NH value from which it was derived. At initial setup, the K gNB is derived directly from K AMF, and is then considered to be associated with a virtual NH parameter with NCC value equal to zero. At initial setup, the derived NH value is associated with the NCC value one.

Whether the AMF sends the K gNB key or the {NH, NCC} pair to the serving gNB/ng-eNB is described in detail in subclauses 6.9.2.2 and 6.9.2.3. The AMF shall not send the NH value to gNB/ng-eNB at the initial connection setup. The gNB/ng-eNB shall initialize the NCC value to zero after receiving NGAP Initial Context Setup Request message.

The UE and the gNB/ng-eNB use the K gNB to secure the communication between each other. On handovers and at transitions from RRC_INACTIVE to RRC_CONNECTED states (defined in clause 6.8.2.1), the basis for the K gNB that will be used between the UE and the target gNB/ng-eNB, called K NG-RAN*, is derived from either the currently active K gNB or from the NH parameter. If K NG-RAN* is derived from the currently active K gNB this is referred to as a horizontal key derivation (see Figure 6.9.2.1.1-1) and if the K NG-RAN* is derived from the NH parameter the derivation is referred to as a vertical key derivation (see Figure 6.9.2.1.1-1).

As NH parameters are only computable by the UE and the AMF, it is arranged so that NH parameters are provided to gNB/ng-eNBs from the AMF in such a way that forward security can be achieved.

On handovers with vertical key derivation the NH is further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the K gNB in the target gNB/ng-eNB. On handovers with horizontal key derivation the currently active K gNB is further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the K gNB in the target gNB/ng-eNB.

6.9.2.1.2  Non access stratum  Word‑p. 80

During mobility, NAS aspects that need to be considered are the possible K AMF change, the possible NAS algorithm change at AMF change, and the possible presence of a parallel NAS connection. There is the possibility that the source AMF and the target AMF do not support the same set of NAS algorithms or have different priorities regarding the use of NAS algorithms. In this case, the target AMF re-derives the NAS keys from the existing K AMF (if unchanged) or derives the NAS keys from the new K AMF (if changed) using the NAS algorithm identities and NAS algorithm types as input to the NAS key derivation functions (see Annex A.8). When the K AMF has not changed, all inputs, in particular the K AMF, will be the same in the re-derivation except for the NAS algorithm identity. When the K AMF has changed, new NAS keys are derived irrespective of change in NAS algorithms.

In case the K AMF has changed or the target AMF decides to use NAS algorithms different from the ones used by the source AMF, the target AMF shall provide needed parameters to the UE as defined in Clause 6.9.2.3.3 for N2-Handover (i.e., using NAS Container) and Clause 6.9.3 for mobility registration update (i.e., using NAS SMC).

6.9.2.2  Key derivations for context modification procedure

As outlined in clause 6.9.2.1, whenever a fresh K gNB is calculated from the K AMF, the AMF shall transfer the K gNB to the serving ng-eNB/gNB in a message modifying the security context in the ng-eNB/gNB. The AMF and the UE shall compute the fresh K gNB as defined in Annex A.9 according to the rules in clause 6.9.6.4. An NCC value 0 is associated with the fresh K gNB. From the fresh K gNB, the ng-eNB/gNB and the UE shall compute the K NG-RAN* as described in Annex A.11 and A.12 and then use the computed K NG-RAN* as the K gNB/K eNB as described in clause 6.9.4.4.

6.9.2.3  Key derivations during handover

6.9.2.3.1  Intra-gNB-CU handover and intra-ng-eNB handover

The gNB shall have a policy deciding at which intra-gNB -CU handovers the K gNB can be retained and at which a new K gNB needs to be derived. At an intra-gNB-CU handover, the gNB shall indicate to the UE whether to change or retain the current K gNB in the HO Command message. Retaining the current K gNB shall only be done during intra-gNB-CU handover.

If the current K gNB is to be changed, the gNB/ng-eNB and the UE shall derive a K NG-RAN* as in Annex A.11/A.12 using target PCI, its frequency ARFCN-DL/EARFCN-DL, and either NH or the current K gNB depending on the following criteria: the gNB shall use the NH for deriving K NG-RAN* if an unused {NH, NCC} pair is available in the gNB (this is referred to as a vertical key derivation), otherwise if no unused {NH, NCC} pair is available in the gNB, the gNB shall derive K NG-RAN* from the current K gNB (this is referred to as a horizontal key derivation). The gNB shall send the NCC used for the K NG-RAN*derivation to UE in HO Command message. The gNB/ng-eNB and the UE shall use the K NG-RAN* as the K gNB, after handover.

If the current K gNB is to be retained, the gNB and the UE shall continue using the current K gNB, after handover.

6.9.2.3.2  Xn-handover  Word‑p. 81

In Xn handovers the source gNB/ng-eNB shall perform a vertical key derivation in case it has an unused {NH, NCC} pair. The source gNB/ng-eNB shall first compute K NG-RAN* from target PCI, its frequency ARFCN-DL/EARFCN-DL, and either from currently active K gNB in case of horizontal key derivation or from the NH in case of vertical key derivation as described in Annex A.11/A.12.

Next, the source gNB/ng-eNB shall forward the { K NG-RAN*, NCC} pair to the target gNB/ng-eNB. The target gNB/ng-eNB shall use the received K NG-RAN* directly as K gNB to be used with the UE. The target gNB/ng-eNB shall associate the NCC value received from source gNB/ng-eNB with the K gNB. The target gNB/ng-eNB shall include the received NCC into the prepared HO Command message, which is sent back to the source gNB/ng-eNB in a transparent container and forwarded to the UE by source gNB/ng-eNB.

When the target gNB/ng-eNB has completed the handover signalling with the UE, it shall send a NGAP PATH SWITCH REQUEST message to the AMF. Upon reception of the NGAP PATH SWITCH REQUEST, the AMF shall increase its locally kept NCC value by one and compute a new fresh NH from its stored data using the function defined in Annex A.10. The AMF shall use the K AMF from the currently active 5G NAS security context for the computation of the new fresh NH. The AMF shall then send the newly computed {NH, NCC} pair to the target gNB/ng-eNB in the NGAP PATH SWITCH REQUEST ACKNOWLEDGE message. The target gNB/ng-eNB shall store the received {NH, NCC} pair for further handovers and remove other existing unused stored {NH, NCC} pairs if any.

If the AMF had activated a new 5G NAS security context with a new K AMF, different from the 5G NAS security context on which the currently active 5G AS security context is based, but has not yet successfully performed a UE Context Modification procedure, the sent NGAP PATH SWITCH REQUEST ACKNOWLEDGE message shall in addition contain a NSCI (New Security Context Indicator). The AMF shall in this case derive a new initial K gNB from the new K AMF and the uplink NAS COUNT in the most recent NAS Security Mode Complete message as specified in Annex A.9. The AMF shall associate the derived new initial K gNB with a new NCC value equal to zero. Then, the AMF shall use {the derived new initial K gNB, the new NCC value initialized to zero} pair as the newly computed {NH, NCC} pair to be sent in the NGAP PATH SWITCH REQUEST ACKNOWLEDGE message. The gNB/ng-eNB shall in this case set the value of keySetChangeIndicator field to true in further handovers. The gNB/ng-eNB should in this case perform an intra-gNB-CU/intra-ng-eNB handover immediately and send appropriate response to the AMF.

6.9.2.3.3  N2-Handover  Word‑p. 82

Upon reception of the NGAP HANDOVER REQUIRED message, if the source AMF does not change the active K AMF (meaning no horizontal K AMF derivation) and if AS key re-keying is not required, the source AMF shall increment its locally kept NCC value by one and compute a fresh NH from its stored data using the function defined in Annex A.10. The source AMF shall use the K AMF from the currently active 5GS NAS security context for the computation of the fresh NH. The source AMF shall send the fresh {NH, NCC} pair to the target AMF in the Namf_Communication_CreateUEContext Request message. The Namf_Communication_CreateUEContext Request message shall in addition contain the K AMF that was used to compute the fresh {NH, NCC} pair and its corresponding ngKSI and corresponding uplink and downlink NAS COUNTs.

If the source AMF had activated a new 5G NAS security context with a new K AMF, different from the 5G NAS security context on which the currently active 5G AS security context is based, but has not yet performed a UE Context Modification procedure, the Namf_Communication_CreateUEContext Request message shall in addition contain an indication that the K AMF sent by source AMF to target AMF is not in sync with the current K gNB used between the UE and the source gNB (i.e., keyAmfChangeInd) which means that AS key re-keying is required at the UE. Further, the source AMF shall derive a new K gNB associated with NCC=0 using the new K AMF and the uplink NAS COUNT from the last successful NAS SMC procedure with the UE and provide the {NH= newly derived K gNB, NCC=0} pair to the target AMF in the Namf_Communication_CreateUEContext Request message.

The source AMF uses its local policy to determine whether to perform horizontal K AMF derivation on currently active K AMF. If horizontal K AMF derivation is performed, the Namf_Communication_CreateUEContext Request shall contain an indication (i.e., keyAmfHDerivationInd ) that the new K AMF has been calculated, an indication (i.e., keyAmfChangeInd) that AS key re-keying is required at the UE, and the downlink NAS COUNT used in the horizontal derivation of the sent K AMF. The ngKSI for the newly derived K AMF key has the same value and the same type as the ngKSI of the current K AMF. Further, the source AMF shall derive a new K gNB associated with NCC=0 using the newly derived K AMF and the uplink NAS COUNT value of 232-1 as defined in Annex A.9. The source AMF shall include the{NH=newly derived K gNB, NCC=0} pair and the ngKSI for the newly derived K AMF key in the Namf_Communication_CreateUEContext Request as well.

The source AMF shall always increment the downlink NAS COUNT by one after sending the Namf_Communication_CreateUEContext Request message to the target AMF.

Unlike the S10 FORWARD RELOCATION REQUEST message in EPS, the Namf_Communication_CreateUEContext Request message in 5G shall not contain data and meta-data related to old 5G security context.

If the target AMF receives the indication of horizontal K AMF derivation (i.e., keyAmfHDerivationInd), it shall derive the NAS keys from the received K AMF as specified in clause A.8 and set the NAS COUNTs to zero. The target AMF shall create a NASC (NAS Container) containing the K_AMF_change_flag, the received downlink NAS COUNT, ngKSI, selected NAS security algorithms, and NAS MAC. The K_AMF_change_flag is set to one when the target AMF receives keyAmfHDerivationInd_. Otherwise, the K_AMF_change_flag is set to zero. If the target AMF does not receive keyAmfHDerivationInd but wants to change the NAS algorithms, it shall create a NASC using the selected NAS security algorithms in the same manner as the case for the horizontal K AMF derivation. However, the target AMF shall not set the NAS COUNTs to zero.

The target AMF shall calculate a 32-bit NAS MAC over the parameters included in the NASC using the K NASint key. The input parameters to the NAS 128-bit integrity algorithms as described in Annex D.3 shall be set as follows when calculating NAS MAC.

The calculation of NAS MAC shall be the 32-bit output of the selected NIA and shall use the following inputs:

KEY : it shall be set to the corresponding K NASint;

COUNT : it shall be set to 232-1;

MESSAGE : it shall be set to the content of NAS Container as defined in TS 24.501;

DIRECTION : its bit shall be set to 1; and

BEARER : it shall be set to the value of the NAS connection identifier for 3GPP access.

The use of the 232-1 as the value of the COUNT for the purpose of NAS MAC calculation/verification does not actually set the NAS COUNT to 232-1. The reason for choosing such a value not in the normal NAS COUNT range, i.e., [0, 224 1] is to avoid any possibility that the value may be reused for normal NAS messages.

Replay protection is achieved by the UE checking if the downlink NAS COUNT included in the NAS Container is replayed or not. The UE shall not accept the same downlink NAS COUNT value twice before a newly derived K AMF is taken into use and the corresponding downlink NAS COUNT is set to zero. The target AMF shall increment the downlink NAS COUNT by one after creating a NASC.

The NASC is included in the NGAP HANDOVER REQUEST message to the target ng-eNB/gNB. The purpose of this NASC could be compared to a NAS SMC message. If the target AMF receives the keyAmfChangeInd, it shall further send the received {NCC, NH} pair and the New Security Context Indicator (NSCI) to the target ng-eNB/gNB within the NGAP HANDOVER REQUEST message. The target AMF shall further set the NCC to one and shall further compute a NH as specified in Annex A.10. The target AMF shall further store the {NCC=1, NH} pair.

If the target AMF does not receive the keyAmfChangeInd, it shall store locally the K AMF and {NH, NCC} pair received from the source AMF and then send the received {NH, NCC} pair to the target ng-eNB/gNB within the NGAP HANDOVER REQUEST message.

Upon receipt of the NGAP HANDOVER REQUEST message from the target AMF, the target ng-eNB/gNB shall compute the K NG-RAN* to be used with the UE by performing the key derivation defined in Annex A.11 and A.12 with the {NH, NCC} pair received in the NGAP HANDOVER REQUEST message and the target PCI and its frequency ARFCN-DL/EARFCN-DL. The gNB uses the K NG-RAN* corresponding to the selected cell as K gNB. The ng-eNB uses the K NG-RAN* corresponding to the selected cell as K eNB. The target ng-eNB/gNB shall associate the NCC value received from AMF with the K gNB/K eNB. The target ng-eNB/gNB shall include the NCC value from the received {NH, NCC} pair, and the NASC if such was also received, into the HO Command message to the UE and remove any existing unused stored {NH, NCC} pairs. If the target ng-eNB/gNB had received the NSCI, it shall set the keySetChangeIndicator field in the HO Command message to true.

6.9.2.3.4  UE handling  Word‑p. 83

The UE behaviour is the same regardless if the handover is intra-gNB-CU, intra ng-eNB, Xn, or N2 with the exception that during intra-gNB-CU handover, the UE may retain the same key based on an indication from the gNB. The UE behaviour is also same in case of conditional handover, as specified in TS 38.300, i.e., the UE shall use the parameters of the selected target cell in K NG-RAN* derivations.

If the UE also receives a NASC (NAS Container) in the HO Command message, the UE shall update its NAS security context as follows:

The UE shall verify the freshness of the downlink NAS COUNT in the NASC.

If the NASC indicates a new K AMF has been calculated (i.e., K_AMF_change_flag is one),

The UE shall compute the horizontally derived K AMF using the K AMF from the current 5G NAS security context identified by the ngKSI included in the NASC and the downlink NAS COUNT in the NASC, as specified in Annex A.13.

The UE shall assign the ngKSI included in the NASC to the ngKSI of the new derived K AMF. The UE shall further configure NAS security based on the horizontally derived K AMF and the selected NAS security algorithms in the NASC.

The UE shall further verify the NAS MAC in the NASC as described in Clause 6.9.2.3.3 and if the verification is successful, the UE shall further set the NAS COUNTs to zero.

If K AMF change is not indicated,

If the verification is successful, the UE shall configure the NAS security based on the parameters included in the NASC but shall not set the NAS COUNTs to zero.

The UE shall verify the NAS MAC in the NASC.

The UE shall further set the downlink NAS COUNT value of the currently active NAS security context to the received downlink NAS COUNT value in the NASC.

If verification of the NASC fails, the UE shall abort the handover procedure. Furthermore, the UE shall discard the new NAS security context if it was derived and continue to use the existing NAS and AS security contexts.

If keySetChangeIndicator in the HO command is true

If the HO Command message contained a NASC parameter with the K_AMF_change_flag set to one:

The UE shall use the horizontally derived K AMF and the NAS COUNT value of 232-1 in the derivation of the temporary K gNB. The UE shall further process this temporary key as described in subclause 6.9.4.4.

Else:

The UE handling related to key derivation shall be done as defined in clause 6.9.4.4.

Else

If the NCC value the UE received in the HO Command message from target ng-eNB/gNB via source ng-eNB/gNB is equal to the NCC value associated with the currently active K gNB/K eNB, the UE shall derive the K NG-RAN* from the currently active K gNB/K eNB and the target PCI and its frequency ARFCN-DL/EARFCN-DL using the function defined in Annex A.11 and A.12.

If the UE received an NCC value that was different from the NCC associated with the currently active K gNB/K eNB, the UE shall first synchronize the locally kept NH parameter by computing the function defined in Annex A.10 iteratively (and increasing the NCC value until it matches the NCC value received from the source ng-eNB/gNB via the HO command message. When the NCC values match, the UE shall compute the K NG-RAN* from the synchronized NH parameter and the target PCI and its frequency ARFCN-DL/EARFCN-DL using the function defined in Annex A.11 and A.12.

The UE shall use the K NG-RAN* as the K gNB when communicating with the target gNB and as the K eNB when communicating with the target ng-eNB.

6.9.3  Key handling in mobility registration update  Word‑p. 84

The procedure shall be invoked by the target AMF after the receiving of a Registration Request message of type mobility registration update from the UE wherein the UE and the source AMF are identified by means of a temporary identifier 5G-GUTI.

The protocol steps for the source AMF and target AMF performing context transfer are as follows:

a) The target AMF sends a message to the source AMF, this message contains 5G-GUTI and the received Registration Request message.

b) The source AMF searches the data of the UE in the database and checks the integrity protection on the Registration Request message.

i) If the UE is found and the integrity check succeeds, when the source AMF does not change K AMF according to its local policy, the source AMF shall send a response back that:

shall include the SUPI, and

may include any current 5G security context it holds.

ii) If the UE is found and the integrity check succeeds, when the source AMF changes K AMF according to its local policy, the source AMF shall send a response back that:

shall include the SUPI,

keyAmfHDerivationInd, and

may include a new 5G security context it derives from the current one it holds.

The source AMF subsequently deletes the 5G security context which it holds.

If the UE cannot be identified or the integrity check fails, then the source AMF shall send a response indicating that the temporary identifier 5G-GUTI cannot be retrieved.

c) If the target AMF receives a response with a SUPI, it creates an entry and stores the 5G security context that may have beenreceived .

If the target AMF receives a response indicating that the UE could not be identified, it shall initiate the subscription identification procedure described in clause 6.12.4 of the present document.

K SEAF shall not be forwarded to another AMF set.

At mobility registration update, the source AMF shall use local policy to determine whether to perform horizontal K AMF derivation. If the source AMF determines not to perform horizontal K AMF derivation, the source AMF shall transfer current security context to the target AMF. If the source AMF determines to perform horizontal K AMF derivation, the source AMF shall derive a new key K AMF from the currently active K AMF and the uplink NAS COUNT value in the received Registration Request message. The ngKSI for the newly derived K AMF key is defined such as the value field and the type field are taken from the ngKSI of the current K AMF. The source AMF shall transfer the new K AMF, the new ngKSI, the UE security capability, the keyAmfHDerivationInd to the target AMF. The key derivation of the new K AMF is specified in Annex A.13. If the source AMF has derived a new key K AMF, the source AMF shall not transfer the old K AMF to the target AMF and the source AMF shall in this case also delete any stored non-current 5G security context, and not transfer any non-current 5G security context to the target AMF.

When the target AMF receives the new K AMF together with the keyAmfHDerivationInd, then the target AMF shall decide whether to use the K AMF directly according to its local policy after receiving the response from the source AMF.

If the target AMF, according to its local policy, decides to not use the K AMF received from the source AMF, it can perform a re-authentication procedure to the UE to establish a new NAS security context.

If the target AMF decides to use the key K AMF received from source AMF (i.e., no re-authentication), it shall send the K_AMF_change_flag set to 1 to the UE in the NAS SMC including replayed UE security capabilities, the selected NAS algorithms and the ngKSI for identifying the new K AMF from which the UE shall derive a new K AMF to establish a new NAS security context between the UE and target AMF.

The target AMF shall reset the NAS COUNTs to zero and derive new NAS keys (K NASint and K NASenc) from the new K AMF using the selected NAS algorithm identifiers as input. The target AMF shall integrity protect the NAS Security Mode Command message with the new K NASint key.

If the UE receives the K_AMF_change_flag set to 1 in the NAS Security Mode Command message, then the UE shall derive a new key K AMF from the current active K AMF identified by the received ngKSI in the NAS Security Mode Command message using the uplink NAS COUNT valuethat was sent in the Registration Request message. The UE shall assign the received ngKSI in the NAS Security Mode Command message to the ngKSI of the new derived K AMF. The UE shall derive new NAS keys (K NASint and K NASenc) from the new K AMF and integrity check the NAS Security Mode Command message using the new K NASint key.

The UE shall then derive a new initial K gNB from the new K AMF as specified in Annex A.9.

The UE shall associate the derived new initial K gNB with a new NCC value equal to zero and reset the NAS COUNTs to zero.

After the ongoing mobility registration procedure is successfully completed, the ME shall replace the currently stored K AMF and ngKSI values on both USIM and ME with the new K AMF and the associated ngKSI.

6.9.4  Key-change-on-the-fly  Word‑p. 86

6.9.4.1  General

Key change on-the-fly consists of key refresh or key re-keying.

Key refresh shall be possible for K gNB, KRRC-enc, KRRC-int, KUP-enc, and KUP-int (if available ) and shall be initiated by the gNB/ng-eNB when a PDCP COUNTs are about to be re-used with the same Radio Bearer identity and with the same K gNB. The procedure is described in clause 6.9.4.5.

Key re-keying shall be possible for the K gNB, KRRC-enc, KRRC-int, KUP-enc, and KUP-int (if available). This re-keying shall be initiated by the AMF when a 5G AS security context different from the currently active one shall be activated. The procedures for doing this are described in clause 6.9.4.4.

AS Key change on-the-fly is accomplished using a procedure based on intra-cell handover. The following AS key changes on-the-fly shall be possible: local K gNB refresh (performed when PDCP COUNTs are about to wrap around), K gNB re-keying performed after an AKA run, activation of a native context after handover from E-UTRAN.

Editor's note: Following NAS key related text are adapted from TS 33.401 and kept here for completeness and to not miss them out. It is FFS whether they need updating according to the agreements in SA3 and whether to move them to Clause 6.5.

Key re-keying shall be possible for KNAS-enc and KNAS-int. Re-keying of KNAS-enc and KNAS-int shall be initiated by the AMF when a 5G NAS security context different from the currently active one shall be activated. The procedures for doing this are described in clause 6.9.4.2.

Re-keying of the entire 5G key hierarchy including K AMF shall be achieved by first re-keying K AMF, then KNAS-enc and KNAS-int, followed by re-keying of the K gNB and derived keys. For NAS key change on-the-fly, activation of NAS keys is accomplished by a NAS SMC procedure.

6.9.4.2  NAS key re-keying

Editor's note: It is FFS whether this clause need updating according to the agreements in SA3 related to NAS keys (e.g. number of NAS keys, number of NAS SMCs, horizontal derivation of K AMF, etc.).

After a primary authentication has taken place, new NAS keys from a new K AMF shall be derived, according to Annex A.8.

To re-activate a non-current full native 5G security context after handover from E-UTRAN the UE and the AMF take the NAS keys into use by running a NAS SMC procedure according to clause 6.7.2.

AMF shall activate fresh NAS keys from a primary authentication run or activate native security context, which has a sufficiently low NAS COUNT values, before the NAS uplink or downlink COUNT wraps around with the current security context.

6.9.4.3  NAS key refresh

Editor's Note: This clause is meant to contain content about K AMF refresh. Scenarios for K AMF refresh are FFS.

If the AMF determines that NAS key refresh is required due to e.g. uplink or downlink NAS counter in the current security context is about to wrap around or based on a local operator policy to refresh the NAS keys after a certain time, the AMF may trigger a primary authentication run or may derive a new K AMF key using horizontal K AMF derivation upon the reception of an initial NAS message, e.g. a Registration Request or a Service Request using the uplink NAS COUNT value in the initial NAS message as described in clause 6.9.3 for mobility update registration. The AMF resets the corresponding uplink and downlink NAS counters and derive new NAS keys from the new K AMF key and the algorithms in use. The AMF activates the new K AMF key by running a NAS SMC with UE according to clause 6.7.2. When the new K AMF key is horizontally derived, the UE shall use the uplink NAS COUNT value that was sent in the initial NAS message to derive the same K AMF key as the AMF, reset the corresponding uplink and downlink NAS counters and then derive new NAS keys from the K AMF and the algorithms in use.

In this case, if AS security is also established between the UE and gNB/ng-eNB, then the AMF and the UE shall derive a new initial K gNB from the new K AMF as specified in Annex A.9. Further, the AMF and the UE shall associate the derived new initial K gNB with a new NCC value equal to zero. Further, the derived new initial K gNB/K eNB is sent by the AMF to the gNB/ng-eNB triggering the gNB/ng-eNB to perform the AS key re-keying as described in clause 6.9.4.4.

6.9.4.4  AS key re-keying  Word‑p. 87

The K gNB/K eNB re-keying procedure is initiated by the AMF. It may be used under the following conditions:

after a successful AKA run with the UE as part of activating a partial native 5G security context; or

as part of synchronizing the NAS and the AS security contexts as a part of handover procedure, if a handover is occuring; or

as part of re-activating a non-current full native 5G security context after handover from E-UTRAN according to clause 8.4; or

to create a new K gNB from the current K AMF.

In order to be able to re-key the K gNB, the AMF requires a fresh uplink NAS COUNT from a successful NAS SMC procedure with the UE. In the case of creating a new K gNB from the current K AMF a NAS SMC procedure shall be run first to provide this fresh uplink NAS COUNT. This NAS SMC procedure does not have to change other parameters in the current EPS NAS security context. The AMF derives the new K gNB using the key derivation function as specified in Annex A.9 using the K AMF and the uplink NAS COUNT used in the most recent NAS Security Mode Complete message. The derived new K gNB is sent to the gNB/ng-eNB in an NGAP UE CONTEXT MODIFICATION REQUEST message triggering the gNB/ng-eNB to perform the AS key re-keying. The gNB/ng-eNB runs the key change on-the-fly procedure with the UE. During this procedure the gNB/ng-eNB shall indicate to the UE that a key change on-the-fly is taking place. The procedure used is based on an intra-cell handover, and hence the same K gNB derivation steps shall be taken as in a normal handover procedure. The gNB/ng-eNB shall indicate to the UE to change the current K gNB in intra-cell handover during this procedure. Network-side handling of AS key re-keying that occur as a part of Xn and N2 handovers are described is defined in clauses 6.9.2.3.2 and 6.9.2.3.3 of the present document.

When the UE receives an indication that the procedure is a key change on-the-fly procedure, the UE shall derive a temporary K gNB by applying the key derivation function as specified in Annex A.9 using the K AMF from the current 5G NAS security context and the uplink NAS COUNT in the most recent NAS Security Mode Complete message. UE-side handling of AS key re-keying that occur as a part of Xn and N2 handovers is described in clause 6.9.2.3.4 of the present document.

From this temporary K gNB the UE shall derive the K NG-RAN* as normal (see Annex A.11/A.12). The gNB/ng-eNB shall take the K gNB it received from the AMF, which is equal to the temporary K gNB, as basis for its K NG-RAN* derivations. From this step onwards, the key derivations continue as in a normal handover.

If the AS level re-keying fails, then the AMF shall complete another NAS security mode procedure before initiating a new AS level re-keying. This ensures that a fresh K gNB is used.

The NH parameter shall be handled according to the following rules:

The UE, AMF, and gNB/ng-eNB shall delete any old NH upon completion of the context modification.

The UE and AMF shall use the K AMF from the currently active 5G NAS security context for the computation of the fresh NH. The computation of NH parameter value sent in the Namf_Communication_CreateUEContext Request, NGAP HANDOVER REQUEST, and NGAP PATH SWITCH REQUEST ACKNOWLEDGE messages shall be done according to clauses 6.9.2.3.2 and 6.9.2.3.3.

6.9.4.5  AS key refresh

This procedure is based on an intra-cell handover. The K gNB chaining that is performed during a handover ensures that the K gNB is re-freshed with respect to the RRC and UP COUNT after the procedure. The gNB/ng-eNB shall indicate to the UE to change the current K gNB in intra-cell handover during this procedure.

6.9.5  Rules on concurrent running of security procedures  Word‑p. 88

6.9.5.1  Rules related to AS and NAS security context synchronization

Concurrent runs of security procedures may, in certain situations, lead to mismatches between security contexts in the network and the UE. In order to avoid such mismatches, the following rules shall be adhered to:

1. AMF shall not initiate any of the N2 procedures including a new key towards a UE if a NAS Security Mode Command procedure is ongoing with the UE.

2. The AMF shall not initiate a NAS Security Mode Command towards a UE if one of the N2 procedures including a new key is ongoing with the UE.

3. When the AMF has sent a NAS Security Mode Command to a UE in order to take a new K AMF into use and receives a request for an inter-AMF handover or an inter-RAT handover from the serving gNB/ng-eNB, the AMF shall wait for the completion of the NAS SMC procedure (i.e. receiving NAS Security Mode Complete) before initiating an inter-AMF handover or initiating an inter-RAT handover.

4. When the AMF has initiated a NGAP UE Context Modification procedure in order to take a new K gNB into use, and receives a request for an inter-AMF handover from the serving gNB/ng-eNB, and decides not to change the K AMF for the inter-AMF handover, the AMF shall wait for the (successful or unsuccessful) completion of the UE Context Modification procedure before initiating an inter-AMF handover.

5. Once the source AMF has initiated inter-AMF handover to the target AMF, or inter-system handover to the target MME, the source AMF shall not send any downlink NAS messages to the UE until it is aware that the handover has either failed or has been cancelled.

6.9.5.2  Rules related to parallel NAS connections

Concurrent runs of security procedures in parallel over two different NAS connections when terminated in the same AMF can lead to race conditions and mismatches between the security contexts in the network and the UE. In order to avoid such mismatches, the following rules shall be followed:

1. The SEAF/AMF shall not initiate a primary authentication or NAS SMC procedure in case a primary authentication or a NAS SMC procedure is ongoing on a parallel NAS connection. Authentication procedures followed by a NAS SMC procedures taking the new 5G security context into use, shall be performed on one NAS signalling connection at a time.

2. When the AMF has sent a NAS Security Mode Command to a UE in order to take a new K AMF into use and receives a context transfer request message for the UE from another AMF, the AMF shall wait for the completion of the NAS SMC procedure (e.g. receiving NAS Security Mode Complete) before transferring the context.

3. The UE shall not initiate a NAS registration over a second NAS connection to an AMF of the same network before primary authentication on the first NAS connection is complete.

6.9.6  Security handling in registration with AMF reallocation via direct NAS reroute