EPS AKA is the authentication and key agreement procedure that shall be used over E-UTRAN. A Rel-99 or later USIM application on a UICC shall be sufficient for accessing E-UTRAN, provided the USIM application does not make use of the separation bit of the AMF in a way described in TS 33.102 Annex F. Access to E-UTRAN with a 2G SIM or a SIM application on a UICC shall not be granted. An ME that has E-UTRAN radio capability shall support the USIM-ME interface as specified in TS 31.102 EPS AKA shall produce keying material forming a basis for user plane (UP), RRC, and NAS ciphering keys as well as RRC and NAS integrity protection keys. The MME sends to the USIM via ME the random challenge RAND and an authentication token AUTN for network authentication from the selected authentication vector. It also includes a KSIASME for the ME which will be used to identify the KASME (and further keys derived from the KASME) that results from the EPS AKA procedure. At receipt of this message, the USIM shall verify the freshness of the authentication vector by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. USIM shall compute CK and IK which are sent to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. If the verification fails, the USIM indicates to the ME the reason for failure and in the case of a synchronisation failure passes the AUTS parameter (see TS 33.102). An ME accessing E-UTRAN shall check during authentication that the "separation bit" in the AMF field of AUTN is set to 1. The "separation bit" is bit 0 of the AMF field of AUTN. UE shall respond with User authentication response message including RES in case of successful AUTN verification and successful AMF verification as described above. In this case the ME shall compute KASME from CK, IK, and serving network's identity (SN id) using the KDF as specified in clause A.2. SN id binding implicitly authenticates the serving network's identity when the derived keys from KASME are successfully used. Otherwise UE shall send an authentication failure message with a CAUSE value indicating the reason for failure. In case of a synchronisation failure of AUTN (as described in TS 33.102), the UE also includes AUTS that was provided by the USIM. Upon receipt of an authentication failure message, the MME may initiate further identity requests and authentications towards the UE. (see TS 24.301). The MME checks that the RES equals XRES. If so the authentication is successful. If not, depending on type of identity used by the UE in the initial NAS message, the MME may initiate further identity requests or send an authentication reject message towards the UE (see TS 24.301). Figure 6.1.1-1 describes EPS AKA procedure, which is based on UMTS AKA (see TS 33.102). The following keys are shared between UE and HSS:

• K is the permanent key stored on the USIM on a UICC and in the Authentication Centre AuC.
• CK, IK is the pair of keys derived in the AuC and on the USIM during an AKA run. CK, IK shall be handled differently depending on whether they are used in an EPS security context or a legacy security context, as described in clause 6.1.2.

As a result of the authentication and key agreement, an intermediate key KASME shall be shared between UE and MME i.e. the ASME for EPS.

The purpose of this procedure is to provide the MME with one or more EPS authentication vectors (RAND, AUTN, XRES, KASME) from the user's HE (HSS) to perform user authentication. Each EPS authentication vector can be used to authenticate the UE.

An EPS authentication vector is derived from the authentication vector defined in clause 6.3.2 of TS 33.102. To derive the key KASME in the HE, the KDF as specified in clause A.2 is used which shall contain following mandatory input parameters: CK, IK and SN identity. If the Network Type equals E-UTRAN then the "separation bit" in the AMF field of AUTN shall be set to 1 to indicate to the UE that the authentication vector is only usable for AKA in an EPS context, if the "separation bit" is set to 0, the vector is usable in a non-EPS context only (e.g. GSM, UMTS). For authentication vectors with the "separation bit" set to 1, the secret keys CK and IK generated during AKA shall never leave the HSS. The MME invokes the procedures by requesting authentication vectors from the HE (Home environment). The authentication data request shall include the IMSI, the Serving Network identity i.e. MCC + MNC, and the Network Type (i.e. E-UTRAN). In the case of a synchronisation failure, the MME shall also include RAND and AUTS. In this case the HE checks the AUTS parameter before sending new authentication vectors to the MME (see TS 33.102). Upon the receipt of the authentication data request from the MME, the HE may have pre-computed the required number of EPS authentication vectors and retrieve them from the HSS database or may compute them on demand. The HE sends an authentication response back to the MME that contains the requested information. If multiple EPS authentication vectors had been requested then they are ordered based on their sequence numbers. The MME shall be aware of the order of the EPS authentication vectors and shall use that the EPS authentication vectors in order.

