Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑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… 
9 Security interworking between E-UTRAN and UTRAN  9.1 RAU and TAU procedures  9.2 Handover  9.3 Recommendations on AKA at IRAT-mobility to E-UTRAN  9.4 Attach procedures 
...

 

9  Security interworking between E-UTRAN and UTRAN  p. 61

9.1  RAU and TAU procedures  p. 61

9.1.1  RAU procedures in UTRAN  p. 61

This clause covers both the cases of idle mode mobility from E-UTRAN to UTRAN and of Idle Mode Signaling Reduction (ISR), as defined in TS 23.401.
Use of an existing UMTS security context
If the UE sends the RAU Request with the "old P-TMSI" Information Element including a valid P-TMSI it shall also include the KSI relating to this P-TMSI. This KSI is associated with the UMTS security context stored on the UE, and it indicates this fact to the SGSN. In this case the UE shall include P-TMSI signature into the RAU Request if a P-TMSI signature was assigned by the old SGSN. If the network does not have a valid security context for this KSI it shall run AKA. In case of an SGSN change keys from the old SGSN shall overwrite keys in the new SGSN if any.
Mapping of EPS security context to UMTS security context
If the UE sends the RAU Request with the "old P-TMSI" Information Element including mapped GUTI it shall also include the KSI equal to the value of the eKSI associated with the current EPS security context (cf. clause 3). The UE shall include a truncated NAS-token, as defined in this clause further below, into the P-TMSI signature IE. The MME shall transfer UE's UTRAN and GERAN security capabilities and CK' || IK' with KSI equal to the value of the eKSI associated with the current EPS security context to SGSN with Context Response/SGSN Context Response message. The MME and UE shall derive CK' and IK' from the KASME and the NAS uplink COUNT value corresponding to the truncated NAS-token received by the MME from SGSN as specified in clause A.13. Keys CK' and IK' and KSI sent from the MME shall replace all the UTRAN PS key parameters CK, IK, s KSI in the target SGSN if any. Keys CK' and IK' and the KSI shall replace all the currently stored UTRAN PS key parameters CK, IK, KSI values on both USIM and ME. The handling of STARTPS shall comply with the rules in TS 25.331. The UE may set the STARTPS value to 0 if it is done before establishment of the RRC connection.
The ME shall use CK' and IK' to derive the GPRS Kc using the c3 function specified in TS 33.102. The ME shall assign the eKSI value (associated with CK' and IK') to the GPRS CKSN. The ME shall update the USIM and ME with the new GPRS Kc and GPRS CKSN.
SGSN shall include the allowed security algorithm and transfer them to RNC. An SMC shall be sent to the UE containing the selected algorithms.
The 16 least significant bits available in the P-TMSI signature field shall be filled with the truncated NAS-token according to TS 23.003.The truncated NAS-token is defined as the 16 least significant bits of the NAS-token.
The NAS-token is derived as specified in Annex A.9. The UE shall use the uplink NAS COUNT value that it would use in the next NAS message to calculate the NAS-token and increase the stored uplink NAS COUNT value by 1.
SGSN shall forward the P-TMSI signature including the truncated NAS token to the old MME, which compares the received bits of the truncated NAS-token with the corresponding bits of a NAS-token generated in the MME, for the UE identified within the context request. If they match, the context request message is authenticated and authorized and MME shall provide the needed information for the SGSN. Old MME shall respond with an appropriate error cause if it does not match the value stored in the old MME. This should initiate the security functions in the new SGSN.
To avoid possible race condition problems, the MME shall compare the received truncated NAS-token with the 16 least significant bits of NAS-tokens generated from the current NAS uplink COUNT value up to current NAS uplink COUNT value +L, i.e. the interval [current NAS uplink COUNT, current NAS uplink COUNT+L]. A suitable value for the parameter L can be configured by the network operator. MME shall not accept the same NAS-token for the same UE twice except in retransmission cases happening for the same mobility event. If the MME finds a match, it shall set the stored uplink NAS COUNT value as though it had successfully received an integrity protected NAS message with the uplink NAS COUNT value that created the match.
Up

9.1.2  TAU procedures in E-UTRAN  p. 62

