The EAP Framework

The EAP allows bringing together security mechanisms from three different areas:

• credential infrastructures and domain-specific authentication protocols, such as (U)SIMs, Authentication Centres and Authentication and Key Agreement (AKA) protocols defined by 3GPP,

• AAA protocols defined by the IETF and

• link layer-specific security protocols, such as those defined for WLAN by the IEEE in [IEEE 802.11i].

EAP is an authentication framework that supports multiple authentication methods, called EAP methods. We present only the very basics of EAP required for our purposes here. EAP is specified in [RFC3748], while the EAP key management framework is specified in [RFC5247]. EAP methods are defined in separate RFCs. The EAP methods relevant in the context of this book are:

• EAP-SIM as specified in [RFC4186] – this method allows using SIMs and GSM authentication vectors and cryptographic functions within the framework of EAP,

• EAP-AKA as specified in [RFC4187] – this method allows using USIMs and UMTS authentication vectors and cryptographic functions within the framework of EAP and

• EAP-AKA as specified in [RFC5448] – this method also allows using USIMs and UMTS authentication vectors and cryptographic functions within the framework of EAP; in addition, EAP-AKA provides a binding of derived keys to the AN identity.

For more details, see Section 11.2.

The EAP Architectural Model

The basic entities are, according to [RFC3748]:

• Authenticator: the end of the link initiating EAP authentication,

• Peer: the end of the link that responds to the authenticator and

• EAP server: the entity that terminates the EAP authentication method with the peer.

In all scenarios relevant in the context of this book, the authenticator operates in the so-called pass-through mode and, hence, does not perform any EAP method-specific operations.

70 LTE Security

Figure 5.1 Forwarding of EAP response packet across protocol layers.

The EAP Layering and Forwarding Model

Figure 5.1, which is based on [RFC3748], shows the forwarding of an EAP response packet across the protocol layers at the peer, pass-through authenticator and EAP server respectively.

One can see from Figure 5.1 that the transport of EAP messages between the peer and the authenticator differs from that between the authenticator and the EAP server.

EAP messages between the peer and the authenticator are typically carried directly on the link layer, in a way specific to the particular link layer. This is the case for 3G–WLAN interworking with direct IP access, as described in this chapter, where EAP messages are carried over WLAN using a mechanism known as EAPOL (or EAPoverLAN [IEEE 802.11i]). It is also the case for trusted access to the Evolved Packet Core, as described in Section 11.2, where EAP messages are carried using a mechanism specific to, for example, cdma2000HRPD or WiMAX. But EAP messages between the peer and the authenticator may also be encapsulated within a protected channel created by IKEv2 [RFC5996] (which obsoleted [RFC4306]), the key management protocol for IPsec security associations. This is the case for 3G–WLAN interworking with 3GPP IP access, as described in this chapter, or for untrusted access to the Evolved Packet Core, as described in Section 11.2.

EAP messages between the authenticator and the EAP server are carried using AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP Application [RFC4072].

This implies that the authenticator includes the functionality of an AAA client.

According to [RFC3748], the EAP layer receives and transmits EAP messages via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers.

Mapping of EAP Architectural Entities to a 3GPP Setting

In the scenarios covered in Chapter 5 and Section 11.2, the EAP architectural model is applied as follows.

• Authenticator: There are two cases for the allocation of the authenticator: for 3G–WLAN interworking with direct IP access, and for trusted access to the Evolved

Packet Core, the authenticator resides in the non-3GPP AN. In a WLAN, the authenticator often coincides with the WLAN Access Point terminating the WLAN radio interface. For 3G–WLAN interworking with 3GPP IP access, and for untrusted access to the Evolved Packet Core, the authenticator resides on the Packet Data Gateway (PDG) and the evolved Packet Data Gateway (ePDG), respectively, which act as the responders in IKEv2.

• Peer: The peer resides on the UE. It requires the use of SIM functionality for the purposes of EAP-SIM and USIM functionality for the purposes of EAP-AKA and EAP-AKA.

• EAP server: In all cases described in this book, the EAP server resides on the 3GPP AAA server [TS23.234, TS23.402]. The 3GPP AAA server communicates with the Home Subscriber Server (HSS) or Home Location Register (HLR) as part of the EAP method execution to retrieve authentication vectors.

