Content for  TS 33.401  Word version:  18.1.0

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.

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.

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.

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.