6.9 Security handling in mobility
33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS
6.9.1 Void
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 KNG-RAN*/NH at handovers is depicted in Figure 6.9.2.1.1-1.
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 sub-clauses 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.
NOTE 1: At the UE, the NH derivation associated with NCC=1 could be delayed until the first handover performing vertical key derivation.
NOTE 1a: In N2 handover, when the KgNB is updated either due to KAMF change or synchronising the AS security context with the NAS security context, the KgNB is derived as specified in clauses 6.9.2.3.3 and 6.9.2.3.4 of the present document. In inter-RAT handover, the KgNB is derived as specified in clause 8.4 of the present document. In UE context modification, the KgNB is derived as specified in clause 6.9.2.2.
Whether the AMF sends the KgNB key or the {NH, NCC} pair to the serving gNB/ng-eNB is described in detail in sub-clauses 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.
NOTE 2: Since the AMF does not send the NH value to gNB/ng-eNB at the initial connection setup, the NH value associated with the NCC value one cannot be used in the next Xn handover or the next intra-gNB/intra-ng-eNB-CU handover, for the next Xn handover or the next intra-gNB-CU/intra-ng-eNB handover the horizontal key derivation (see Figure 6.9.2.1.1-1) will apply.
NOTE 3: One of the rules specified for the AMF in sub-clause 6.9.2.3.3 of the present document states that the AMF always computes a fresh {NH, NCC} pair that is given to the target gNB/ng-eNB. An implication of this is that the first {NH, NCC} pair will never be used to derive a KgNB. It only serves as an initial value for the NH chain.
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.
6.9.2.1.2 Non access stratum
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).
NOTE 1: It is per operator’s policy how to configure selection of handover types. Depending on an operator’s security requirements, the operator can decide whether to have Xn or N2 handovers for a particular gNB/ng-eNB according to the security characteristics of a particular gNB/ng-eNB.
NOTE 2: Following key change indicators are involved with N2 handovers. 1) Source AMF indicates AS key re-keying required meaning that the KAMF sent by source AMF to the target AMF is not in sync with current gNB/ng-eNB with keyAmfChangeInd (KAMF Change Indicator). 2) Source AMF indicates that the KAMF sent by source AMF to target AMF has been calculated using horizontal KAMF derivation with keyAmfHDerivationInd (KAMF Horizontal Derivation Indicator). 3) The target AMF indicates a horizontal KAMF derivation to the UE with K_AMF_change_flag in the NAS Container to tell the NAS layer of the UE to change KAMF. 4). The target AMF indicates anAS key re-keying to the gNB/ng-eNB with NSCI (New Security Context Indicator). 5) The gNB/ng-eNB indicates a AS re-keying to the UE with keySetChangeIndicator so that the AS layer of the UE knows that new KgNB needs to be derived from new KAMF instead of NH, and NCC needs to be reset to zero.
6.9.2.2 Key derivations for context modification procedure
As outlined in clause 6.9.2.1, whenever a fresh KgNB is calculated from the KAMF, the AMF shall transfer the KgNB 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 KgNB 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 KgNB. From the fresh KgNB, the ng-eNB/gNB and the UE shall compute the KNG-RAN* as described in Annex A.11 and A.12 and then use the computed KNG-RAN* as the KgNB/KeNB as described in clause 6.9.4.4.
NOTE 1: Unlike EPS, in 5GS the NAS and the AS security contexts are synchronized as a part of handover procedure, if a handover is occurring. See sub-clauses under the clause 6.9.2.3 (key derivations during handover) of the present document.
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 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.
NOTE: The option of retaining the KeNB at intra-ng-eNB handover is not supported in ng-eNB.
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/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.
NOTE 1: This clause is also applicable when gNB is implemented as a single unit, i.e., when the gNB is not split into CU and DU.
NOTE 2: The key derivation mechanism described in this clause is also applicable to CHO defined in TS 38.300[52].
6.9.2.3.2 Xn-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/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 .
NOTE 1: Because the NGAP PATH SWITCH REQUEST message is transmitted after the radio link handover, it can only be used to provide keying material for the next handover procedure. Thus, for Xn-handovers key separation happens only after two hops because the source gNB/ng-eNB knows the target gNB/ng-eNB keys. The target gNB/ng-eNB can immediately initiate an intra-gNB-CU/intra-ng-eNB handover to take the new NH into use once the new NH has arrived in the PATH SWITCH REQUEST ACKNOWLEDGE message.
NOTE 2: The key derivation mechanism described in this clause is also applicable to CHO defined in TS 38.300[52].
6.9.2.3.3 N2-Handover
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.
NOTE a: The uplink NAS COUNT value for the initial KgNB derivation is set to 232-1. The reason for choosing such a value is to avoid any possibility that the value may be used to derive the same KgNB again.
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.
NOTE 1: Void.
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 [35];
– 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.
NOTE 1a: VoidNOTE 2: The NAS Container (NASC) is defined as Intra N1 mode NAS transparent container in TS 24.501 [35].
NOTE 3: The downlink NAS COUNT is always included in the Namf_Communication_CreateUEContext Request and used by the target AMF for NAS MAC computation. This provides replay protection for NASC.
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.
NOTE 4: The source AMF may be the same as the target AMF in the description in this sub-clause. If so the single AMF performs the roles of both the source and target AMF. In this case, actions related to N14 messages are handled internally in the single AMF.
6.9.2.3.4 UE handling
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 [52], 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:
NOTE 1: The purpose of this NASC could be compared to a NAS SMC message.
– 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.
6.9.3 Key handling in mobility registration update
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 the 5G-GUTI, the Access Type 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. The source AMF uses the 5G NAS security context corresponding to the Access Type to perform the integrity check.
i) If the UE is found and the integrity check succeeds, when the source AMF does not change KAMF 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 KAMF 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.
NOTE: Void.
NOTE 1: The source AMF does not have KSEAF because it is deleted after KAMF derivation as per clause 6.2.2.1 and therefore the context transfer from the source AMF to the target AMF does not contain KSEAF.
At mobility registration update, the source AMF shall use local policy to determine whether to perform horizontal KAMF derivation. If the source AMF determines not to perform horizontal KAMF derivation, the source AMF shall transfer current security context to the target AMF. If the source AMF determines to perform horizontal KAMF derivation, the source AMF shall derive a new key KAMF from the currently active KAMF and the uplink NAS COUNT value in the received Registration Request message. The ngKSI for the newly derived KAMF key is defined such as the value field and the type field are taken from the ngKSI of the current KAMF. The source AMF shall transfer the new KAMF, the new ngKSI, the UE security capability, the keyAmfHDerivationInd to the target AMF. The key derivation of the new KAMF is specified in Annex A.13. If the source AMF has derived a new key KAMF, the source AMF shall not transfer the old KAMF 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 KAMF together with the keyAmfHDerivationInd, then the target AMF shall decide whether to use the KAMF 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 KAMF 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 KAMF 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 KAMF from which the UE shall derive a new KAMF 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 (KNASint and KNASenc) from the new KAMF using the selected NAS algorithm identifiers as input. The target AMF shall integrity protect the NAS Security Mode Command message with the new KNASint 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 KAMF from the current active KAMF 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 KAMF. The UE shall derive new NAS keys (KNASint and KNASenc) from the new KAMF and integrity check the NAS Security Mode Command message using the new KNASint key.
The UE shall then derive a new initial KgNB from the new KAMF as specified in Annex A.9.
The UE shall associate the derived new initial KgNB 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 KAMF and ngKSI values on both USIM and ME with the new KAMF and the associated ngKSI.
6.9.4 Key-change-on-the-fly
6.9.4.1 General
Key change on-the-fly consists of key refresh or key re-keying.
Key refresh shall be possible for KgNB, 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 KgNB. The procedure is described in clause 6.9.4.5.
Key re-keying shall be possible for the KgNB, 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 KgNB refresh (performed when PDCP COUNTs are about to wrap around), KgNB re-keying performed after an AKA run, activation of a native context after handover from E-UTRAN.
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 KAMF shall be achieved by first re-keying KAMF, then KNAS-enc and KNAS-int, followed by re-keying of the KgNB 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
After a primary authentication has taken place, new NAS keys from a new KAMF 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
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 KAMF key using horizontal KAMF 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 KAMF key and the algorithms in use. The AMF activates the new KAMF key by running a NAS SMC with UE according to clause 6.7.2. When the new KAMF 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 KAMF key as the AMF, reset the corresponding uplink and downlink NAS counters and then derive new NAS keys from the KAMF 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 KgNB from the new KAMF as specified in Annex A.9. Further, the AMF and the UE shall associate the derived new initial KgNB with a new NCC value equal to zero. Further, the derived new initial KgNB/KeNB 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
The KgNB/KeNB 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 KgNB from the current KAMF.
NOTE 1: To perform a key change on-the-fly of the entire key hierarchy, the AMF has to change the 5G NAS security context before changing the 5G AS security context.
In order to be able to re-key the KgNB, the AMF requires a fresh uplink NAS COUNT from a successful NAS SMC procedure with the UE. In the case of creating a new KgNB from the current KAMF 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 KgNB using the key derivation function as specified in Annex A.9 using the KAMF and the uplink NAS COUNT used in the most recent NAS Security Mode Complete message. The derived new KgNB 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 KgNB derivation steps shall be taken as in a normal handover procedure. The gNB/ng-eNB shall indicate to the UE to change the current KgNB 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 KgNB by applying the key derivation function as specified in Annex A.9 using the KAMF 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 KgNB the UE shall derive the KNG-RAN* as normal (see Annex A.11/A.12). The gNB/ng-eNB shall take the KgNB it received from the AMF, which is equal to the temporary KgNB, as basis for its KNG-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 KgNB 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 KAMF 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 KgNB chaining that is performed during a handover ensures that the KgNB 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 KgNB in intra-cell handover during this procedure.
6.9.5 Rules on concurrent running of security procedures
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 KAMF 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 KgNB into use, and receives a request for an inter-AMF handover from the serving gNB/ng-eNB, and decides not to change the KAMF 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 KAMF 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
In registration with AMF reallocation via direct NAS reroute, the initial AMF shall send the complete Registration Request in clear text to the target AMF.
NOTE: The completeRegistration Request in clear text is obtained based on the Registration Request initially received by the initial AMF if the UE have a valid NAS sececurity context, or the Registration Request received by the initial AMF as part of the Security Mode Complete if it is executed.
In registration with AMF reallocation via direct NAS reroute, the initial AMF shall use its local policy to determine whether to perform horizontal KAMF derivation on current KAMF. As described in Clause 6.9.3, if the initial AMF decides not to change KAMF, the initial AMF shall send the current security context to the target AMF; otherwise, the initial AMF shall derive new security context and send to the target AMF the derived security context and the indication of horizontal KAMF derivation (i.e., keyAmfHDerivationInd).
If the target AMF receives the indication of horizontal KAMF derivation (i.e., keyAmfHDerivationInd) from the initial AMF, it shall initiate NAS SMC. If the target AMF does not receive keyAmfHDerivationInd, the target AMF shall use the received security context from initial AMF and send protected NAS message including protected authentication request message if authentication is needed. The target AMF decides whether to perform authentication based on local policy.