Content for  TS 33.401  Word version:  18.1.0

The user plane data is ciphered by the PDCP protocol between the UE and the eNB as specified in TS 36.323. The use and mode of operation of the 128-EEA algorithms are specified in Annex B. The input parameters to the 128-bit EEA algorithms as described in Annex B are an 128-bit cipher key KUPenc as KEY, a 5-bit bearer identity BEARER which value is assigned as specified by TS 36.323, the 1-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.

This clause applies only to the user plane on the Un interface between RN and DeNB and Uu interface between UE and eNB: The user plane data is integrity-protected by the PDCP protocol between the RN and the DeNB as specified in TS 36.323. Replay protection shall be activated when integrity protection is activated. Replay protection shall ensure that the receiver only accepts each particular incoming PDCP COUNT value once using the same AS security context. The use and mode of operation of the 128-EIA algorithms are specified in Annex B. The input parameters to the 128-bit EIA algorithms as described in Annex B are a 128-bit integrity key KUPint as KEY, a 5-bit bearer identity BEARER which value is assigned as specified by TS 36.323, the 1-bit direction of transmission DIRECTION, and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT. The supervision of failed UP integrity checks shall be performed both in the UE and the eNB, and in the RN and the DeNB. In case of failed integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message shall be discarded. This can happen on the UE side or on the eNB side. This can also happen on the DeNB side or on the RN side. UE and the eNB shall derive UP integrity key as specified in Annex A.7.

