Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.401  Word version:  17.3.0

Top   Top   Up   Prev   Next
1…   4   5…   6…   6.2…   7…   7.2.5…   7.2.8   7.2.9…   7.3…   8…   9…   10…   11…   15…   A…   B…   C…   C.1.6   C.2…   C.2.7   C.2.8   C.3…   C.4.7   D…   E…   E.2…   E.3…   F…   G…   H…   I…   K…

 

E (Normative)  Dual connectivity |R13|p. 136

E.1  Introduction |R12|p. 136

E.1.1  General |R15|p. 136

This clause describes the security functions necessary to support a UE that is simultaneously connected to more than one eNB for the architectures for dual connectivity as described in TS 36.300. The security functions are described in the context of the functions controlling the dual connectivity.

E.1.2  Dual Connectivity architecture with an SeNB |R15|p. 136

For dual connectivity architecture, which hosts PDCP in MeNB the security functions described for the single connectivity mode in this specification are sufficient. The reason for that they are sufficient, is that the end-point for the encryption and integrity protection remains in the MeNB. That is, from a security point of view, the PDCP packets are still processed in the same locations in the architecture; they have only travelled a different path via the SeNB.
The remainder of the present clause deals with dual connectivity between an MeNB and an SeNB with the architecture as shown in Figure E.1.2-1.
Copy of original 3GPP image for 3GPP TS 33.401, Fig. E.1.2-1: Dual Connectivity architecture with an SeNB
Up
When the MeNB establishes security between an SeNB and the UE for the first time for a given AS security context shared between the MeNB and the UE, the MeNB generates the S-KeNB for the SeNB and sends it to the SeNB over the X2-C. To generate the S-KeNB, the MeNB associates a counter, called an SCG Counter, with the current AS security context. The SCG Counter is used as freshness input into S-KeNB derivations as described in the clause E.2.4, and guarantees, together with the other provisions in the present Annex E, that the KUPenc and the KUPint derived from the same S-KeNB is not re-used with the same input parameters as defined in Annex B of the present specification. The latter would result in key-stream re-use. The MeNB sends the value of the SCG Counter to the UE over the RRC signalling path when it is required to generate a new S-KeNB.
The communication established between the SeNB and the UE is protected at the PDCP layer using the AS Secondary Cell security context, or AS SC security context for short. The AS SC security context includes parameters as the AS security context described in clause 7 of the present specification, the S-KeNB replaces the KeNB. The UE and the SeNB derives the KUPenc and the KUPint from the S-KeNB as described in clause A.7, cf. also clause E.2.4.2.
Up

E.1.3  Dual Connecivity architecture with an SgNB |R15|p. 137

Annex E.3 describes the security functions necessary to support a UE that is simultaneously connected to eNB as master and gNB as secondary for EN-DC dual connectivity. The description in Annex E.3 is focused on the difference from dual connectivity in E-UTRAN described in Annex E.2. The major differences are
  1. with dual connectivity between an MeNB and an SgNB compared to between an MeNB and an SeNB is that in the former case a RRC signalling connection is allowed between the UE and the SgNB. Such a RRC signalling connection shall be integrity protected in addition to the ciphered with the chosen ciphering algorithm;
  2. EPS bearers from the core network to the SgNB may be Split across the radio resources of both MeNB and SgNB (as well as being Non-Split and only using radio resources of the SgNB); and
  3. for bearers whose PDCP terminates in the MeNB, the security functions described for the single connectivity mode in this specification shall be used, while for bearers whose PDCP terminates in the SgNB, the security algorithm given in clause E.3.10.1 with key derived as given in clause A.19 shall be used.
Copy of original 3GPP image for 3GPP TS 33.401, Fig. E.1.3-1: Offload architecture for EN-DC
Figure E.1.3-1: Offload architecture for EN-DC
(⇒ copy of original 3GPP image)
Up
When the MeNB establishes security between a SgNB and the UE for the first time for a given AS security context shared between the MeNB and the UE, the MeNB generates the S-KgNB (exactly as it would generate an S-KeNB) for the SgNB and sends it to the SgNB over the X2-C. The SCG Counter is also used as freshness input into S-KgNB derivations as described in the clause E.2.4, and guarantees, together with the other provisions in the present Annex E, that the integrity and ciphering keys used at the SgNB derived from the same S-KgNB are not re-used with the same input parameters to avoid in key-stream re-use and provide replay protection. The MeNB sends the value of the SCG Counter to the UE over the LTE RRC signalling path when it is required to generate a new S-KgNB.
The communication established between the SgNB and the UE is protected at the PDCP layer using the SgNB Secondary Cell security context, or SgNB SC security context for short. The SgNB SC security context includes S-KgNB, the key used as input to the UP confidentiality algorithm, KSgNB-UP-enc, the key used as input to the UP integrity algorithm, KSgNB-UP-int, the key used as the input to the RRC confidentiality algorithm, KSgNB-RRC-enc, the key used as the input for the RRC integrity algorithm, KSgNB-RRC-int, the identifiers of the selected cryptographic algorithms and counters used for replay protection. The UE and the SgNB derives the integrity and ciphering keys from the S-KgNB as described in clause A.19, cf. also clause E.3.4.2.
Up

Up   Top   ToC