6.11 Security handling for RRC connection re-establishment procedure

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

NOTE: This clause applies only to the gNB. Inter-RAT RRC Connection Re-establishment (i.e., between gNB and ng-eNB) is not supported. The RRC Connection Re-establishment procedure for the ng-eNB is specified in TS 33.401 [10].

The K_NG-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 K_NG-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 K_NG-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 K_NG-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 K_RRCint 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 K_gNB used in the source cell until the handover or a connection re-establishment has been completed successfully or until the UE has deleted the K_gNB for other reasons (e.g., due to transitioning to CM-IDLE).

For Xn handover, the target gNB shall use the received multiple K_NG-RAN* keys. But for N2 handover, the target gNB discards the multiple K_NG-RAN* keys received from the source gNB, and derives the K_NG-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 K_NG-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 K_NG-RAN* using the target cell PCI, target ARFCN-DL and the K_gNB/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 K_NG-RAN* corresponding to the selected cell as K_gNB and derive new RRC keys (new K_RRCint and new K_RRCenc) based on the K_gNB 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 K_RRCint.

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 K_NG-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 K_NG-RAN* as K_gNB. The gNB uses the K_NG-RAN* corresponding to the selected cell as K_gNB. The UE shall derive the new RRC keys from the K_gNB 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 K_RRCint.

NOTE: Void.

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.