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…

 

7.2.5  Key handling at state transitions to and away from EMM-DEREGISTEREDp. 40

7.2.5.1  Transition to EMM-DEREGISTEREDp. 40

There are different reasons for transition to the EMM-DEREGISTERED state. If a NAS messages leads to state transition to EMM-DEREGISTERED, it shall be security protected by the current EPS NAS security context (mapped or native), if such exists in the UE or MME.
On transitioning to EMM-DEREGISTERED, the UE and MME shall do the following:
  1. If they have a full non-current native EPS NAS security context and a current mapped EPS NAS security context, then they shall make the non-current native EPS NAS security context the current one.
  2. They shall delete any mapped or partial EPS NAS security contexts they hold.
Handling of the remaining authentication data for each of these cases are given below:
  1. Attach reject: All authentication data shall be removed from the UE and MME
  2. Detach:
    1. UE-initiated
      1. If the reason is switch off then all the remaining authentication data shall be removed from the UE and MME with the exception of:
        • the current native EPS NAS security context (as in clause 6.1.1), which should remain stored in the MME and UE, and
        • any unused authentication vectors, which may remain stored in the MME.
      2. If the reason is not switch off then MME and UE shall keep all the remaining authentication data.
    2. MME-initiated
      1. Explicit: all the remaining authentication data shall be kept in the UE and MME if the detach type is re-attach.
      2. Implicit: all the remaining authentication data shall be kept in the UE and MME.
    3. HSS-initiated: If the message is "subscription withdrawn" then all the remaining authentication data shall be removed from the UE and MME.
  3. TAU reject: There are various reasons for TAU reject. The action to be taken shall be as given in TS 24.301.
Storage of the full native EPS NAS security context, excluding the UE security capabilities and the keys KNASint and KNASenc, in the UE when the UE transitions to EMM-DEREGISTERED state is done as follows:
  1. If the ME does not have a full native EPS NAS security context in volatile memory, any existing native EPS NAS security context stored on the UICC or in non-volatile memory of the ME shall be marked as invalid.
  2. If the USIM supports EMM parameters storage, then the ME shall store the full native EPS NAS security context parameters on the USIM (except for KNASenc and KNASint), mark the native EPS NAS security context on the USIM as valid, and not keep any native EPS NAS security context in non-volatile ME memory.
  3. If the USIM does not support EMM parameters storage, then the ME shall store the full native EPS NAS security context (except for KNASenc and KNASint) in a non-volatile part of its memory, and mark the native EPS NAS security context in its non-volatile memory as valid.
For the case that the MME or the UE enter EMM-DEREGISTERED state without using any of the above procedures, the handling of the remaining authentication data shall be as specified in TS 24.301.
Up

7.2.5.2  Transition away from EMM-DEREGISTEREDp. 41