If the UE indicates that it supports user plane integrity protection with EPS in EIA7 in the EPS security capability, the MME shall provide UP integrity protection policy for each E-RAB to the eNB during the Attach/Dedicated bearer activation/Dedicated bearer modification procedure as specified in TS 23.401. The MME receives UP integrity protection policy from SMF+PGW-C via SGW. The UP integrity protection policy shall indicate whether UP integrity protection shall be activated or not for all DRBs belonging to that E-RAB. The eNB shall be locally configured with UP integrity protection policy. If the eNB receives UP integrity protection policy from the MME, the eNB shall use the received UP integrity protection policy, otherwise, the eNB shall use the locally configured UP integrity protection policy if EIA7 in the EPS security capability indicates that the UE supports user plane integrity protection with EPC. The locally configured UP integrity protection policy on eNB should be set as "preferred". The eNB shall activate UP integrity protection per each DRB, according to the UP integrity protection policy, using RRC signalling as defined in clause 7.3.4. If the UP integrity protection policy indicates "Required", the eNB shall activate UP integrity protection. If the eNB cannot activate UP integrity protection, and when the UP integrity protection policy is "Required", the eNB shall reject establishment of UP resources for the E-RAB and indicate reject-cause to the MME. If the UP integrity protection policy is "Not needed", the eNB shall not activate UP integrity protection. At an X2-handover from the source eNB to the target eNB, the source eNB shall include in the HANDOVER REQUEST message, the UP integrity protection policy, the UE EPS security capability and the corresponding E-RAB ID, if the UP integrity protection policy is received from other entities. If the target eNB does not receive the UP integrity protection policy, but the EIA7 in the EPS security capability indicates that the UE supports user plane integrity protection with EPC, the target eNB shall use its locally configured UP integrity protection policy to activate or deactivate the UP integrity protection for all DRBs belonging to the E-RAB. If the received UP integrity protection policy is 'Required', the target eNB shall reject all E-RABs for which it cannot comply with the corresponding UP integrity protection policy and indicate the reject-cause to the MME. For the accepted E-RABs, the target eNB shall activate UP integrity protection per DRB according to the UP integrity protection policy and shall indicate that to the UE in the HANDOVER COMMAND by the source eNB. If the UE receives an indication in the HANDOVER COMMAND that UP integrity protection for an E-RAB is enabled at the target eNB, the UE shall generate or update the UP integrity protection key and shall activate UP integrity protection for the respective E-RAB. Further, in the Path-Switch message, the target eNB shall send the UE's UP integrity protection policy and corresponding E-RAB ID to the MME. The sent UP integrity protection policy can either be the one received from source eNB or the locally configured one if the target eNB does not receive it from the source eNB, but the EIA7 in the EPS security capability indicates that the UE supports user plane integrity protection with EPC. If the MME receives UP integrity protection policy, the MME shall verify that the UP integrity protection policy received from the target eNB is the same as the UP integrity protection policy that the MME has locally stored. If there is a mismatch, the MME shall send its locally stored UE's UP integrity protection policy of the corresponding E-RABs to the target eNB. This UP integrity protection policy, if included by the MME, is delivered to the target eNB in the Path-Switch Acknowledge message. The MME may support logging capabilities for this event and may take additional measures, such as raising an alarm. If the target eNB receives UE's UP integrity protection policy from the MME in the Path-Switch Acknowledge message, the target eNB shall update the UE's UP integrity protection policy with the received UE's UP integrity protection policy. If UE's current UP integrity protection activation is different from the determination of received UE's UP integrity protection policy, then the target eNB shall initiate intra-cell handover procedure which includes RRC Connection Reconfiguration procedure to reconfigure the DRBs to activate or de-activate the UP integrity as per the received policy from MME. At an S1-handover, the source MME shall send the UE's UP integrity protection policy and the UE EPS security capability to the target eNB via the target MME. Besides, the source eNB shall also send the UE's UP integrity protection policy if received from the source MME to the target eNB in a source-to-target container. The target eNB shall use the UE capability indicating support of UP IP in EPS together with the UP integrity protection policy received from the MME and ignore the UP integrity protection received in the source-to-target container. If the target eNB does not receive the UP integrity protection policy from the MME, the target eNB shall use the UE capability indicating support of UP IP in EPS together with the UP integrity protection policy received from the source eNB. If both policies from MME and source eNB are absent, but EIA7 in the EPS security capability indicates that the UE supports use of user plane protection with EPC, the eNB shall use locally configured UP integrity protection policy. The target eNB shall reject all E-RABs for which it cannot comply with the corresponding UP integrity protection policy and indicate the reject-cause to the source MME via the target MME. For all other E-RABs, the target eNB shall activate UP integrity protection per DRB according to the used UP integrity protection policy. If the target MME detects in a TAU procedure following S1-handover, and becomes aware of that there is a mismatch between the UE EPS security capabilities received from the source MME and the one received from the UE, and that the target eNB may not have the UE capability indicating UP IP support in UE EPS security capabilities, then the MME shall send an S1 CONTEXT MODIFICATION REQUEST message to inform the eNB about the correct UE EPS security capabilities and the target eNB shall take the new UE EPS security capabilities into account. At interworking-handover from 5GS to EPS, the SMF+PGW-C provides the UE's UP integrity protection policy to the target eNB via the target MME. The target eNB shall determine from the UP integrity protection policy received from the SMF+PGW-C via the MME together with indication that the UE supports use of user plane protection with EPC whether to activate user plane integrity protection with the UE or not. If the target eNB does not receive the UP integrity protection policy from the SMF+PGW-C via the MME, but the UE indicates support of UP integrity protection with EPS , the eNB shall use locally configured UP integrity protection policy. The target eNB shall reject all E-RABs for which it cannot comply with the corresponding UP integrity protection policy and indicate the reject-cause to the source AMF via the target MME. For all other E-RABs, the target eNB shall activate UP integrity protection per DRB according to the used UP integrity protection policy.

AS UP integrity protection activation shall be done as part of the DRB addition procedure using RRC Connection Reconfiguration procedure as described in this clause, see Figure 7.3.4-1. As defined in Clause 7.3.3, the MME may send the UP integrity protection policy to the eNB. If the MME does not send the UP integrity protection policy, the eNB may use locally configured UP integrity protection policy.

If UP integrity protection is not activated for DRBs, the eNB and the UE shall not integrity protect the traffic of such DRB and shall not put MAC-I into PDCP packet.

