The
KNG-RAN* and token calculation at handover preparation are cell specific instead of gNB specific. During the handover procedure, at potential RRC connection reestablishment (e.g., in handover failure case), the UE may select a cell different from the target cell to initiate the reestablishment procedure. To ensure that the UE RRC connection re-establishment attempt is successful when the UE selects another cell under the control of the target gNB at handover preparation, the source gNB may prepare multiple
KNG-RAN* keys and tokens for multiple cells which are under the control of the target gNB. The source gNB may prepare for multiple cells belonging to the serving gNB itself.
The preparation of these cells includes sending security context containing
KNG-RAN* keys and tokens for each cell to be prepared, as well as the corresponding NCC, the UE 5G security capabilities, and the security algorithms used in the source cell for computing the token, to the target gNB. The source gNB shall derive the
KNG-RAN* keys as described in
Annex A.11/
A.12 based on the corresponding target cell's physical cell ID and frequency ARFCN-DL.
In order to calculate the token, the source gNB shall use the negotiated NIA-algorithm from the 5G AS Security context from the source gNB with the following inputs: source C-RNTI, source PCI and target Cell-ID, where source PCI and source C-RNTI are associated with the cell the UE last had an active RRC connection with and target Cell-ID is the identity of the target cell where the RRCReestablishmentRequest is sent to.
-
KEY shall be set to KRRCint of the source cell;
-
all BEARER bits shall be set to 1;
-
DIRECTION bit shall be set to 1;
-
all COUNT bits shall be set to 1.
The token shall be the 16 least significant bits of the output of the used integrity algorithm.
In order to avoid UE's inability to perform the RRC re-establishment procedure due to a failure during a handover or a connection re-establishment, the UE shall keep the
KgNB used in the source cell until the handover or a connection re-establishment has been completed successfully or until the UE has deleted the
KgNB for other reasons (e.g., due to transitioning to CM-IDLE).
For Xn handover, the target gNB shall use the received multiple
KNG-RAN* keys. But for N2 handover, the target gNB discards the multiple
KNG-RAN* keys received from the source gNB, and derives the
KNG-RAN* keys as described in
Annex A.11/
A.12 based on the received fresh {NH, NCC} pair from AMF for forward security purpose.
When an RRCReestablishmentRequest is initiated by the UE, the RRCReestablishmentRequest shall contain the token corresponding to the cell the UE tries to reconnect to. This message is transmitted over SRB0 and hence not integrity protected.
If the target gNB receiving the RRCReestablishmentRequest has a prepared
KNG-RAN* key and token for the specific cell, the target gNB receiving the RRCReestablishmentRequest shall validate the token received in the RRCReestablishmentRequest. However, if the target gNB has not prepared token for the cell, the target gNB extracts the C-RNTI and PCI from the RRCReestablishmentRequest message. The target gNB contacts the source gNB based on PCI by sending an Xn-AP Retrieve UE Context Request message with the following included: C-RNTI, PCI, the token and target Cell-ID, in order to allow the source gNB to validate the UE request and to retrieve the UE context including the UE 5G AS security context.
The source gNB retrieves the stored UE context including the UE 5G AS security context from its database using the C-RNTI. The source gNB verifies the token. If the verification is successful, then the source gNB calculates
KNG-RAN* using the target cell PCI, target ARFCN-DL and the
KgNB/NH in the current UE 5G AS security context based on either a horizontal key derivation or a vertical key derivation according to whether the source gNB has an unused pair of {NCC, NH} as described in
Annex A.11. The source gNB can obtain the target PCI and target ARFCN-DL from a cell configuration database by means of the target Cell-ID which was received from the target gNB. Then the source gNB shall respond with an Xn-AP Retrieve UE Context Response message to the target gNB including the UE context that contains the UE 5G AS security context.
After successful verification of token by either target gNB or source gNB, the target gNB shall check whether it supports ciphering and integrity algorithms that the UE was using with the last source cell, if supports and these algorithms are the chosen algorithms or they are not the chosen algorithms by the target gNB, the target gNB shall use the
KNG-RAN* corresponding to the selected cell as
KgNB and derive new RRC keys (new
KRRCint and new
KRRCenc) based on the
KgNB and the AS algorithms used in source cell.
Then, the target gNB shall respond with an RRCReestablishment message containing the NCC received during the preparation phase or context fetch phase. This RRCReestablishment message is sent on SRB1 and is integrity protected in PDCP layer using the newly calculated
KRRCint.
If verification of the token is failed by either target gNB or source gNB, or the target gNB does not support the ciphering and integrity algorithms used in source cell, the target gNB shall reply with an RRCSetup message. The RRCSetup message is sent on SRB0 and hence not integrity protected.
Next the target gNB and UE shall do the following: The UE shall firstly synchronize the locally kept NH parameter as defined in
Annex A.10 if the received NCC value is different from the current NCC value in the UE itself. Then the UE shall derive
KNG-RAN* as described in
Annex A.11/
A.12 based on the selected cell's physical cell ID and its frequency ARFCN-DL. The UE shall use this
KNG-RAN* as
KgNB. The gNB uses the
KNG-RAN* corresponding to the selected cell as
KgNB. The UE shall derive the new RRC keys from the
KgNB and the AS algorithms (ciphering and integrity algorithms) the UE was using with the source cell. The UE shall verify the integrity of the RRCReestablishment message by verifying the PDCP MAC-I using the newly derived
KRRCint.
If the UE successfully validate the integrity of the received RRCReestablishment message, the UE shall respond with an RRCReestablishmentComplete on SRB1 while being integrity protected and ciphered using the new RRC keys. The RRCConnectionReconfiguration procedure used to re-establish the remaining radio bearers shall only include integrity protected and ciphered messages.
When the UE receives RRCSetup message, the UE shall perform the RRC connection establishment procedure as if the UE was in RRC_IDLE.