The user identification mechanism should be invoked by the serving network whenever the user cannot be identified by means of a temporary identity (GUTI). In particular, it should be used when the serving network cannot retrieve the IMSI based on the GUTI by which the user identifies itself on the radio path. The mechanism described in Figure 6.1.3-1 allows the identification of a user on the radio path by means of the permanent subscriber identity (IMSI).

The mechanism is initiated by the MME that requests the user to send its permanent identity. The user's response contains the IMSI in cleartext. This represents a breach in the provision of user identity confidentiality.

The purpose of this procedure is to provide a newly visited MME with authentication data from a previously visited MME within the same serving network domain. The procedure is shown in Figure 6.1.4-1.

The procedure shall be invoked by the newly visited MMEn after the receipt of a Tracking Area update request from the user wherein the user is identified by means of a temporary user identity GUTIo and the Tracking area identity TAIo under the jurisdiction of a previously visited MMEo that belongs to the same serving network domain as the newly visited MMEn. The protocol steps are as follows:

1. The MMEn sends a message to the MMEo, this message contains GUTIo and the received TAU message.
2. The MMEo searches the user data in the database and checks the integrity protection on the TAU message.
   If the user is found and the integrity check succeeds, the MMEo shall send a response back that:
   1. shall include the IMSI,
   2. may include a number of unused EPS-authentication vectors ordered on a first-in / first-out basis, and
   3. may include any EPS security contexts it holds
   The MMEo subsequently deletes the EPS-authentication vectors and any EPS security contexts which have been sent.
   If the user cannot be identified or the integrity check fails, then the MMEo shall send a response indicating that the user identity cannot be retrieved.
3. If the MMEn receives a response with an IMSI, it creates an entry and stores any EPS-authentication vectors and any EPS security context that may be included.
   If the MMEn receives a response indicating that the user could not be identified, it shall initiate the user identification procedure described in clause 6.1.3 during the Initial E-UTRAN Attach procedure, or it shall reject the TAU Request message initiated by UE during the TAU procedure (see clause 4.4.4.3 in TS 24.301).

The same procedure does not apply to distribution of EPS authentication data between MME and SGSN in the same serving network domain, i.e. EPS authentication data shall not be forwarded from an MME towards an SGSN.

In general, the distribution of IMSI and authentication data between MMEs belonging to different serving network domains of shall be performed as described for the distribution of IMSI and authentication data within the same service network domain in clause 6.1.4. In particular, the current EPS security context data may be transferred between MMEs belonging to different serving network domains. However, there is the following restriction:

• Unused EPS authentication vectors, or non-current EPS security contexts, shall not be distributed between MMEs belonging to different serving domains (PLMNs).

The same procedure does not apply to distribution of EPS authentication data between MME and SGSN in different serving network domains, i.e. EPS authentication data shall not be forwarded from an MME towards an SGSN.

This clause applies to both distribution of UMTS authentication vectors within one serving network domain and distribution of UMTS authentication vectors between different serving network domains. The following rules apply to the distribution of UMTS authentication vectors between two MMEs, and between an SGSN and an MME:

1. MME to MME
   UMTS authentication vectors that were previously received from an SGSN shall not be forwarded between MME's.
2. SGSN to MME
   An SGSN may forward unused UMTS authentication vectors to an MME. only if MME and SGSN are in the same serving network domain.
3. MME to SGSN
   UMTS AVs which were previously stored in the MME may be forwarded back towards the same SGSN.
   UMTS AVs which were previously stored in the MME shall not be forwarded towards other SGSNs.