When the eNB needs to activate user plane integrity protection as part of the DRB addition procedure using RRC Connection Reconfiguration procedure then the eNB shall select the NR algorithm (NIA) for the integrity algorithm which corresponds to the EPS algorithm (EIA) which the eNB selected and indicated to the UE in the AS Security Mode Command procedure. The eNB shall map the EPS security algorithm to the corresponding NR security algorithm in the following way:

RRC integrity protection shall be provided by the PDCP layer between UE and eNB and no layers below PDCP shall be integrity protected. Replay protection shall be activated when integrity protection is activated (except for when the selected integrity protection algorithm is EIA0, see Annex B). Replay protection shall ensure that the receiver only accepts each particular incoming PDCP COUNT value once using the same AS security context. The use and mode of operation of the 128-EIA algorithms are specified in Annex B. The input parameters to the 128-bit EIA algorithms as described in Annex B are an 128-bit integrity key KRRCint as KEY,, a 5-bit bearer identity BEARER which value is assigned as specified by TS 36.323, the 1-bit direction of transmission DIRECTION and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT. The supervision of failed RRC integrity checks shall be performed both in the ME and the eNB. In case of failed integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message shall be discarded. This can happen on the eNB side or on the ME side.

RRC confidentiality protection is provided by the PDCP layer between UE and eNB. The use and mode of operation of the 128-EEA algorithms are specified in Annex B. The input parameters to the 128-bit EEA algorithms as described in Annex B are an 128-bit cipher Key KRRCenc as KEY, a 5-bit bearer identity BEARER which corresponds to the radio bearer identity, the 1-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.

The KeNB* and token calculation at handover preparation are cell specific instead of eNB specific. At potential RRC Connection re-establishment (e.g, in handover failure case), the UE may select a cell different from the target cell to initiate the re-establishment procedure. To ensure that the UE RRCConnectionRe-establishment attempt is successful when the UE selects another cell under the control of the target eNB at handover preparation, the serving eNB could prepare multiple KeNB*s and tokens for multiple cells which are under the control of the target eNB. The serving eNB may prepare cells belonging to the serving eNB itself. The preparation of these cells includes sending security context containing KeNB*s and tokens for each cell to be prepared, as well as the corresponding NCC, the UE EPS security capabilities, and the security algorithms used in the source cell for computing the token, to the target eNB. The source eNB shall derive the KeNB*s as described in Annex A.5 based on the corresponding target cell's physical cell ID and frequency EARFCN-DL. In order to calculate the token, the source eNB shall use the negotiated EIA-algorithm from the AS Security context from the source eNB with the following inputs: source C-RNTI, source PCI and target Cell-ID as defined by VarShortMAC-Input in TS 36.331, 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 RRCConnectionReestablishmentRequest 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. To avoid that the UE cannot perform the RRC re-establishment procedure if there is a failure during a handover or a connection re-establishment, the UE shall keep the KeNB used in the source cell until the handover or a connection re-establishment has completed successfully or until the UE has deleted the KeNB due to other rules in this specification (e.g., due to transitioning to ECM-IDLE). For X2 handover, the target eNB shall use these received multiple KeNB*s. But for S1 handover, the target eNB discards the multiple KeNB*s received from the source eNB, and derives the KeNB*s as described in Annex A.5 based on the received fresh {NH, NCC} pair from MME for forward security purpose. When an RRCConnectionReestablishmentRequest is initiated by the UE, the RRCConnectionReestablishmentRequest 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. The target eNB receiving the RRCConnectionReestablishmentRequest shall respond with an RRCConnectionReestablishment message containing the NCC received during the preparation phase if the token is valid, otherwise the target eNB shall reply with an RRCConnectionReestablishmentReject message. The RRCConnectionReestablishment and RRCConnectionReestablishmentReject messages are also sent on SRB0 and hence not integrity protected. Next the target eNB and UE shall do the following:.The UE shall firstly synchronize the locally kept NH parameter as defined in Annex A.4 if the received NCC value is different from the current NCC value in the UE itself. Then the UE shall derive KeNB* as described in Annex A.5 based on the selected cell's physical cell ID and its frequency EARFCN-DL. The UE shall use this KeNB* as KeNB. The eNB uses the KeNB* corresponding to the selected cell as KeNB. Then, UE and eNB shall derive and activate keys for integrity protection and verification from this KeNB and the AS algorithms (ciphering and integrity algorithms) obtained during handover preparation procedures which were used in source eNB. Even if the AS algorithms used by the source eNB do not match with the target eNB local algorithm priority list the source eNB selected AS algorithms shall take precedence when running the RRCConnectionRe-establishment procedure. The target eNB and UE should refresh the selected AS algorithms and the AS keys based on local prioritized algorithms after the RRCConnectionRe-establishment procedure. The UE shall respond with an RRCReestablishmentComplete on SRB1, integrity protected and ciphered using these new keys. The RRCConnectionReconfiguration procedure used to re-establish the remaining radio bearers shall only include integrity protected and ciphered messages.