This clause covers both the cases of idle mode mobility from UTRAN to E-UTRAN and of Idle Mode Signaling Reduction, as defined in TS 23.401.
The TAU Request and ATTACH Request message shall include the UE security capabilities. The MME shall store these UE security capabilities for future use. The MME shall not make use of any UE security capabilities received from the SGSN.
In this procedure, the START values shall be kept in the volatile memory of the ME, cf. also clause 6.8.11 of TS 33.102.
Case 1: P-TMSI not included in "old GUTI" IE in TAU Request
This case is identical to that described in clause 7.2.7.
Case 2: Mapped P-TMSI included in "old GUTI" IE in TAU Request
The UE shall include in the TAU Request:
  • the KSI with corresponding P-TMSI and old RAI to point to the right source SGSN and key set there. This allows the UE and MME to generate the mapped EPS NAS security context, as described below, if current EPS NAS security context is not available in the UE and network. The KSI shall correspond to the set of keys most recently generated (either by a successful UMTS AKA run in UTRAN (which may or may not yet have been taken into use by the UE and SGSN) or a UMTS security context mapped from an EPS NAS security context during a previous visit in UTRAN).
  • a P-TMSI signature, if the UE was previously connected to UTRAN where the SGSN assigned a P-TMSI signature to the UE
  • a 32bit NONCEUE (see clause A.11 for requirements on the randomness of NONCEUE).
If the UE has a current EPS NAS security context, then it shall include the corresponding eKSI value and if it exists, the corresponding GUTI, in the TAU Request. If the UE includes the eKSI, but not the corresponding GUTI, the MME may treat the TAU request as if the EPS NAS security context did not exist. The TAU Request shall be integrity-protected, but not confidentiality-protected. The UE shall use the current EPS NAS security context algorithms to protect the TAU Request message.
If a current EPS NAS security context is not available in the UE, the UE shall send the TAU request unprotected.
If the MME received a P-TMSI signature from the UE, the MME shall include that P-TMSI signature in the Context Request message sent to the SGSN. The SGSN shall transfer CK || IK to MME in the Context Response/SGSN Context Response message. In case the MM context in the Context Response/SGSN Context Response indicates GSM security mode, the MME shall abort the procedure.
In case the TAU Request was protected and the MME has the indicated EPS NAS security context it shall verify the TAU Request message. If it is successful, the UE and the MME share a current EPS NAS security context. In case the TAU Request had the active flag set or the MME chooses to establish radio bearers when there is pending downlink UP data or pending downlink signalling, KeNB is calculated as described in clause 7.2.7.
If the MME wants to change the algorithms, the MME shall use a NAS security mode procedure (see clause 7.2.4.4).
If the MME does not have the EPS NAS security context indicated by the eKSI by the UE in the TAU request, or the TAU request was received unprotected, the MME shall create a new mapped EPS NAS security context (that shall become the current EPS NAS security context). In this case, the MME shall generate a 32bit NONCEMME (see clause A.10 for requirements on the randomness of NONCEMME). and use the received NONCEUE with the NONCEMME to generate a fresh mapped K'ASME from CK and IK, where CK, IK were identified by the KSI and P-TMSI in the TAU Request. See Annex A.11 for more information on how to derive the fresh K'ASME. The MME initiates a NAS Security mode command procedure with the UE as described in clause 7.2.4.4 including the KSISGSN, NONCEUE, and NONCEMME in the NAS Security mode command. The uplink and downlink NAS COUNT for mapped EPS NAS security context shall be set to start value (i.e., 0) when new mapped EPS NAS security context is created in UE and MME.
If the TAU Request had the active flag set or the MME chooses to establish radio bearers when there is pending downlink UP data or pending downlink signalling, the uplink NAS Count which is set to zero shall be used to derive the KeNB in MME and UE as specified in clause A.3. MME shall deliver the KeNB to the target eNB on the S1 interface.
The TAU Accept shall be protected using the current EPS NAS security context.
Up

9.2  Handover  p. 63

9.2.1  From E-UTRAN to UTRAN  p. 63

