Content for TS 33.401 Word version: 18.1.0

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…

7.0 General 7.1 Mechanism for user identity confidentiality 7.2 Handling of user-related keys in E-UTRAN 7.2.1 E-UTRAN key setting during AKA 7.2.2 E-UTRAN key identification 7.2.3 E-UTRAN key lifetimes 7.2.4 Security mode command procedure and algorithm negotiation 7.2.4a Algorithm negotiation for unauthenticated UEs in LSM
...

7 Security procedures between UE and EPS access network elements p. 33

7.0 General |R10| p. 33

The statements relating to eNBs in clause 7 apply also to RNs regarding the security between a UE and a relay node.

The statements relating to UEs in clause 7 apply also to RNs regarding the security between a relay node and a Donor eNB and between a relay node and its MME unless stated otherwise.

7.1 Mechanism for user identity confidentiality p. 33

The MME shall allocate a GUTI to a UE in order to support the subscriber identity confidentiality. The GUTI is defined in TS 23.003.

S-TMSI, the shortened form of the GUTI, is used to support the subscriber identity confidentiality with more efficient radio signalling procedures (e.g. paging and Service Request).

A new GUTI shall be sent to the UE only after a successful activation of NAS security.

M-TMSI generation should be following the best practices of unpredictable identifier generation. It is recommended that operator policy is set to frequently update the M-TMSI.

7.2 Handling of user-related keys in E-UTRAN p. 33

7.2.1 E-UTRAN key setting during AKA p. 33

Authentication and key setting are triggered by the authentication procedure. Authentication and key setting may be initiated by the network as often as the network operator wishes. Key setting can occur as soon as the identity of the mobile subscriber (i.e. GUTI or IMSI) is known by the MME. A successful run of AKA results in a new KASME that is stored in the UE and MME.

NAS keys, KeNB and the RRC and UP keys are derived from KASME using the KDFs specified in Annex A.

The NAS keys derived from the new KASME are taken in use in the MME and the UE by means of the NAS security mode set-up procedure (see clause 7.2.4.4). The AS keys are taken into use with the AS security mode set-up procedure (see clause 7.2.4.5) or with the key change on the fly procedure (see clause 7.2.9.2).

7.2.2 E-UTRAN key identification p. 33

Clause 6.3 of this specification states how the key KASME is identified, namely by the key set identifier eKSI. Keys KNASenc and KNASint in the E-UTRAN key hierarchy specified in clause 6.2, which are derived from KASME, can be uniquely identified by eKSI together with those parameters from the set {algorithm distinguisher, algorithm identifier}, which are used to derive these keys from KASME according to Annex A.

The initial KeNB can be uniquely determined by the key set identifier, i.e. eKSI, together with the uplink NAS COUNT are used to derive it. The intermediate key NH as defined in clause 7 can be uniquely determined by the key set identifier, i.e. eKSI, together with the initial KeNB derived from the current NAS security context for use during the ongoing CONNECTED state and a counter counting how many NH-derivations have already been performed from this initial KeNB.according to Annex A.4. The next hop chaining count, NCC, represents the 3 least significant bits of this counter.

Intermediate key KeNB*, defined in clause 7, as well as keys non-initial KeNB, KRRCint, KRRCenc, KUPint, and KUPenc in the E-UTRAN key hierarchy specified in clause 6.2 can be uniquely identified by eKSI together with those parameters from the set {Initial KeNB or NH, algorithm distinguisher, algorithm identifier, and sequence of PCIs and EARFCN-DLs used in horizontal key derivations from the initial KeNB or NH}, which are used to derive these keys from KASME according to clause 7 and clause A.7.

It is specified in the remainder of clause 7, as well as in clause 9 and 10, which of the above parameters need to be included in a security-relevant message to allow the entity receiving the message to uniquely identify a certain key.

7.2.3 E-UTRAN key lifetimes p. 34

All E-UTRAN keys are derived based on a KASME. The key hierarchy which is described in clause 6.2 does not allow direct update to RRC and UP keys, but fresh RRC and UP keys are derived based on a fresh KeNB, which is bound to certain dynamic parameters (like PCI) or fresh key derivation parameter(s) in state transitions (like NAS uplink COUNT). This results as fresh RRC and UP keys in the eNB between inter-eNB handovers and state transitions (see clauses 7.2.6 to 7.2.8). The handling (creation, modification and update) of the E-UTRAN keys in the various state transitions is described in clauses 7.2.5, 7.2.6, 7.2.7 and 7.2.8.

