Section: 4.4.2 Handling of EPS security contexts 4.4.2.1 General
Content: The security parameters for authentication, integrity protection and ciphering are tied together in an EPS security context and identified by a key set identifier for E-UTRAN (eKSI). The relationship between the security parameters is defined in 3GPP TS 33.401[ 3GPP System Architecture Evolution (SAE); Security architecture ]  [19]. Before security can be activated, the MME and the UE need to establish an EPS security context. Usually, the EPS security context is created as the result of an EPS authentication procedure between MME and UE. Alternatively: - during inter-system handover from A/Gb mode to S1 mode or from Iu mode to S1 mode, the MME and the UE derive a mapped EPS security context from a UMTS security context that has been established while the UE was in A/Gb mode or Iu mode; or - during CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode, the MME and the UE derive a mapped EPS security context from a CS UMTS security context that has been established while the UE was in A/Gb mode or Iu mode. The EPS security context is taken into use by the UE and the MME, when the MME initiates a security mode control procedure or during the inter-system handover procedure from A/Gb mode to S1 mode or Iu mode to S1 mode. The EPS security context which has been taken into use by the network most recently is called current EPS security context. This current EPS security context can be of type native or mapped, i.e. originating from a native EPS security context or mapped EPS security context. The key set identifier eKSI is assigned by the MME either during the EPS authentication procedure or, for the mapped EPS security context, during the inter-system handover procedure. The eKSI consists of a value and a type of security context parameter indicating whether an EPS security context is a native EPS security context or a mapped EPS security context. When the EPS security context is a native EPS security context, the eKSI has the value of KSIASME, and when the current EPS security context is of type mapped, the eKSI has the value of KSISGSN. The EPS security context which is indicated by an eKSI can be taken into use to establish the secure exchange of NAS messages when a new NAS signalling connection is established without executing a new EPS authentication procedure (see clause 4.4.2.3) or when the MME initiates a security mode control procedure. For this purpose the initial NAS messages (i.e. ATTACH REQUEST, TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE REQUEST, EXTENDED SERVICE REQUEST, and CONTROL PLANE SERVICE REQUEST) and the SECURITY MODE COMMAND message contain an eKSI in the NAS key set identifier IE or the value part of eKSI in the KSI and sequence number IE indicating the current EPS security context used to integrity protect the NAS message. In the present document, when the UE is required to delete an eKSI, the UE shall set the eKSI to the value "no key is available" and consider also the associated keys KASME or K'ASME, EPS NAS ciphering key and EPS NAS integrity key invalid (i.e. the EPS security context associated with the eKSI as no longer valid). NOTE: In some specifications the term ciphering key sequence number might be used instead of the term Key Set Identifier (KSI). The UE and the MME need to be able to maintain two EPS security contexts simultaneously, i.e. a current EPS security context and a non-current EPS security context, since: - after an EPS re-authentication, the UE and the MME can have both a current EPS security context and a non-current EPS security context which has not yet been taken into use (i.e. a partial native EPS security context); and - after an inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the UE and the MME can have both a mapped EPS security context, which is the current EPS security context, and a non-current native EPS security context that was created during a previous access in S1 mode or S101 mode. The number of EPS security contexts that need to be maintained simultaneously by the UE and the MME is limited by the following requirements: - After a successful EPS (re-)authentication, which creates a new partial native EPS security context, the MME and the UE shall delete the non-current EPS security context, if any. - When a partial native EPS security context is taken into use through a security mode control procedure, the MME and the UE shall delete the previously current EPS security context. - When the MME and the UE create an EPS security context using null integrity and null ciphering algorithm during an attach procedure for emergency bearer services, or a tracking area updating procedure for a UE that has a PDN connection for emergency bearer services (see clause 5.4.3.2), the MME and the UE shall delete the previous current EPS security context. The UE shall not update the USIM and non-volatile ME memory with the current EPS security context and shall delete the current EPS security context when the UE is detached from emergency services (e.g. before attaching for normal service). - When a new mapped EPS security context or EPS security context created using null integrity and null ciphering algorithm is taken into use during the inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME and the UE shall not delete the previously current native EPS security context, if any. Instead, the previously current native EPS security context shall become a non-current native EPS security context, and the MME and the UE shall delete any partial native EPS security context. If no previously current native EPS security context exists, the MME and the UE shall not delete the partial native EPS security context, if any. - When the MME and the UE derive a new mapped EPS security context during inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME and the UE shall delete any existing current mapped EPS security context. - When a non-current full native EPS security context is taken into use by a security mode control procedure, then the MME and the UE shall delete the previously current mapped EPS security context. - When the UE or the MME moves from EMM-REGISTERED to EMM-DEREGISTERED state, if the current EPS security context is a mapped EPS security context and a non-current full native EPS security context exists, then the non-current EPS security context shall become the current EPS security context. Furthermore, the UE and the MME shall delete any mapped EPS security context or partial native EPS security context. The UE shall mark the EPS security context on the USIM or in the non-volatile memory as invalid when the UE initiates an attach procedure as described in clause 5.5.1 or when the UE leaves state EMM-DEREGISTERED for any other state except EMM-NULL. The UE shall store the current native EPS security context as specified in annex C and mark it as valid only when the UE enters state EMM-DEREGISTERED from any other state except EMM-NULL or when the UE aborts the attach procedure without having left EMM-DEREGISTERED.