NAS and AS security shall always be activated before handover from E-UTRAN to UTRAN can take place. Consequently the source system in the handover shall always send a key set to the target system during handover. The security policy of the target PLMN determines the selected algorithms to be used within the UTRAN HO command.
The MME shall select the current NAS downlink COUNT value to use in the handover and then increase the stored NAS downlink COUNT value by 1.
UE and MME shall derive a confidentiality key CK', and an integrity key IK' from the KASME and the selected NAS downlink COUNT value of the current EPS key security context with the help of a one-way key derivation function KDF as specified in clause A.8.
Whether UTRAN PS key ciphering is considered active in the target UTRAN after handover from E-UTRAN shall be determined according to the principles for handover to UTRAN in TS 25.331.
UE and MME shall assign the value of eKSI to KSI. MME shall transfer CK' || IK' with KSI to SGSN. The target SGSN shall replace all stored parameters CK, IK, KSI, if any, with CK' , IK', KSI received from the MME. The UE shall replace all stored parameters CK, IK, KSI, if any, with CK' , IK', KSI in both ME and USIM. STARTPS shall comply with the rules in TS 25.331. The ME shall use CK' and IK' to derive the GPRS Kc using the c3 function specified in TS 33.102. The ME shall assign the eKSI value (associated with CK' and IK') to the GPRS CKSN. The ME shall update the USIM and ME with the GPRS Kc and GPRS CKSN.
After HO from E-UTRAN to UTRAN the current EPS NAS security context shall (if it is kept ) be considered as the current one in E-UTRAN in the UE and the MME.
MME shall also provide at least the 4 LSB of the selected NAS downlink COUNT value to the source eNB, which then shall include the bits in the MobilityFromE-UTRANCommand to the UE. The UE shall use the received 4 LSB and its stored NAS downlink COUNT to estimate the NAS downlink COUNT selected by the MME.
The UE shall ensure that the estimated NAS downlink COUNT has not been used to calculate a CK' and IK' in a previous successful or unsuccessful PS or SRVCC handover. If the estimated NAS downlink COUNT is greater than all the estimated NAS downlink COUNTs either used by the UE for key derivation in a handover or received in a NAS message that passed its integrity check, the UE shall update its stored NAS downlink COUNT as though it has successfully integrity checked a NAS message with that estimated NAS downlink COUNT. In particular, the stored NAS downlink COUNT shall never be decreased.
MME shall transfer the UE security capabilities to the SGSN. The selection of the algorithms in the target system proceeds as described in TS 33.102 for UTRAN.
If the handover is not completed successfully, the new mapped UMTS security context can not be used in the future. The SGSN shall delete the new mapped UMTS security context and the stored UMTS security context which has the same KSI as the new mapped UMTS security context.
Up

9.2.2  From UTRAN to E-UTRAN  p. 64

9.2.2.1  Procedure  p. 64

The procedure for handover from UTRAN to E-UTRAN, as far as relevant for security, proceeds in the following two consecutive steps:
  1. Handover signalling using the mapped EPS security context (cf. also Figure 9.2.2.1-1);
  2. Subsequent NAS signalling to determine whether a native EPS security context can be taken in use (not shown in Figure 9.2.2.1-1).
In this procedure, the START values shall be kept in the volatile memory of the ME, cf. also clause 6.8.11 of TS 33.102.
The activation of NAS and AS security in E-UTRAN, and selection of the key set from the source system for the handover shall be according to following principles:
  1. As described for inter-SGSN PS handover cases in TS 33.102, the source SGSN shall select the key set most recently generated (either by a successful UMTS AKA run in UTRAN (which may or may not yet have been taken into use by the UE and SGSN) or a UMTS security context mapped from an EPS security context during a previous visit to UTRAN) and transfer this key set to the MME in the Forward Relocation Request.
  2. Activation of AS security (for details cf. TS 36.331):
    The E-UTRAN HO command received at the UE shall activate AS security.
    The HO Complete received at the eNB shall activate AS security.
  3. Activation of NAS security (for details cf. TS 24.301):
    The E-UTRAN HO command received at the UE shall activate NAS security.
    The HO Notify received at the MME shall activate NAS security. In case the MME does not have the UE security capabilities stored from a previous visit, then no NAS message shall be sent or accepted by the MME other than a TAU request before a successful check of the UE security capabilities in the TAU request was performed by the MME.
  4. Both AS and NAS ciphering and integrity protection algorithms shall be selected according to the policy of the target PLMN.