KASME shall be created only by running a successful AKA or by the inter-RAT procedures towards E-UTRAN (cf clauses 9 and 10). In case the UE does not have a valid KASME, a KSIASME with value "111" shall be sent by the UE to the network, which can initiate (re-)authentication procedure to get a new KASME based on a successful AKA authentication.

7.2.4 Security mode command procedure and algorithm negotiation p. 34

7.2.4.1 Requirements for algorithm selection p. 34

An active UE and a serving network shall agree upon algorithms for
- RRC ciphering and RRC integrity protection (to be used between UE and eNB)
- UP ciphering and integrity protection (to be used between UE and eNB)
- NAS ciphering and NAS integrity protection (to be used between UE and MME) An active RN and a network serving the RN shall additionally agree upon algorithms for UP integrity.
The serving network shall select the algorithms to use dependent on
- the UE security capabilities of the UE,
- the configured allowed list of security capabilities of the currently serving network entity
The same set of ciphering and integrity algorithms shall be supported by the UE both for AS and NAS level.
Each selected algorithm shall be acknowledged to the UE in an integrity protected way such that the UE is ensured that the algorithm selection was not manipulated, i.e. that the UE security capabilities were not bidden down.
The UE security capabilities the ME sent to the network shall be repeated in an integrity protected NAS level message to the ME such that "bidding down attacks" against the UE's security capabilities can be detected by the ME. The UE security capabilities apply to both AS and NAS level security.
Separate AS and NAS level security mode command procedures are required. AS level security mode command procedure shall configure AS security (RRC and UP) and NAS level security mode command procedure shall configure NAS security.
1. Both integrity protection and ciphering for RRC shall be activated within the same AS SMC procedure, but not necessarily within the same message.
2. User plane ciphering shall be activated at the same time as RRC ciphering.
3. For Relay Node (RN), user plane integrity shall be activated at the same time as RRC ciphering. For normal UE, user plane integrity shall be activated during the RRC Connection Reconfiguration procedure . User plane integrity shall be applied to a data radio bearer if integrity protection is configured for that data radio bearer at the time of data radio bearer set-up.
It shall be possible that the selected AS and NAS algorithms are different at a given point of time.
The same integrity algorithm shall be used for both RRC integrity protection and UP integrity protection.
The same ciphering algorithm shall be used for both RRC ciphering and UP ciphering.

7.2.4.2 Procedures for AS algorithm selection p. 35

7.2.4.2.1 Initial AS security context establishment p. 35

Each eNB shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for integrity algorithms, and one for ciphering algorithms. These lists shall be ordered according to a priority decided by the operator. When AS security context is established in the eNB, the MME shall send the UE EPS security capabilities to the eNB. The eNB shall choose the ciphering algorithm which has the highest priority from its configured list and is also present in the UE EPS security capabilities. The eNB shall choose the integrity algorithm which has the highest priority from its configured list and is also present in the UE EPS security capabilities. The chosen algorithms shall be indicated to the UE in the AS SMC. The ciphering algorithm is used for ciphering of the user plane and RRC traffic. The integrity algorithm is used for integrity protection of the RRC traffic, and, if applicable, for the integrity protection of user plane traffic between RN and DeNB and between UE and eNB.

7.2.4.2.2 X2-handover p. 35

At handover from a source eNB over X2 to a target eNB, the source eNB shall include the UE EPS security capabilities and ciphering and integrity algorithms used in the source cell in the handover request message. The target eNB shall select the algorithm with highest priority from the UE EPS security capabilities according to the prioritized locally configured list of algorithms (this applies for both integrity and ciphering algorithms). The chosen algorithms shall be indicated to the UE in the handover command if the target eNB selects different algorithms compared to the source eNB. If the UE does not receive any selection of integrity and ciphering algorithms it continues to use the same algorithms as before the handover (see TS 36.331). In the path-switch message, the target eNB shall send the UE EPS security capabilities received from the source eNB to the MME. The MME shall verify that the UE EPS security capabilities received from the eNB are the same as the UE EPS security capabilities that the MME has stored. If there is a mismatch, the MME shall send its locally stored UE EPS security capabilities to the target eNB in the response to the path-switch message. In addition, the MME may log the event and may take additional measures, such as raising an alarm. If the target eNB receives UE EPS security capabilities from the MME, the target eNB shall update the AS security context of the UE with these UE EPS security capabilities. The target eNB shall select the algorithm with highest priority from these UE EPS security capabilities according to the locally configured prioritized list of algorithms (this applies for both integrity and ciphering algorithms). If the algorithms selected by the eNB are different from the algorithms currently used at the target eNB, then the target eNB may take the proper actions to change to the selected algorithms.

7.2.4.2.3 S1-handover p. 35

