Overview of EAP-AKA

The most important example of an EAP method in the context of this book is EAP-AKA [RFC4187], which is based on the use of the USIM. We therefore give an overview of EAP-AKA here. As the focus of this book is LTE security, and SIMs are no longer allowed for accessing LTE and the Evolved Packet Core, we only briefly address the case of EAP-SIM in this chapter.

EAP-AKA Full Authentication

EAP-AKA allows using USIMs, UMTS authentication vectors and UMTS cryptographic functions within the framework of EAP. The USIM and the Authentication Centre perform the same functions as in UMTS AKA (see Section 4.2). The message flow and the message formats differ, however, between UMTS AKA and EAP-AKA. Figure 5.2 shows the basic message flow of a successful EAP-AKA full authentication.

1. The procedure starts with the authenticator requesting the peer’s identity. From this point onwards the authenticator passes only EAP messages through.

2. The peer replies with sending its identity. This identity may be a permanent identity or a temporary identity (pseudonym).

3. The EAP server fetches UMTS authentication vectors and sends a random 128-bit string (RAND) and authentication token (AUTN) encoded in the EAP-Request/AKA-Challenge message to the peer. The EAP server first derives a master key (MK) from the user identity and the keys Ciphering Key in 3G (CK) and Integrity Key in 3G (IK).

From MK, the EAP server then derives the keys MSK and EMSK (see Section 5.1), as well as Transient EAP Keys (TEKs), the encryption key K_encr and the integrity key K_aut, for protecting the EAP-AKA messages. For the details of EAP-AKA key derivation, see [RFC4187]. If the EAP server supports user identity privacy, it may also include a pseudonym protected with this encryption key. The peer may use this pseudonym in the next full authentication.

4. The peer first hands the received RAND and AUTN to the USIM, which processes them as for UMTS AKA. The peer obtains CK and IK from the USIM and performs the same key derivations as the EAP server. The peer decrypts the encrypted parts of the EAP-Request/AKA-Challenge message and checks the integrity of the message. The peer then sends the AT_RES attribute, which includes RES, in the EAP-Response/AKA-Challenge message to the EAP server.

5. The EAP server checks RES against Expected Response (XRES) in the UMTS authen-tication vector it received from the HSS or HLR, and then checks the integrity of the

Authenticator Peer

2. EAP-Response/Identity 1. EAP-Request/Identity

EAP Server

4. EAP-Response/AKA-Challenge 3. EAP-Request/AKA-Challenge

5. EAP-Success

Figure 5.2 EAP-AKA full authentication procedure.

74 LTE Security

message. If the checks are successful the EAP server sends an EAP-Success message to the peer. The AAA message, in which the EAP-Success message is carried between the EAP server and the authenticator, may also carry the key MSK. MSK is not forwarded by the authenticator to the peer as the peer-derived MSK in step 3.

The EAP-AKA full authentication procedure ends with step 5. It may be followed by a procedure, such as a four-way handshake according to [IEEE 802.11i], to establish link layer security using the key MSK shared between the peer and the authenticator.

EAP-AKA Fast Re-authentication

The fast re-authentication procedure differs from a full authentication procedure in that it does not consume a new UMTS authentication vector, nor does it involve the USIM.

Authentication and key derivation are based on the keys derived during the preceding full authentication procedure. The same TEKs are used while fresh keys MSK and EMSK are derived from MK. Fast re-authentication identities, different from the permanent user identity, are used with this procedure. The EAP-AKA fast re-authentication procedure has no equivalent in UMTS AKA; but one could argue that EPS AKA (see Chapter 7) has a somewhat similar feature in that EPS AKA produces the local master key K_ASME, from which new session keys can be generated without involving the USIM or consuming new authentication vectors.

EAP-AKA Identities

The identities of the peer have the form of a Network Access Identifier (NAI), as defined in [RFC4282]. A NAI is composed of a username and, optionally, a realm, and has the form

‘username@realm’. The username uniquely identifies a user within a realm (when there is a realm). [TS23.234] specifies that the NAI representing the permanent user identity in EAP-AKA for 3G–WLAN interworking shall be derived from the user’s International Mobile Subscriber Identity (IMSI) as defined in [TS23.003]. A permanent user identity then takes the form

‘0<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org’

Permanent user identities are used only in EAP-AKA full authentications. Temporary identities, also called pseudonyms, are used for the purpose of user identity privacy. They are used only in EAP-AKA full authentications. Pseudonyms may be generated by the EAP server in an implementation-dependent manner, as only the EAP server needs to be able to map the pseudonym username to the permanent identity. 3GPP, however, specified a particular way of generating pseudonyms from permanent user identities in [TS33.234]

in order to allow for the case where a user may be served by different servers within an operator’s network at different points in time (e.g. for load-balancing purposes). The 3GPP-defined mechanism, which is described in Section 5.3, then allows all these servers to understand the pseudonyms. Pseudonyms are sent by the EAP server to the peer in an encrypted part of an EAP message. If they were not encrypted, user identity privacy would be endangered.

Fast re-authentication identities are generated by the EAP server in a way similar to pseudonyms.

In Section 5.2, the principles laid out in this section are applied to securing the 3G–WLAN interworking procedures for direct IP access and 3GPP IP access.

5.2 Security Mechanisms of 3G–WLAN Interworking