The above four principles consequentially always activate ciphering (potentially NULL ciphering) in E-UTRAN even if it was not active in the source system.
Copy of original 3GPP image for 3GPP TS 33.401, Fig. 9.2.2.1-1: Handover from UTRAN to E-UTRAN
Figure 9.2.2.1-1: Handover from UTRAN to E-UTRAN
(⇒ copy of original 3GPP image)
Up
A) Handover signalling in case of successful handover
Before attempting a handover for a UE, the source RNC may check if the UE is authenticated using UMTS AKA. If the UE is not authenticated using UMTS AKA and the UE does not have an ongoing emergency call, then the source RNC may decide not to perform a handover to E-UTRAN (to avoid triggering unnecessary handover attempts to E-UTRAN which will be rejected by the target MME). The check can be performed by analysing the active CK and IK as follows:
  • If the 64 most significant bits of the CK are not identical to the 64 least significant bits of the CK, the RNC can deduce that the UE was authenticated via UMTS AKA. (The bits are identical if the CK is derived from a Kc via the c4 key conversion function [4], and it is very unlikely that they are equal for a CK derived from UMTS AKA.)
  • If the 64 most significant bits of the CK are identical to the 64 list significant bits of the CK, the RNC can further check if the IK fulfils the equation given by the c5 key conversion function [4]. If the IK does not fulfil this equation, the RNC can deduce that the UE was authenticated with UMTS AKA, and if the IK does, then the RNC can deduce that the UE was authenticated using GSM AKA.
If the source RNC does not conclude that the UE is authenticated using UMTS AKA, the source RNC may select an appropriate network for the UE at the handover decision stage and may send a Relocation Required message to the SGSN. This message does not contain any security-relevant parameters.
Step 1.
The SGSN shall transfer MM context (including CK and IK (or the Kc), KSI and the UE security capabilities) to MME in the Forward relocation request message. In case the MM context in the Forward relocation request message indicates GSM security mode(i.e., it contains a Kc), the MME shall abort the non-emergency call procedure. The UE security capabilities, including the UE EPS security capabilities, were sent by the UE to the SGSN via the UE Network Capability IE, in Attach Request and RAU Request. It is possible that an SGSN does not forward the UE EPS security capabilities to the MME. When the MME does not receive UE EPS security capabilities from the SGSN, the MME shall assume that the following default set of EPS security algorithms is supported by the UE (and shall set the UE EPS security capabilities in the mapped EPS NAS security context according to this default set):
  1. EEA0, 128-EEA1 and 128-EEA2 for NAS signalling ciphering, RRC signalling ciphering and UP ciphering;
  2. 128-EIA1 and 128-EIA2 for NAS signalling integrity protection and RRC signalling integrity protection.