At handover from a source eNB to a target eNB over S1 (possibly including an MME change and hence a transfer of the UE security capabilities from source MME to target MME), the target MME shall send the UE EPS security capabilities to the target eNB in the S1 AP HANDOVER REQUEST message. The target eNB shall select the algorithm with highest priority from the UE EPS security capabilities according to the prioritized locally configured list of algorithms (this applies for both integrity and ciphering algorithms). The chosen algorithms shall be indicated to the UE in the handover command if the target eNB selects different algorithms compared to the source eNB. If the UE does not receive any selection of integrity and ciphering algorithms it continues to use the same algorithms as before the handover (see TS 36.331).

7.2.4.2.4 Intra-eNB handover p. 36

It is not required to change the AS security algorithm during intra-eNB handover. If the UE does not receive any selection of new AS security algorithms during an intra-eNB handover, the UE continues to use the same algorithms as before the handover (see TS 36.331).

7.2.4.3 Procedures for NAS algorithm selection p. 36

7.2.4.3.1 Initial NAS security context establishment p. 36

Each MME shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for NAS integrity algorithms, and one for NAS ciphering algorithms. These lists shall be ordered according to a priority decided by the operator.

To establish the NAS security context, the MME shall choose one NAS ciphering algorithm and one NAS integrity protection algorithm. The MME shall then initiate a NAS security mode command procedure, and include the chosen algorithms and UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the message to the UE (see clause 7.2.4.4). The MME shall select the NAS algorithms which have the highest priority according to the ordered lists.

7.2.4.3.2 MME change p. 36

In case there is change of MMEs and algorithms to be used for NAS, the target MME shall initiate a NAS security mode command procedure and include the chosen algorithms and the UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the message to the UE (see clause 7.2.4.4). The MME shall select the NAS algorithms which have the highest priority according to the ordered lists (see clause 7.2.4.3.1).

7.2.4.4 NAS security mode command procedure p. 36

The NAS SMC procedure consists of a roundtrip of messages between MME and UE. The MME sends the NAS Security Mode Command to the UE and the UE replies with the NAS Security Mode Complete message. The primary purpose of the NAS SMC procedure is to securely establish a NAS security context between the UE and MME.

The NAS Security Mode Command message from MME to UE shall contain the replayed UE security capabilities, the selected NAS algorithms, the eKSI for identifying KASME, and both NONCEUE and NONCEMME in the case of creating a mapped context in idle mobility (see clause 9.1.2). The replayed UE security capabilities shall include the UE NR security capabilities if the MME understands the UE NR security capabilities and received them from the UE In the case of sending a NAS Security Mode Command during an Attach or TAU procedure (i.e. after receiving the Attach/TAU Request but before sending a response to that message) where the relevant Request message either did not have an integrity protection or did not successfully pass its integrity protection, the MME shall calculate a HASHMME of the entire plain Request message and include the HASHMME in the NAS security mode command message. The MME shall calculate HASHMME as decribed in Annex I.2. This message shall be integrity protected (but not ciphered) with NAS integrity key based on KASME indicated by the eKSI in the message (see Figure 7.2.4.4-1).

The UE shall verify the integrity of the NAS Security Mode Command message. This includes ensuring that the UE security capabilities sent by the MME match the ones stored in the UE to ensure that these were not modified by an attacker. If the UE NR security capabilities are not included, the UE shall not consider this a mismatch of security capabilities. The verification also includes checking the integrity protection using the indicated NAS integrity algorithm and the NAS integrity key based on KASME indicated by the eKSI. In addition, when creating a mapped context for the case described in clause 9.1.2, the UE shall ensure the received NONCEUE is the same as the NONCEUE sent in the TAU Request and also calculate K'ASME from CK, IK and the two nonces (see Annex A.11).

In addition if the NAS Security Mode Command message includes a HASHMME, the UE shall compare HASHUE with HASHMME. The UE shall calculate HASHUE as described in Annex I.2 from the entire plain Attach Request or TAU Request that it sends.

If the MME receives no response to a NAS Security Mode Command that included nonces to create a mapped context and it wishes to try again to create the mapped context, the MME shall use the same values of NONCEUE and NONCEMME.

If the UE receives a re-transmitted NAS Security Mode Command, i.e one containing the nonces, after it has successfully received a previous one (and hence created a mapped EPS NAS security context), the UE shall process the message as above, except that it is not required to re-generate the K'ASME or check the NONCE UE if it does not re-generate the K'ASME.

If the checks of the NAS Security Mode Command pass the UE shall respond with a NAS Security Mode Complete.

The UE shall delete NONCE_UE once the TAU procedure is complete.

