Content for  TS 33.501  Word version:  19.0.0

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

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 KgNB and a Next Hop parameter (NH). The KgNB and the NH are derived from the KAMF. A NH Chaining Counter (NCC) is associated with each KgNB and NH parameter. Every KgNB is associated with the NCC corresponding to the NH value from which it was derived. At initial setup, the KgNB is derived directly from KAMF, 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 KgNB 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 KgNB 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 KgNB that will be used between the UE and the target gNB/ng-eNB, called KNG-RAN*, is derived from either the currently active KgNB or from the NH parameter. If KNG-RAN* is derived from the currently active KgNB this is referred to as a horizontal key derivation (see Figure 6.9.2.1.1-1) and if the KNG-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 KgNB in the target gNB/ng-eNB. On handovers with horizontal key derivation the currently active KgNB is further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the KgNB in the target gNB/ng-eNB.

During mobility, NAS aspects that need to be considered are the possible KAMF 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 KAMF (if unchanged) or derives the NAS keys from the new KAMF (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 KAMF has not changed, all inputs, in particular the KAMF, will be the same in the re-derivation except for the NAS algorithm identity. When the KAMF has changed, new NAS keys are derived irrespective of change in NAS algorithms. In case the KAMF 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).

The gNB shall have a policy deciding at which intra-gNB-CU handovers the KgNB can be retained and at which a new KgNB needs to be derived. At an intra-gNB-CU handover, the gNB shall indicate to the UE whether to change or retain the current KgNB in the HO Command message. Retaining the current KgNB shall only be done during intra-gNB-CU handover. If the current KgNB is to be changed, the gNB/ng-eNB and the UE shall derive a KNG-RAN* as in Annex A.11 / Annex A.12 using target PCI, its frequency ARFCN-DL/EARFCN-DL, and either NH or the current KgNB depending on the following criteria: the gNB shall use the NH for deriving KNG-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 KNG-RAN* from the current KgNB (this is referred to as a horizontal key derivation). The gNB shall send the NCC used for the KNG-RAN*derivation to UE in HO Command message. The gNB/ng-eNB and the UE shall use the KNG-RAN* as the KgNB, after handover. If the current KgNB is to be retained, the gNB and the UE shall continue using the current KgNB, after handover.

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 KNG-RAN* from target PCI, its frequency ARFCN-DL/EARFCN-DL, and either from currently active KgNB in case of horizontal key derivation or from the NH in case of vertical key derivation as described in Annex A.11 / Annex A.12. Next, the source gNB/ng-eNB shall forward the {KNG-RAN*, NCC} pair to the target gNB/ng-eNB. The target gNB/ng-eNB shall use the received KNG-RAN* directly as KgNB to be used with the UE. The target gNB/ng-eNB shall associate the NCC value received from source gNB/ng-eNB with the KgNB. 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 KAMF 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 KAMF, 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 KgNB from the new KAMF 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 KgNB with a new NCC value equal to zero. Then, the AMF shall use {the derived new initial KgNB, 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.

Upon reception of the NGAP HANDOVER REQUIRED message, if the source AMF does not change the active KAMF (meaning no horizontal KAMF 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 KAMF 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 KAMF 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 KAMF, 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 KAMF sent by source AMF to target AMF is not in sync with the current KgNB 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 KgNB associated with NCC=0 using the new KAMF and the uplink NAS COUNT from the last successful NAS SMC procedure with the UE and provide the {NH= newly derived KgNB, 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 KAMF derivation on currently active KAMF. If horizontal KAMF derivation is performed, the Namf_Communication_CreateUEContext Request shall contain an indication (i.e., keyAmfHDerivationInd ) that the new KAMF 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 KAMF. The ngKSI for the newly derived KAMF key has the same value and the same type as the ngKSI of the current KAMF. Further, the source AMF shall derive a new KgNB associated with NCC=0 using the newly derived KAMF and the uplink NAS COUNT value of 232-1 as defined in Annex A.9. The source AMF shall include the{NH=newly derived KgNB, NCC=0} pair and the ngKSI for the newly derived KAMF 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 KAMF derivation (i.e., keyAmfHDerivationInd), it shall derive the NAS keys from the received KAMF 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 KAMF 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 KNASint 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 KNASint;
• 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 KAMF 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 KAMF 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 KNG-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 KNG-RAN* corresponding to the selected cell as KgNB. The ng-eNB uses the KNG-RAN* corresponding to the selected cell as KeNB. The target ng-eNB/gNB shall associate the NCC value received from AMF with the KgNB/KeNB. 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.

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 KNG-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 KAMF has been calculated (i.e., K_AMF_change_flag is one),
  • The UE shall compute the horizontally derived KAMF using the KAMF 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 KAMF. The UE shall further configure NAS security based on the horizontally derived KAMF 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 KAMF 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 KAMF and the NAS COUNT value of 232-1 in the derivation of the temporary KgNB. 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 KgNB/KeNB, the UE shall derive the KNG-RAN* from the currently active KgNB/KeNB 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 KgNB/KeNB, 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 KNG-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 KNG-RAN* as the KgNB when communicating with the target gNB and as the KeNB when communicating with the target ng-eNB.