UEs that are not in limited service state, shall initiate normal initial attach when not already attached to receive EPS emergency bearer services. The security mode control procedure shall be applied as part of EPS emergency bearer establishment as defined in TS 23.401. Thus, integrity protection (and optionally ciphering) shall be applied as for normal EPS bearers. If authentication fails for any reason, the handling of the EPS emergency bearer services shall be handled as specified in clauses 15.2.1 and 15.2.2 below. Once the IMS Emergency Session is in progress with NAS and AS integrity protection (and optionally ciphering) applied, failure of integrity checking or ciphering (for both NAS and AS) is an unusual circumstance and shall be treated as in the case of a normal EPS bearer.

If the UE already has a current EPS security context and attempts to set up an IMS Emergency Session, the UE shall use this EPS security context to protect NAS, RRC and UP traffic. If the MME successfully validates a request for EPS emergency bearer services using the current EPS security context, the MME should accept this request. A request for EPS emergency bearer services is defined to be, for the purposes of this document, an Attach request message for EPS emergency bearer services or a PDN Connectivity request message for EPS emergency bearer services. If the authentication fails during a normal Attach procedure, or a Service request procedure, while the UE is in normal service mode, and the UE intends to set up an IMS Emergency Session, the UE shall retry by sending an Attach request for EPS emergency bearer services. If the MME attempts to authenticate the UE after receiving a request for EPS emergency bearer services which was integrity protected by the current EPS NAS security context and the authentication failed and if the serving network policy does not allow unauthenticated IMS Emergency Sessions, the UE and MME shall proceed as for set up of normal EPS bearers as described in clause 6.1.1. If the MME attempts to authenticate the UE after receiving a request for EPS emergency bearer services which was integrity protected by the current EPS NAS security context and the authentication failed and the serving network policy allows unauthenticated IMS Emergency Sessions, then the UE and the MME behaviours are described in the paragraph below. If the authentication failure is detected in the UE or in the MME during an attach procedure for EPS emergency bearer services or a PDN connectivity request procedure for EPS emergency bearer services, and the related signalling messages were correctly integrity-protected by the current EPS security context, the set up of the EPS emergency bearers shall then proceed in one of two ways:

1. The set-up proceeds according to clause 15.2.2. In this case, there is no need for the UE to re-attach, and the MME requests the use of the NULL ciphering and integrity algorithms in the same way as described in clause 15.2.2.2 for the case that UE and MME share no EPS security context.
2. Or else, if the serving network policy allows unauthenticated IMS Emergency Sessions and MME continues using the current security context, the use of the EPS emergency bearers may proceed as described below for the case of an AKA run while a PDN connection for emergency bearer services exists.

If AKA is run while a PDN connection for emergency bearer services exists, the MME and UE shall behave as follows: UE behavior:

• Upon successful authentication verification in the UE, the UE shall send RES to the MME.
• Alternatively, upon authentication verification failure in the UE, the UE shall send an Authentication Failure message to the MME. The UE shall continue using the current EPS security context. If the UE receives a NAS security mode command selecting NULL integrity and ciphering algorithms, the UE shall accept this as long as the IMS Emergency session progresses.

MME behavior:

• If the serving network policy requires IMS Emergency Sessions to be authenticated, the MME shall, after the unsuccessful comparison of RES to XRES, i.e. AKA failure, proceed as if the request for EPS emergency bearers was a request for normal EPS bearer services. The MME should not send an Authentication Reject message if authentication failed in the MME and the serving network policy allows unauthenticated IMS Emergency Sessions. If the MME does not send an Authentication Reject message it shall continue using the current security context with the UE.
• After receiving both, the EC Indication and the Authentication Failure message, the MME shall continue using the current security context with the UE for establishing an EPS emergency bearer.

Authentication may fail for a UE attached for EPS emergency bearer services just as for a UE attached for normal EPS bearer services when the UE tries to establish an IMS Emergency Session. As defined in TS 23.401 and as a serving network option, IMS Emergency Sessions may be established in limited service state without the network having to authenticate the UE or apply ciphering or integrity protection for either AS or NAS. The following are the only identified cases where the "security procedure not applied" option may be used:

1. Authentication is impossible because the USIM is absent;
2. Authentication is impossible because the serving network cannot obtain authentication vectors due to a network failure;
3. Authentication is impossible because the USIM is in limited service mode in the serving network (e.g. there is no roaming agreement or the IMSI is barred, etc.);
4. Authentication is possible but the serving network cannot successfully authenticate the USIM.

If the ME receives a NAS SMC selecting EIA0 (NULL integrity) for integrity protection, and EEA0 (NULL ciphering) for encryption protection, then:

• the ME shall mark any stored native EPS NAS security context on the USIM /non-volatile ME memory as invalid; and
• the ME shall not update the USIM/non-volatile ME memory with the current EPS NAS security context.

These two rules override all other rules regarding updating the EPS NAS security context on the USIM/non-volatile ME memory, in this specification. If EIA0 is used, and the NAS COUNT values wrap around, and a new KASME has not been established before the NAS COUNT wrap around, the NAS connection shall be kept. Since a UE with a 2G SIM cannot be in authenticated via EPS AKA, it shall be considered by the MME to be unauthenticated in E-UTRAN. A UE with a 2G SIM shall at an IRAT handover to E-UTRAN when an IMS Emergency Service is active, be considered by the MME to be unauthenticated. In such a scenario, EIA0 shall be used in E-UTRAN after handover if the target network policy allows unauthenticated IMS Emergency Sessions. A handover from E-UTRAN to another RAT, of an unauthenticated IMS Emergency Session, shall result in an unauthenticated IMS Emergency Session or a circuit switched emergency call (depending on if it is a PS handover or SRVCC) in the other RAT.

If the MME attempts to authenticate the UE after receiving the EPS emergency bearer setup request and the authentication failed and if the serving network policy does not allow unauthenticated IMS Emergency Sessions, the UE and MME shall proceed as for normal EPS bearer setup requests as described in clause 6.1.1. If the UE is not yet authenticated and while the UE is trying to setup an IMS Emergency Session, the authentication failed in the UE, the UE shall wait for a NAS SMC command to set up an unauthenticated emergency bearer. If the serving network policy supports unauthenticated IMS Emergency Sessions, only then the MME shall support unauthenticated EPS emergency bearer setup. In this case, the behaviours of the UE and the MME are as described below. The confluence of EPS emergency bearer setup and authentication failure means that the UE is considered by the MME and UE itself to be in LSM even though the UE could have been in normal service mode before the EPS emergency bearer setup. UE behavior: After sending EC Indication to the serving network the UE shall know of its own intent to establish an IMS Emergency Session.

• The UE will proceed as specified for the non-emergency case in clause 6 and clause 7 of this specification except that the UE shall accept a NAS SMC selecting EEA0 and EIA0 algorithms from the MME.

MME behavior: After receiving EC Indication from the UE, the MME knows of that UE's intent to establish an IMS Emergency Session.

• If the MME cannot identify the subscriber, or cannot obtain authentication vectors, the MME shall send NAS SMC with NULL algorithms to the UE regardless of the supported algorithms announced previously by the UE.
• After the unsuccessful comparison of RES to XRES, i.e. AKA failure, the MME shall send NAS SMC with NULL algorithms to the UE regardless of the supported algorithms announced previously by the UE.
• After the receiving of both, the EC Indication and the Authentication Failure messages, the MME shall send NAS SMC with NULL algorithms to the UE regardless of the supported algorithms announced previously by the UE.

If the serving network policy does not allow unauthenticated IMS Emergency Sessions, the MME shall reject the unauthenticated EPS emergency bearer setup request from the UE.

An unauthenticated UE does not share a complete EPS NAS security context with the network. Since there has been no successful EPS AKA run, the UE and the MME does not share a KASME. When the UE and the MME does not share a KASME the only possibility for an MME that allows unauthenticated IMS Emergency Sessions is to run with the NULL integrity algorithm EIA0 and the NULL ciphering algorithm EEA0. These algorithms are not affected by the choice of key. Therefore the UE and the MME independently generate a KASME in an implementation defined way and populate the EPS NAS security context with this KASME to be used when activating an EPS NAS security context for which no successful EPS AKA run has been made. After this EPS NAS security context is activated all key derivations proceed as if they were based on a KASME generated from an EPS AKA run. Even if no confidentiality or integrity protection is provided by EIA0 and EEA0, the UE and network treat the EPS security context with the independently generated KASME as if it contained a normally generated KASME and hence share an EPS security context (see TS 24.301).

When UE attempts to make X2/S1 handover, UE and eNB derive and transfer the keys as normal to re-use the normal handover mechanism. Since the derived keys have no ability to affect the output of the NULL algorithms it is irrelevant that the network and the UE derive different keys. Furthermore, clause 7.2.4a describes how the algorithm selection is handled for unauthenticated emergency call. This implies that source eNB will forward UE EPS security capability which contains EIA0 and EEA0 only to target eNB. So the target eNB can only select EIA0 for integrity protection and EEA0 for confidential protection. If the UE does not receive any selection of new AS security algorithms during a intra-eNB handover, the UE continues to use the same algorithms as before the handover (see TS 36.331).