Step 2.
The MME shall create a NONCEMME to be used in the K'ASME derivation (see clause A.10 for requirements on the randomness of NONCEMME).. MME shall derive K'ASME from CK and IK with the help of a one-way key derivation function as defined in clause A.10 and associate it with a Key Set Identifier KSISGSN. The value field of the KSISGSN shall be derived by assigning the KSI corresponding to the set of keys most recently generated (either by a successful UMTS AKA run in UTRAN (which may or may not yet have been taken into use by the UE and the SGSN) or a UMTS security context mapped from an EPS security context during a previous visit in UTRAN). MME shall derive KeNB from K'ASME using the key derivation function defined in clause A.3. The uplink and downlink NAS COUNT values for the mapped EPS security context shall be set to start value (i.e. 0) in the MME.
Step 3.
MME shall select the NAS security algorithms (including ciphering and integrity protection) which have the highest priority from its configured list and are also present in the UE EPS security capabilities, MME shall derive the NAS keys from K'ASME using the algorithm types and algorithm IDs as input to the NAS key derivation functions(see Annex A.7), MME shall include KSISGSN, NONCEMME , the selected NAS security algorithms in the NAS Security Transparent Container IE of S1 HO Request message to the target eNB. MME further shall include KeNB and the UE EPS security capabilities, either the capabilities received from the SGSN or, in the absence of these, the default set of EPS security algorithms, in the S1 HO Request message to the target eNB.
Step 4.
The target eNB shall select the AS algorithms (including ciphering for both RRC and UP, and integrity protection for RRC ) which have the highest priority from its configured list and is also present in the UE EPS security capabilities. The target eNB shall create a transparent container (RRCConnectionReconfiguration) including the selected RRC, UP algorithms and the NAS Security Transparent Container IE, and send it in the S1 HO Request Ack message towards the MME. The eNB shall derive the RRC and UP from KeNB using the key derivation function defined in clause A.7.
Step 5.
MME shall include the transparent container received from the target eNB in the FW Relocation Response message sent to SGSN.
Step 6.
SGSN shall include the transparent container in the relocation command sent to the RNC.
Step 7.
The RNC shall include the transparent container in the UTRAN HO command sent to the UE.
Step 8.
The UE shall derive K'ASME, associate it with KSISGSN and derive KeNB in the same way the MME did in step 2 The UE shall also derive the NAS key as the MME did in step 3 and the RRC and UP keys as the eNB did in step 4. The UE shall send a RRCConnectionReconfiguration Complete messages to the eNB. The uplink and downlink NAS COUNT values for the mapped EPS security context shall be set to start value (i.e. 0) in the UE.
Step 9.
The mapped EPS security context shall become the current (cf. clause 3.1) EPS security context at AS and NAS level and overwrite any existing current mapped EPS security context. If the current EPS security context is of type native, then it shall become the non-current native EPS security context and overwrite any existing non-current EPS security context. The HO Complete messages and all following AS messages in E-UTRAN shall be ciphered and integrity protected according to the policy of the target PLMN.
If the handover is not completed successfully, the new mapped EPS security context can not be used in the future. The MME shall delete the new mapped EPS security context.
B) Subsequent NAS signalling
In order to prevent that successful bidding down on the UE security capabilities in a previous RAT have an effect on the selection of EPS security algorithm for NAS and AS, the UE security capabilities shall be included in the TAU request after IRAT-HO and be verified by the MME.
In any case UE security capability information received from the UE overwrites any capabilities received with the context transfer as specified in TS 23.401.
It can happen that the MME receives different UE EPS security capabilities in the TAU Request from the already stored UE EPS security capabilities in MME (received from the source SGSN or the default UE EPS security capabilities when MME uses the default set of EPS security algorithms for the UE according to A) step 1 above). If it happens, the MME shall perform as follows:
  • In case the TAU Request contains a higher priority NAS algorithm (according to the priority list stored in the MME), the MME run a NAS security mode command procedure to change the NAS algorithms according to clause 7.2.4.4.
  • MME shall send an S1 CONTEXT MODIFICATION REQUEST message to inform the eNB about the correct UE EPS security capabilities.
The eNB shall trigger a change of AS algorithms if the received UE EPS security capabilities from the S1 CONTEXT MODIFICATION REQUEST message would contain higher priority AS algorithm (according to the priority list stored in the eNB).
Step 1.
If the MME has native security context for the UE and does not receive a TAU request within a certain period after the HO it shall assume that UE and MME share a native security context.
Step 2.
When the UE sends a TAU request it shall protect the request using the mapped EPS security context identified by KSISGSN. The UE shall also include KSIASME in the TAU request if and only if it has native EPS security context. The KSIASME shall be accompanied by a GUTI. When the MME receives a TAU request with a KSIASME and GUTI corresponding to the non-current native EPS security context stored on that MME it knows that UE and MME share a non-current native EPS security context.
Step 3.
Void.
Step 4.
When the MME receives a TAU request without a KSIASME it shall delete any non-current native EPS security context for any GUTI it may have for the user who sent the TAU request.
Step 5.
If the MME shares the non-current native EPS security context indexed by the KSIASME and GUTI from the TAU Request with the UE, the MME may run a NAS security mode command procedure with the UE to activate the non-current native EPS NAS security context according to clause 7.2.9.4. The MME may in addition change the KeNB on the fly according to clause 7.2.9.2. In case the GUTI received in the TAU Request message pointed to a different MME, the allocation of a new GUTI, replacing the received GUTI, and the association of this new GUTI with KSIASME is required.
Step 6.
Void.
Step 7.
When the MME knows, after having completed the TAU procedure in the preceding steps, that it shares a non-current native EPS security context with the UE, the MME may (depending on configured policy and if the MME did not do it already in step 5) activate this non-current native EPS security context. This activation may occur in three ways:
  1. When the UE has cryptographically protected radio bearers established: the MME shall initiate a key change on the fly procedure according to clause 7.2.9 for the entire EPS key hierarchy.
  2. After the next transition to ECM-IDLE state following the handover from UTRAN: Upon receiving the first message from the UE after the UE has gone to ECM-IDLE state the MME shall use the procedures defined in clauses 7.2.4.4 and 7.2.4.5 to activate the non-current native EPS security context if such exists.
  3. At the next transition to EMM-DEREGISTERED (see clause 7.2.5.1).
