Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

6.10  Dual connectivityWord‑p. 89

6.10.1  Introduction

6.10.1.1  General

This clause describes the security functions necessary to support a UE that is simultaneously connected to more than one NG-RAN node, i.e., Multi-Radio dual connectivity (MR-DC) with 5GC as described in TS 37.340. The security functions are described in the context of the functions controlling the dual connectivity.

6.10.1.2  Dual Connectivity protocol architecture for MR-DC with 5GC

The dual connectivity protocol architecture for MR-DC with 5GC is shown in figure 6.10.1.2-1. The TS 37.340 is to be referred for further details of the architecture illustrating MCG, SCG, and Split bearers for both SRBs and DRBs. The architecture has the following variants:
  • NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC) is the variant when the UE is connected to one ng-eNB that acts as a Master Node (MN) and one gNB that acts as a Secondary Node (SN). The ng-eNB is connected to the 5GC and the gNB is connected to the ng-eNB via Xn interface.
  • NR-E-UTRA Dual Connectivity (NE-DC) is the variant when the UE is connected to one gNB that acts as a MN and one ng-eNB that acts as a SN. The MN (i.e., gNB) is connected to 5GC and the ng-eNB (i.e., SN) is connected to the gNB via Xn interface.
  • NR-NR Dual Connectivity (NR-DC) is the variant when the UE is connected to one gNB that acts as a MN and one gNB that acts as a SN. The MN is connected to 5GC while the SN is connected to MN via Xn interface.
  • [not reproduced yet]
    Figure 6.10.1.2-1: Multi-Radio dual connectivity (MR-DC) protocol architecture.
    Up
    When the MN establishes security context between an SN and the UE for the first time for a given AS security context shared between the MN and the UE, the MN generates the KSN for the SN and sends it to the SN over the Xn-C. To generate the KSN, the MN associates a counter, called an SN Counter, with the current AS security context. The SN Counter is used as freshness input into KSN derivations as described in the clause 6.10.3.2. The MN sends the value of the SN Counter to the UE over the RRC signalling path when it is required to generate a new KSN. The KSN is used to derive further RRC and UP keys that are used between the UE and SN.
    Up

    6.10.2  Security mechanisms and procedures for DCWord‑p. 90

    6.10.2.1  SN Addition or modification

    When the MN is executing the Secondary Node Addition procedure (i.e. initial offload of one or more radio bearers to the SN), or the Secondary Node Modification procedure (as in clauses 10.2.2 and 10.3.2 in TS 37.340) which requires an update of the KSN, the MN shall derive an KSN as defined in clause 6.10.3.2 The MN shall maintain the SN Counter as defined in Clause 6.10.3.1
    When executing the procedure for adding subsequent radio bearer(s) to the same SN, the MN shall, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last KSN change. If the MN cannot allocate an unused radio bearer identity for a new radio bearer in the SN, due to radio bearer identity space exhaustion, the MN shall increment the SN Counter and compute a fresh KSN, and then shall perform a SN Modification procedure to update the KSN.
    The dual connectivity procedure with activation of encryption/decryption and integrity protection follows the steps outlined on the Figure 6.10.2.1-1.
    [not reproduced yet]
    Figure 6.10.2.1-1: Security aspects in SN Addition/Modification procedures (MN initiated)
    Up
    1. The UE and the MN establish the RRC connection.
    2. The MN sends SN Addition/Modification Request to the SN over the Xn-C to negotiate the available resources, configuration, and algorithms at the SN. The MN computes and delivers the KSN to the SN if a new key is needed. The UE security capabilities (see subclause 6.10.4) and the UP security policy received from the SMF shall also be sent to SN. In case of PDU split, UP integrity protection and ciphering activation decision from MN may be also included as described in subclause 6.10.4.
    3. The SN allocates the necessary resources and chooses the ciphering algorithm and integrity algorithm which has the highest priority from its configured list and is also present in the UE security capability. If a new KSN was delivered to the SN then the SN calculates the needed RRC. The UP keys may be derived at the same time when RRC key derived. The SN shall activate the UP security policy as described in subclause 6.10.4.
    4. The SN sends SN Addition/Modification Acknowledge to the MN indicating availability of requested resources and the identifiers for the selected algorithm(s) for the requested DRBs and/or SRB for the UE. The UP integrity protection and encryption indications shall be send to the MN.
    5. The MN sends the RRC Connection Reconfiguration Request to the UE instructing it to configure the new DRBs and/or SRB for the SN. The MN shall include the SN Counter parameter to indicate a new KSN is needed and the UE shall compute the KSN for the SN. The MN forwards the UE configuration parameters (which contains the algorithm identifier(s) received from the SN in step 4) , and UP integrity protection and encryption indications(received from the SN in step 4) to the UE (see subclause 6.10.3.3 for further details).
    6. The UE accepts the RRC Connection Reconfiguration Request after validating its integrity. The UE shall compute the KSN for the SN if an SN Counter parameter was included. The UE shall also compute the needed RRC and UP keys and activate the UP protection as per the indications received for the associated DRBs and/or SRB. The UE sends the RRC Reconfiguration Complete to the MN. The UE activates the chosen encryption/decryption and integrity protection keys with the SN at this point.
    7. MN sends SN Reconfiguration Complete to the SN over the Xn-C to inform the SN of the configuration result. On receipt of this message, SN may activate the chosen encryption/decryption and integrity protection with UE. If SN does not activate encryption/decryption and integrity protection with the UE at this stage, SN shall activate encryption/decryption and integrity protection upon receiving the Random Access request from the UE.
    Up

    6.10.2.2  Secondary Node key updateWord‑p. 91
    6.10.2.2.1  General
    The SN shall request the Master Node to update the KSN over the Xn-C, when uplink and/or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs or SCG SRB.
    If the Master Node re-keys its currently active AS key in an 5G AS security context the Master Node shall update any KSN associated with that 5G AS security context.
    Whenever the UE or SN start using a fresh KSN, they shall re-calculate the RRC and UP keys from the fresh KSN.
    6.10.2.2.2  MN initiated
    The Master Node may update the KSN for any reason. If the MN decides to update the KSN, the MN shall perform a SN modification procedure to deliver the fresh KSN to the SN as defined in clause 6.10.2.1. The MN shall provide the value of the SN Counter used in the derivation of the KSN to the UE in an integrity protected RRC Connection Reconfiguration procedure. The UE shall derive the KSN as described in clause A.16.
    6.10.2.2.3  SN initiated
    When uplink and/or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs or SCG SRB, the SN shall request the MN to update the KSN over the Xn-C using the SN Modification procedure with MN involvement. The SN shall send the SN Modification Required message including KSN key update an indication to the MN as shown in Figure 6.10.2.2.3-1. When the MN receives KSN Key update indication, the MN shall derive a fresh KSN and send the derived KSN to the SN in the SN Modification Request message as in clause 6.10.2.1. Rest of the flows are like the call flow in Clause 6.10.2.1.
    [not reproduced yet]
    Figure 6.10.2.2.3-1: SN Key update procedure using SN Modification procedure (SN initiated with MN involvement)
    Up

    6.10.2.3  SN release and changeWord‑p. 92
    When the SN releases the last UE radio bearer on the SN or when the SN is changed, i.e., the UE radio bearer(s) is moved from the SN, the SN and the UE shall delete the SN RRC and UP keys. The SN and UE shall also delete the KSN, if it was not deleted earlier.

    6.10.3  Establishing the security context between the UE and SN

    6.10.3.1  SN Counter maintenance

    The MN shall maintain a 16-bit counter, SN Counter, in its AS security context. The SN Counter is used when computing the KSN.
    The MN maintains the value of the counter SN Counter for a duration of the current 5G AS security context between UE and MN. The UE does not need to maintain the SN Counter after it has computed the KSN since the MN provides the UE with the current SN Counter value when the UE needs to compute a new KSN.
    The SN Counter is a fresh input to KSN derivation. That is, the UE assumes that the MN provides a fresh SN Counter each time and does not need to verify the freshness of the SN Counter.
    The MN shall set the SN Counter to '0' when a new AS root key, K NG-RAN, in the associated 5G AS security context is established. The MN shall set the SN Counter to '1' after the first calculated KSN, and monotonically increment it for each additional calculated KSN. The SN Counter value '0' is used to calculate the first KSN.
    If the MN decides to release the offloaded connections to the SN and later decides to re-start the offloading to the same SN, the SN Counter value shall keep increasing, thus keeping the computed KSN fresh.
    The MN shall refresh the root key of the 5G AS security context associated with the SN Counter before the SN Counter wraps around. Refreshing the root key is done using intra cell handover as described in subclause 6.7.3.3 of the present document. When the root key is refreshed, the SN Counter is reset to '0' as defined above.
    Up

    6.10.3.2  Derivation of keys

    The UE and MN shall derive the security key KSN of the SN as defined in Annex A.16 of the present document.
    The SN RRC and UP keys shall be derived from the KSN both at the SN and the UE using the function given in Annex A.7 of TS 33.401 if the SN is a ng-eNB or using the function given in Annex A.8 of the present specification if the SN is a gNB.
    Once all the SN RRC and UP keys have been derived from the KSN, the SN and UE may delete the KSN.
    Up

    6.10.3.3  Negotiation of security algorithms

    The MN shall receive the UE security capabilities from the AMF or the previous NG-RAN node. These security capabilities include both LTE and NR security capabilities.
    When establishing one or more DRBs and/or SRBs for a UE at the SN, as shown on Figure 6.10.2.1-1, the MN shall provide the UE security capabilities of the UE to the SN in the SN Addition/Modification Request message.
    Upon receipt of this message, the SN shall select the algorithms with highest priority in its locally configured list of algorithms that are also present in the received UE security capabilities and include the selected algorithms in SN Addition/Modification Request Acknowledge.
    The MN shall provide the selected algorithms to the UE during the RRCConnectionReconfiguration procedure that configures the DRBs and/or SRB with the SN for the UE. The UE shall use the indicated algorithms for the DRBs and/or SRB whose PDCP terminates on the SN.
    Up

    6.10.4  Protection of traffic between UE and SNWord‑p. 93
    This subclause provides the details of the needed SN RRC and UP keys and the algorithms used to protect the traffic whose PDCP terminates on the SN. The UE and SN may either calculate all the SN RRC and UP keys at once or as there are required to be used. The RRC and UP keys are K RRCenc and K RRCint for the SRB whose PDCP terminates on the SN and K UPenc for the DRBs whose PDCP terminate on the SN.
    When the SN is a gNB, the RRC traffic protection directly between the UE and SN is done using the mechanism described in subclause 6.5 of the present document with the algorithms specified in Annex D of the present document.
    When the SN is a gNB, the UP traffic protection and activation is done using the mechanism described in subclauses 6.6 of the present document using the algorithms specified in Annex D of the present document. The UP security activation procedure for MR-DC (meaning NR-DC, NE-DC and NGEN-DC) scenarios use the mechanism described in sublcause 6.10.2.1 with the following additional procedures:
    In the case of split PDU session where some of the DRB(s) is terminated at the MN and some DRB(s) is terminated at the SN, the MN shall ensure that all DRBs which belong to the same PDU session have the same UP integrity protection and ciphering activation. To achieve this, the MN shall inform the SN with its UP integrity protection and ciphering activation decision of any DRB that is offloaded and to be terminated at the SN. The SN shall activate the UP integrity protection and ciphering based on the MN decision.
    For UP Integrity Protection:
    Case 1: UP security policy indicates UP Integrity Protection "required":
    In NGEN-DC scenario, the MN shall reject the PDU session.
    In NE-DC scenario, if the MN decides to activate the UP integrity protection for this PDU session, the MN shall not offload any DRB of the PDU session to the SN.
    In NR-DC scenario, the MN makes the decision for PDU sessions that are terminated at the MN while the SN makes the decision for PDU sessions that are terminated at the SN.
    Case 2: UP security policy indicates UP Integrity Protection "preferred":
    In NGEN-DC scenario, the MN shall always deactivate UP integrity protection. In this case, the SN shall always deactivate the UP integrity protection of any PDU session terminated at the SN.
    In NE-DC scenario, if the MN has activated any of this PDU session DRBs with UP integrity protection "on", the MN shall not offload any DRB of this PDU session to the SN. However, if the MN has activated all DRBs of this PDU session with integrity protection "off", the MN may offload DRBs of this PDU session to the SN. In this case, the SN shall not activate the UP integrity protection and shall always set the UP integrity protection indication to "off".
    In NR-DC scenario, the MN makes the decision for PDU sessions that are terminated at the MN while the SN makes the decision for PDU sessions that are terminated at the SN.
    Case 3: UP security policy indicates UP Integrity Protection "not needed":
    In all MR-DC scenarios, the MN and SN shall always deactivate UP integrity protection.
    For UP Ciphering Protection:
    In all MR-DC scenario, the MN and SN shall make a decision on UP ciphering protection according to the UP security policy for PDU sessions which terminate at the MN and SN, respectively, where all DRBs belonging to the same PDU session shall have the ciphering protection either "on" or "off".
    In all scenarios of MR-DC, the SN shall send the UP integrity protection and encryption indications to the MN in the SN Addition/Modification Request Acknowledgement message. The MN shall forward the UP integrity protection and encryption indications to the UE in RRC Connection Reconfiguration message. The UE activate the UP security protection with the SN based on the UP integrity protection and encryption indications using the scheme described in subclause 6.6.2. If the MN has not activated the RRC security before sending the RRC Connection Reconfiguration message, the MN shall perform AS SMC procedure first.
    When the SN is a ng-eNB, the RRC and UP traffic is protected using the mechanism described in subclauses 7.4 and 7.3 respectively of TS 33.401 with the algorithms specified in Annex C of TS 33.401.
    Up

    6.10.5  Handover ProcedureWord‑p. 94
    During N2 and Xn handover, the DRB and/or SRB connections between the UE and the SN shall be released, and the SN and the UE shall delete the SN RRC and UP keys since they shall be refreshed by the new KSN derived by the target-MN.

    6.10.6  Signalling procedure for PDCP COUNT check

    SN may request the MN to execute a counter check procedure specified in Clause 6.13 of this specification to verify the value of the PDCP COUNT(s) associated with DRB(s) offloaded to the SN. To accomplish this, the SN shall communicate this request, including the expected values of PDCP COUNT(s) and associated radio bearer identities to the MN over the Xn-C.
    If the MN receives a RRC counter check response from the UE that contains one or several PDCP COUNT values (possibly associated with both MN and SN), the MN may release the connection or report the difference of the PDCP COUNT values to the serving AMF or O&M server for further traffic analysis, e.g., detecting the attacker.
    Up

    6.10.7  Radio link failure recovery

    Since the MN holds the control plane functions in MR-DC as in clause 6.10.1.2, the UE runs the RRC re-establishment procedure with the MN as specified in Clause 6.11 of the present document. During the RRC re-establishment procedure, the radio bearers between the UE and the SN shall be released.

    6.11  Security handling for RRC connection re-establishment procedure

    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.
    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.
  • Up

    Up   Top   ToC