If the UE experience a RLF when using Control Plane CIoT EPS optimisation only, the AS layer of the UE may trigger an RRCConnectionReestablishment procedure. As there is no AS security available, this procedure can not be protected as described in clause 7.4.3. In order to protect the the re-establishment procedure, the AS part of the UE triggers the NAS part of the UE to provide the UL_NAS_MAC and XDL_NAS_MAC. These parameter are used to show that the UE is requesting the re-establishment and that the UE is talking to a genuine network repsectively. The UE calculates a UL_NAS_MAC and XDL_NAS_MAC by using the curently used NAS integrity algorithm with the following inputs, KNASint as the key, the uplink NAS COUNT that would be used for the next uplink NAS message, the DIRECTION bit set to 0 and the target Cell-ID as the message to be protected to calculate NAS-MAC (see Annex B.2.1). The uplink NAS COUNT is increased by the UE in exactly the same way as if it had sent a NAS message. The first 16 bits of NAS-MAC form UL_NAS_MAC and the last 16 bits form XDL_NAS_MAC, which is stored by the UE. The UE shall send the RRCConntectionRestablishmentRequest message to the target eNB and shall include S-TMSI, the 5 least significant bits (LSB) of the NAS COUNT that was used to calculate NAS-MAC and UL_NAS_MAC in the message. The target eNB recognises the RRCConntectionRestablishmentRequest message sent by a UE relates to the Control Plane CIoT EPS optimisation based on the presence of the S-TMSI in the message. The target eNB shall send the S-TMSI, LSB of NAS COUNT, UL_NAS_MAC and target Cell-ID in the eNB CP Relocation Indication message to the MME that is serving the UE (this can be deteremined by the S-TMSI). The MME uses LSB of NAS COUNT to estimate the full uplink NAS COUNT and calculates XNAS-MAC (see Annex B.2.1) using the same inputs (i.e. estimated uplink NAS COUNT, DIRECTION bit set to 0 and the target Cell-ID as the message) as the UE used for calculating NAS-MAC. The MME then compares the received UL_NAS_MAC with the first 16 bits of XNAS-MAC and if these are equal the network is sure that the geniune UE sent the RRCConntectionRestablishmentRequest message. The stored uplink NAS COUNT in the MME is set as though the MME received a sucessfully protected NAS message using that NAS COUNT. The MME shall set DL_NAS_MAC to the last 16 bits of already calculated XNAS-MAC and send DL_NAS_MAC to the target eNB in the Connection Establishment Indication message. The target eNB shall send the DL_NAS_MAC to the UE in the RRCConnectionReestablisment message. The UE shall check that the received DL_NAS_MAC equal to the stored XDL_NAS_MAC. If so, the UE shall complete the re-establishment procedure.

The network should activate AS security (i.e., perform a successful AS SMC procedure) before running the RRC UE capability transfer procedure. With the exception of unauthenticated emergency calls and the UEs using Control plane CIoT optimization, if the network had acquired UE capabilities using RRC UE capability transfer procedure before AS security activation, then the network shall not store them locally for later use and shall not send them to other network entities. In that case, the network shall re-run the RRC UE capability transfer procedure after a successful AS SMC procedure.