7.2.5.2.1  Generalp. 41
When starting the transition away from EMM-DEREGISTERED state with the intent to eventually transitioning to EMM-REGISTERED state, if no current EPS NAS security context is available in the ME, the ME shall retrieve native EPS NAS security context stored on the USIM if the USIM supports EMM parameters storage and if the stored native EPS NAS security context on the USIM is marked as valid. If the USIM does not support EMM parameters storage the ME shall retrieve stored native EPS NAS security context from its non-volatile memory if the native EPS NAS security context is marked as valid. The ME shall derive the KNASint and KNASenc after retrieving the stored EPS NAS security context; see clause A.7 on NAS key derivation. The retrieved native EPS NAS security context with the derived KNASint and KNASenc shall then become the current EPS NAS security context.
When the ME is transitioning away from EMM-DEREGISTERED state with the intent to eventually transitioning to EMM-REGISTERED state, if the USIM supports EMM parameters storage, the ME shall mark the stored EPS NAS security context on the USIM as invalid. If the USIM does not support EMM parameters storage, the ME shall mark the stored EPS NAS security context in its non-volatile memory as invalid.
If the ME uses an EPS NAS security context to protect NAS messages, the NAS COUNT values are updated in the volatile memory of the ME. If the attempt to transition away from EMM-DEREGISTERED state with the intent to eventually transitioning to EMM-REGISTERED state fails, the ME shall store the (possibly updated) EPS NAS security context on the USIM or non-volatile ME memory and mark it as valid.
When the UE transits from EMM-DEREGISTERED to EMM-REGISTERED/ECM-CONNECTED, there are two cases to consider, either a full native EPS NAS security context exists, or it does not.
Up
7.2.5.2.2  With existing native EPS NAS security contextp. 41
The UE shall transmit a NAS Attach Request message. This message is integrity protected and for the case that the EPS NAS security context used by the UE is non-current in the MME, the rules in clause 6.4 apply. Furthermore provided there is no NAS SMC procedure before the AS SMC the NAS COUNT of the Attach Request message shall be used to derive the KeNB with the KDF as specified in clause A.3. As a result of the NAS Attach Request, the eNB shall send an AS SMC to the UE to activate AS security. The KeNB used, is derived in the current EPS NAS security context.
When the UE receives the AS SMC without having received a NAS Security Mode Command after the Attach Request, it shall use the NAS COUNT of the Attach Request message (i.e. the uplink NAS COUNT) that triggered the AS SMC to be sent as freshness parameter in the derivation of the KeNB. From this KeNB the RRC protection keys and the UP protection keys shall be derived as described in clause 7.2.1.
The same procedure for refreshing KeNB can be used regardless of the fact if the UE is connecting to the same MME to which it was connected previously or to a different MME. In case UE connects to a different MME and this MME selects different NAS algorithms, the NAS keys have to be re-derived in the MME with the new algorithm IDs as input using the KDF as specified in clause A.7.
In addition, there is a need for the MME to send a NAS SMC to the UE to indicate the change of NAS algorithms and to take the re-derived NAS keys into use. The UE shall assure that the NAS keys used to verify the integrity of the NAS SMC are derived using the algorithm ID specified in the NAS SMC. The NAS SMC Command and NAS SMC Complete messages are protected with the new NAS keys.
If there is a NAS Security Mode Command after the Attach Request but before the AS SMC, the UE and MME use the NAS COUNT of the most recent NAS Security Mode Complete (i.e. the uplink NAS COUNT) and the related KASME as the parameter in the derivation of the KeNB. From this KeNB the RRC protection keys and the UP protection keys are derived as described in clause 7.2.1.
Up
7.2.5.2.3  With run of EPS AKAp. 42
If in the process described in clause 7.2.5.2.2, there is no full native EPS NAS security context available in the MME (i.e. either the UE has sent an unprotected Attach Request message or the UE has protected the Attach Request message with a current native EPS security context which no longer is stored in the MME) an EPS AKA run is required. If there is a full native EPS NAS security context available in the MME, then the MME may (according to MME policy) decide to run a new EPS AKA and a NAS SMC procedure (which activates the new EPS NAS security context based on the KASME derived during the EPS AKA run) after the Attach Request but before the corresponding AS SMC. The NAS (uplink and downlink) COUNTs are set to start values, and the start value of the uplink NAS COUNT shall be used as freshness parameter in the KeNB derivation from the fresh KASME (after AKA) when UE receives AS SMC the KeNB is derived from the current EPS NAS security context, i.e., the fresh KASME is used to derive the KeNB The KDF as specified in clause A.3 shall be used to derive the KeNB.
The NAS SMC complete message shall include the start value of the uplink NAS COUNT that is used as freshness parameter in the KeNB derivation and the KASME is fresh. After an AKA, a NAS SMC needs to be sent from the MME to the UE in order to take the new NAS keys into use. Both NAS SMC and NAS SMC Complete messages are protected with the new NAS keys.
Up

7.2.6  Key handling in ECM-IDLE to ECM-CONNECTED and ECM-CONNECTED to ECM-IDLE transitionsp. 42

7.2.6.1  ECM-IDLE to ECM-CONNECTED transitionp. 42

The UE sends an initial NAS message to initiate transition from ECM-IDLE to ECM-CONNECTED state [9]. On transitions to ECM-CONNECTED, the MME should be able to check whether a new authentication is required, e.g. because of prior inter-provider handover.
When cryptographic protection for radio bearers is established RRC protection keys and UP protection keys shall be generated as described in clause 7.2.1 while KASME is assumed to be already available in the MME.
The initial NAS message shall be integrity protected by the current EPS NAS security context if such exists. If no current EPS NAS security context exists the ME shall signal "no key available" in the initial NAS message.
KASME may have been established in the MME as a result of an AKA run, or as a result of a security context transfer from another MME during handover or idle mode mobility. When the eNB releases the RRC connection the UE and the eNB shall delete the keys they store such that state in the network for ECM-IDLE state UEs will only be maintained in the MME.
Up

7.2.6.2  Establishment of keys for cryptographically protected radio bearersp. 42