The Role of Link Layer Security

In general, authentication is not sufficient for ensuring secure communication. When the access link is prone to eavesdropping or tampering, encryption and/or integrity protection is required. The encryption and integrity keys need to be generated as part of the AKA protocol. All three EAP methods relevant in our context, SIM, AKA and EAP-AKA, provide mutual authentication and key agreement. The agreed keys are called the Master Session Key (MSK) and Extended Master Session Key (EMSK) in EAP terminology [RFC5247]. Both the peer and the EAP server derive both the MSK and the EMSK. On the network side, while the EMSK remains in the EAP server, and is used in, for example, [TS33.402] to derive mobile-IP-specific keys (see Section 11.2), the MSK is sent by the EAP server to the authenticator. For direct WLAN access, the WLAN-specific keys defined in [IEEE 802.11i] are derived from MSK in the peer and the authenticator;

[RFC5247] explains the relationship of these keys with MSK.

When EAP is used in conjunction with IKEv2, the key MSK is used to compute the parameter AUTH, which is part of the IKEv2 exchange (of which more in Section 5.2.3), but MSK plays no role in the derivation of the keys used to protect IP packets in the IPsec tunnel set up by IKEv2 [RFC5996].

Use of EAP with IKEv2

IKE [RFC2409] and IKEv2 [RFC5996] are key exchange protocols for generating secu-rity associations to be used, for example, with IPsec ESP (IP Encapsulating Secusecu-rity Payload [RFC4303]). The IKE mutual authentication is based either on shared keys or on certificates on both sides. There are deployments, however, where neither of these two possibilities is well suited: the use of shared keys does not scale, and the distribu-tion of certificates to a large number of users of a public service may also be difficult from an administrative point of view. Therefore, version 2 of IKE offers another possi-bility for authentication, namely the use of an EAP method for authenticating the client (the ‘initiator’ in IKEv2 terminology). This possibility adds more flexibility by allow-ing the re-use of existallow-ing authentication infrastructures. It further allows the separation of

72 LTE Security

the IKEv2 termination point on the network side (the responder in IKEv2 terminology, for example a Virtual Private Network (VPN) gateway) from the backend authentication server. But IKEv2 still requires certificates for the authentication of the responder.

While the distribution of certificates to the responders in a network may be considered practically feasible, as they are not very numerous, the requirement to have a public key infrastructure may still be a burden in some usage scenarios. One may therefore wonder whether responder authentication by certificates is required at all when the EAP method provides mutual AKA, as many EAP methods do. And, indeed, a relatively recent RFC allows removing the requirement of responder authentication by certificates under certain conditions – see [RFC5998].

When doing so one of the problems to be taken into account is the ‘lying authenticator’

problem: even if the EAP method provides mutual authentication and key agreement, and the MSK is used to establish a secure link between the EAP peer and the authenticator, the EAP peer will, in general, know after a successful EAP protocol run only that the authenticator is some entity entrusted by the EAP server to receive the key MSK. The peer does not know, in general, from the EAP protocol run to which authenticator it is connected. Consequently, the authenticator could lie about its identity. There are scenarios where this may matter. For example, a user in a 3G–WLAN interworking scenario may want to know whether he is connected to a WLAN access point meant to provide direct IP access to the Internet, or an operator-controlled PDG meant to provide 3GPP IP access to the operator’s network.

When EAP is used with IKEv2, and the responder, assuming the role of the authentica-tor, is authenticated by a certificate binding the public key to the authenticator’s identity, the authenticator cannot lie about its identity. So while, in principle, responder authen-tication by certificates could be replaced by EAP mutual authenauthen-tication, this would be admissible only in scenarios where

• the lying authenticator problem did not matter,

• the EAP server coincided with the authenticator-responder or

• the EAP method also provided authentication of the authenticator (or a group of authen-ticators) to the peer.

The third condition is fulfilled by EAP-AKA [RFC5448] in the sense that it authen-ticates the group of authenticators identified by having the same ‘AN identifier’ to the peer, but this condition is not fulfilled by EAP-AKA without further enhancements. Such enhancements would be possible, but the corresponding references in [RFC5998] only point to Internet drafts that were expired at the time this book was written.