Step 8.
If a non-current native EPS security context has been established, then the UE and the MME shall delete the mapped EPS security context and set the non-current native EPS security context to the current EPS security context.
Step 9.
If the SN id changed during the IRAT handover, the MME shall delay authenticating the UE until after the network has concluded that the UE has received the TAU Accept message which contains the current SN id. Doing this ensures that the UE and the MME use the same SN id in the KASME derivation.
Up

9.2.2.2  Derivation of NAS keys and KeNB during Handover from UTRAN to E-UTRAN  p. 69

MME and UE shall derive the NAS keys from the mapped key K'ASME as specified in clause A.7.
The MME and UE shall derive KeNB by applying the KDF defined in Annex A.3 using the mapped key K'ASME and 232-1 as the value of the uplink NAS COUNT parameter.
Up

9.3  Recommendations on AKA at IRAT-mobility to E-UTRAN  p. 69

After a handover from GERAN or UTRAN into E-UTRAN, it is strongly recommended to run an AKA and perform a key change on-the-fly of the entire key hierarchy as soon as possible after the handover if there is no native security context in E-UTRAN.
When a UE moves in IDLE mode from GERAN or UTRAN into E-UTRAN, it is strongly recommended to run an AKA if there is no native security context in E-UTRAN, either after the TAU procedure that establishes an EPS security context in the MME and UE, or when the UE establishes cryptographically protected radio bearers.
Up

9.4  Attach procedures |R9|  p. 69

9.4.1  Attach in UTRAN  p. 69

This clause covers the case that the UE includes a mapped GUTI into the "old P-TMSI" Information Element of the Attach Request.
If the UE has a current EPS NAS security context, it shall include a truncated NAS-token, as defined in clause 9.1.1, into the P-TMSI signature IE of the Attach Request. It shall also include the KSI equal to the value of the eKSI associated with the current EPS security context.
If the UE does not have a current EPS NAS security context, the UE shall set the truncated NAS-token to all zero and the KSI to '111' to indicate the UE has no keys available.
The SGSN shall forward the P-TMSI signature including the truncated NAS-token to the old MME. The MME may check a non-zero NAS-token as described in clause 9.1.1. If successful, the MME responds with an Identification Response to the SGSN. If unsuccessful the MME responds with an appropriate error cause which should initiate the security functions in the SGSN.
If P-TMSI Signature includes an all zero NAS-token or the MME chooses not to check the NAS-token, the MME may respond with an Identification Response that does not include keys.
If needed, the MME and UE shall derive CK' and IK' from the KASME as in subclause 9.1.1. Keys CK' and IK' and KSI sent from the MME shall replace all the UTRAN PS key parameters CK, IK and KSI in the target SGSN if any. Keys CK' and IK' and the KSI shall replace all the currently stored UTRAN PS key parameters CK, IK, KSI values on both the USIM and ME. The handling of STARTPS shall comply with the rules in TS 25.331. The UE may set the STARTPS value to 0 if it is done before establishment of the RRC connection.
The ME shall use CK' and IK' to derive the GPRS Kc using the c3 function specified in TS 33.102. The ME shall assign the eKSI value (associated with CK' and IK') to the GPRS CKSN. The ME shall update the USIM and ME with the GPRS Kc and GPRS CKSN.
Up

Up   Top   ToC