The procedure the UE uses to establish cryptographic protection for radio bearers is initiated by an (extended) NAS Service Request message or TAU Request message with the active flag set from the UE to the MME. The MME may initiate the procedure to establish cryptographic protection for radio bearers when the "active flag" is not set in the TAU request and there is pending downlink UP data or pending downlink signalling.
Upon receipt of the NAS message, if the MME does not require a NAS SMC procedure before initiating the S1-AP procedure INITIAL CONTEXT SETUP, the MME shall derive key KeNB as specified in clause A.3 using the NAS COUNT [9] corresponding to the NAS message and the KASME of the current EPS NAS security context. The MME shall further initialize the value of the Next hop Chaining Counter (NCC) to zero. The MME shall further derive a next hop parameter NH as specified in clause A.4 using the newly derived KeNB and the KASME as basis for the derivation. The MME shall further set the the value of the Next hop Chaining Counter (NCC) to one. This fresh {NH, NCC=1} pair shall be stored in the MME and shall be used for the next forward security key derivation. The MME shall communicate the KeNB to the serving eNB in the S1-AP procedure INITIAL CONTEXT SETUP. The UE shall derive the KeNB from the KASME of the current EPS NAS security context.
As a result of the (extended) NAS Service Request or TAU procedure, radio bearers are established, and the eNB sends an AS SMC to the UE. When the UE receives the AS SMC without having received a NAS Security Mode Command, it shall use the NAS uplink COUNT of the NAS message that triggered the AS SMC as freshness parameter in the derivation of the KeNB. The KDF as specified in Annex A.3 shall be used for the KeNB derivation using the KASME of the current EPS NAS security context. The UE shall further derive the NH parameter from the newly derived KeNB and the KASME in the same way as the MME. From the KeNB the RRC protection keys and the UP protection keys are derived by the UE and the eNB as described in clause 6.2.
If the NAS procedure establishing radio bearers contains an EPS AKA run (which is optional), the NAS uplink and downlink COUNT for the new KASME shall be set to the start values (i.e. zero). If the NAS procedure establishing radio bearers contains a NAS SMC (which is optional), the value of the uplink NAS COUNT from the most recent NAS Security Mode Complete shall be used as freshness parameter in the KeNB derivation from fresh KASME of the current EPS NAS security context when executing an AS SMC. The KDF as specified in Annex A.3 shall be used for the KeNB derivation also in this case.
The case that the UE is using Control Plane CIoT EPS optimisation to send data over NAS and S1-U bearers are established (due to either a request from the UE or decided by the MME - see clause 5.3.4B.3 of TS 23.401) works as follows. The UE and MME shall always use the value of the uplink NAS COUNT from the Control Plane Service Request that was sent to transition the UE from idle to active as freshness parameter in the derivation of the KeNB unless there has been a subsequent NAS Security Mode Complete. If there was a subsequent NAS Security Mode Complete, then the UE and MME use the value of the uplink NAS COUNT from the latest NAS Security Mode Complete message as freshness parameter in the derivation of the KeNB.
Up

7.2.6.3  ECM-CONNECTED to ECM-IDLE transitionp. 43

On ECM-CONNECTED to ECM-IDLE transitions the eNB does no longer need to store state information about the corresponding UE.
In particular, on ECM-CONNECTED to ECM-IDLE transitions:
  • The eNB and the UE shall release all radio bearers and delete the AS security context.
  • MME and the UE shall keep the EPS NAS security context stored with the following exception: if there is a new and an old KASME according to rules 3, 4, 8 or 9 in clause 7.2.10 of this specification then the MME and the UE shall delete the old KASME and the corresponding eKSI. The MME shall delete NH and NCC.
Up

7.2.7  Key handling for the TAU procedure when registered in E-UTRANp. 43

Before the UE can initiate the TAU procedure, the UE needs to transition to ECM-CONNECTED state. The UE shall use the current EPS security context to protect the TAU Request and include the corresponding GUTI and eKSI value. The TAU Request shall be integrity-protected, but not confidentiality-protected. UE shall use the current EPS security context algorithms to protect the TAU Request message. For the case that this security context is non-current in the MME, the rules in clause 6.4 apply.
If the "active flag" is set in the TAU request message or the MME chooses to establish radio bearers when there is pending downlink UP data or pending downlink signalling, radio bearers will be established as part of the TAU procedure and a KeNB derivation is necessary.If there was no subsequent NAS SMC, the uplink NAS COUNTof the TAU request message sent from the UE to the MME is used as freshness parameter in the KeNB derivation using the KDF as specified in clause A.3. The TAU request shall be integrity protected.
In the case an AKA is run successfully, the uplink and downlink NAS COUNT shall be set to the start values (i.e. zero).
In the case source and target MME use different NAS algorithms, the target MME re-derives the NAS keys from KASME with the new algorithm identities as input and provides the new algorithm identifiers within a NAS SMC. The UE shall assure that the NAS keys used to verify the integrity of the NAS SMC are derived using the algorithm identity specified in the NAS SMC.
If there is a NAS Security Mode Command after the TAU Request but before the AS SMC, the UE and MME use the NAS COUNT of the most recent NAS Security Mode Complete (i.e. the uplink NAS COUNT) and the related KASME as the parameter in the derivation of the KeNB. From this KeNB the RRC protection keys and the UP protection keys are derived as described in clause 7.2.1.
Up

Up   Top   ToC