If successfully verified, the UE shall start NAS integrity protection and ciphering/deciphering with this security context and sends the NAS security mode complete message to MME ciphered and integrity protected The NAS Security Mode Complete message shall include IMEISV in case MME requested it in the NAS Security Mode Command message. In addition if HASHUE and HASHMME are different, the UE shall include the complete Attach/TAU Request message (that the UE previously sent) in the NAS SecurityMode Complete message.

The MME shall de-cipher and check the integrity protection on the NAS Security Mode Complete using the keys and algorithms indicated in the NAS Security Mode Command. NAS downlink ciphering at the MME with this security context shall start after receiving the NAS Security Mode Complete message. NAS uplink deciphering at the MME with this context starts after sending the NAS Security Mode Command message. If the NAS Security Mode Complete message contains an Attach/TAU Request message, the MME shall complete the on-going Attach/TAU procedure by considering the contained Attach/TAU Request message as the message that triggered the procedure.

If any verification of the NAS Security Mode Command is not successful in the ME, the ME shall reply with a NAS Security Mode Reject message (see TS 24.301). The NAS Security Mode Reject message and all following NAS messages shall be protected with the EPS NAS security context, i.e., the EPS NAS security context used prior to the NAS Security Mode Command that failed (until a new EPS NAS security context is established, e.g., via a new NAS security mode command procedure). If no EPS NAS security context existed prior to the NAS Security Mode Command, the NAS Security Mode Reject message cannot be protected.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. 7.2.4.4-1: NAS Security Mode Command procedure

Figure 7.2.4.4-1: NAS Security Mode Command procedure
(⇒ copy of original 3GPP image)

7.2.4.5 AS security mode command procedure p. 38

The AS SMC procedure consists of a roundtrip of messages between eNB and UE. The eNB sends the AS security mode command to the UE and the UE replies with the AS security mode complete message. See Figure 7.2.4.5-1.

The AS security mode command message from eNB to UE shall contain the selected AS algorithms. This message shall be integrity protected with RRC integrity key based on the current KASME.

The AS security mode complete message from UE to eNB shall be integrity protected with the selected RRC algorithm indicated in the AS security mode command message and RRC integrity key based on the current KASME.

RRC and UP downlink ciphering (encryption) at the eNB shall start after sending the AS security mode command message. RRC and UP uplink deciphering (decryption) at the eNB shall start after receiving and successful verification of the AS security mode complete message.

RRC and UP uplink ciphering (encryption) at the UE shall start after sending the AS security mode complete message. RRC and UP downlink deciphering (decryption) at the UE shall start after receiving and successful verification of the AS security mode command message

If any control of the AS security mode command is not successful in the ME, the ME shall reply with an unprotected security mode failure message (see TS 36.331).

AS security mode command always changes the AS keys.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. 7.2.4.5-1: AS security setup

Figure 7.2.4.5-1: AS security setup
(⇒ copy of original 3GPP image)

7.2.4a Algorithm negotiation for unauthenticated UEs in LSM |R9| p. 39

UEs that are in limited service mode (LSM) and that cannot be authenticated by the MME (for whatever reason) may still be allowed to establish emergency calls by sending the emergency attach request message. It shall be possible to configure whether the MME allows unauthenticated UEs in LSM to establish bearers for emergency calls or not. If an MME allows unauthenticated UEs in LSM to establish bearers for an emergency call, the MME shall for the NAS protocol use EIA0 and EEA0 as the integrity and ciphering algorithm respectively.

If the MME allows an unauthenticated UE in LSM to establish bearers for emergency calls after it has received the emergency attach request message from the UE, the MME shall:

Select EIA0 and EEA0, regardless of the supported algorithms announced previously by the UE as the NAS algorithms and signal this to the UE via the NAS security mode command procedure when activating the EPS NAS security context.
Set the UE EPS security capabilities to only contain EIA0 and EEA0 when sending these to the eNB in the following messages:
- S1 UE INITIAL CONTEXT SETUP
- S1 UE CONTEXT MODIFICATION REQUEST
- S1 HANDOVER REQUEST

The rules for when the MME shall select EIA0 for NAS integrity protection, and when the UE shall accept a NAS security mode command selecting EIA0 for NAS integrity protection depends on whether the UE and MME can be certain that no EPS NAS security context can be established. The rules for determining this is defined in clause 15 of this specification. If the MME has selected EIA0 as the NAS integrity protection algorithm, the UE shall accept selection of EIA0 as the AS integrity protection algorithm. Selection of AS integrity protection algorithm happens via the AS security mode command procedure or via a handover command. The UE shall under no other circumstances accept selection of EIA0 as the AS integrity protection algorithm.