Content for TS 33.501 Word version: 18.4.0

1… 4… 5… 5.3… 5.9… 5.10… 6… 6.1.3… 6.1.4… 6.2… 6.2.2… 6.3… 6.4… 6.5… 6.6… 6.7… 6.8… 6.9… 6.10… 6.11 6.12… 6.13 6.14… 6.15… 6.16… 7… 7A… 7A.2.3… 7B… 8… 9… 10… 11… 12… 13… 13.2.2… 13.2.4… 13.3… 13.4… 14… 15… 16… A… B… C… D… E… F… G… I… I.9… J… K… M… N… O… P… R S… T… U… V… W… X… Y… Z…

6.10 Dual connectivity 6.10.1 Introduction 6.10.1.1 General 6.10.1.2 Dual Connectivity protocol architecture for MR-DC with 5GC 6.10.2 Security mechanisms and procedures for DC 6.10.2.1 SN Addition or modification 6.10.2.2 Secondary Node key update 6.10.2.2.1 General 6.10.2.2.2 MN initiated 6.10.2.2.3 SN initiated 6.10.2.3 SN release and change 6.10.3 Establishing the security context between the UE and SN 6.10.3.1 SN Counter maintenance 6.10.3.2 Derivation of keys 6.10.3.3 Negotiation of security algorithms 6.10.4 Protection of traffic between UE and SN 6.10.5 Handover Procedure 6.10.6 Signalling procedure for PDCP COUNT check 6.10.7 Radio link failure recovery
...

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 p. 100

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.

Reproduction of 3GPP TS 33.501, Fig. 6.10.1.2-1: Multi-Radio dual connectivity (MR-DC) protocol architecture.

Figure 6.10.1.2-1: Multi-Radio dual connectivity (MR-DC) protocol architecture.

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.

6.10.2 Security mechanisms and procedures for DC p. 101

6.10.2.1 SN Addition or modification p. 101

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. In the case of Conditional PSCell Change and conditional PSCell addition as specified in TS 37.340, if there are more than one candidate SNs, for each SN, the MN shall derive a different KSN via using different SN counter as defined in clause 6.10.3.2.

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.

Reproduction of 3GPP TS 33.501, Fig. 6.10.2.1-1: Security aspects in SN Addition/Modification procedures (MN initiated)

Figure 6.10.2.1-1: Security aspects in SN Addition/Modification procedures (MN initiated)

Step 1.

The UE and the MN establish the RRC connection.

Step 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.

When the MN decides to configure CPA or CPC, if there are more than one candidate SNs, for each SN, the MN shall derive a different KSN and delivers the KSN to each SN seperately..

Step 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.

Step 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.

Step 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).

If an SN sends more than one candidate PScell SCG configuration, the MN signals to the UE that all these configurations are associated with the same SN counter value.

Step 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 RRC and UP protection as per the indications received for the associated SRB and/or DRBs respectively. 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.

Step 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.

6.10.2.2 Secondary Node key update p. 103

6.10.2.2.1 General p. 103

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 p. 103

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 p. 103

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.

Reproduction of 3GPP TS 33.501, Fig. 6.10.2.2.3-1: SN Key update procedure using SN Modification procedure (SN initiated with MN involvement)

Figure 6.10.2.2.3-1: SN Key update procedure using SN Modification procedure (SN initiated with MN involvement)

6.10.2.3 SN release and change p. 103

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 p. 103

6.10.3.1 SN Counter maintenance p. 103

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, KNG-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.

6.10.3.2 Derivation of keys p. 104

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.

6.10.3.3 Negotiation of security algorithms p. 104

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.

6.10.4 Protection of traffic between UE and SN p. 104

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 KRRCenc and KRRCint for the SRB whose PDCP terminates on the SN and KUPenc 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 subclause 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, if the UE does not indicate that it supports the use of integrity protection with ng-eNB:

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 integrity protection, if the UE indicates that it supports use of integrity protection with ng-eNB, in all 5GC-based MR-DC scenarios, the MN and SN shall make a decision on UP integrity 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 integrity protection either "on" or "off".

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. Additionally, the UP traffic is integrity protected based on the UP security policy and the indication that the UE supports the use of UP integrity protection with ng-eNB.

6.10.5 Handover Procedure p. 106

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 p. 106

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.

6.10.7 Radio link failure recovery p. 106

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.