Section: 6.9.2.3.3 N2-Handover
Content: 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[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [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[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [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.