Extensible Authentication Protocol, or EAP, is an authentication framework frequently used in wireless networks and Point-to-Point connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and was updated by RFC 5247.
EAP is an authentication framework providing for the transport and usage of keying material and parameters generated by EAP methods.[1] There are many methods defined by RFCs and a number of vendor specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines message formats. Each protocol that uses EAP defines a way to encapsulate EAP messages within that protocol's messages.
EAP is in wide use. For example, in IEEE 802.11 (WiFi) the WPA and WPA2 standards have adopted IEEE 802.1X with five EAP types as the official authentication mechanisms.
Contents |
EAP is an authentication framework, not a specific authentication mechanism.[1] It provides some common functions and negotiation of authentication methods called EAP methods. There are currently about 40 different methods defined. Methods defined in IETF RFCs include EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA and EAP-AKA', and in addition a number of vendor specific methods and new proposals exist. Commonly used modern methods capable of operating in wireless networks include EAP-TLS, EAP-SIM, EAP-AKA, LEAP and EAP-TTLS. Requirements for EAP methods used in wireless LAN authentication are described in RFC 4017.
The standard also describes the conditions under which the AAA key management requirements described in RFC 4962 can be satisfied.
The Lightweight Extensible Authentication Protocol (LEAP) is a proprietary EAP method developed by Cisco Systems prior to the IEEE ratification of the 802.11i security standard.[2] Cisco distributed the protocol through the CCX (Cisco Certified Extensions) as part of getting 802.1X and dynamic WEP adoption into the industry in the absence of a standard. There is no native support for LEAP in any Windows operating system, but it is widely supported by third party client software most commonly included with WLAN (wireless LAN) devices. LEAP support for Microsoft Windows 7 and Microsoft Windows Vista can be added by downloading a client add in from Cisco that adds support for both LEAP and EAP-FAST. Due to the wide adoption of LEAP in the networking industry, many other WLAN vendors claim support for LEAP.
LEAP uses a modified version of MS-CHAP, an authentication protocol in which user credentials are not strongly protected and are thus easily compromised. Along these lines, an exploit tool called ASLEAP was released in early 2004 by Joshua Wright.[3] Cisco recommends that customers that absolutely must use LEAP do so only with sufficiently complex passwords, though complex passwords are difficult to administer and enforce. Cisco's current general recommendation is to use newer and stronger EAP protocols such as EAP-FAST, PEAP, or EAP-TLS.
EAP-Transport Layer Security (EAP-TLS), defined in RFC 5216, is an IETF open standard, and is well-supported among wireless vendors. The security of the TLS protocol is strong, provided the user understands potential warnings about false credentials. It uses PKI to secure communication to a RADIUS authentication server or another type of authentication server. So even though EAP-TLS provides excellent security, the overhead of client-side certificates may be its Achilles' heel.
EAP-TLS is the original, standard wireless LAN EAP authentication protocol. Although it is rarely deployed, it is still considered one of the most secure EAP standards available and is universally supported by all manufacturers of wireless LAN hardware and software. The requirement for a client-side certificate, however unpopular it may be, is what gives EAP-TLS its authentication strength and illustrates the classic convenience vs. security trade-off. A compromised password is not enough to break into EAP-TLS enabled systems because the intruder still needs to have the client-side private key. The highest security available is when client-side keys are housed in smart cards.[4] This is because there is no way to steal a certificate's corresponding private key from a smart card without stealing the card itself. It is significantly more likely that the physical theft of a smart card would be noticed (and the smart card immediately revoked) than a (typical) password theft would be noticed. Up until April 2005, EAP-TLS was the only EAP type vendors needed to certify for a WPA or WPA2 logo.[5] There are client and server implementations of EAP-TLS in 3Com, Apple, Avaya, Brocade Communications, Cisco, Enterasys Networks, Foundry, Hirschmann, HP, Juniper, and Microsoft, and open source operating systems. EAP-TLS is natively supported in Mac OS X 10.3 and above, wpa supplicant, Windows 2000 SP4, Windows XP and above, Windows Mobile 2003 and above, and Windows CE 4.2.
EAP-MD5, defined in RFC 3748, is the only IETF Standards Track based EAP method. It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise. EAP-MD5 differs from other EAP methods in that it only provides authentication of the EAP peer to the EAP server but not mutual authentication. By not providing EAP server authentication, this EAP method is vulnerable to man-in-the-middle attacks.[6] EAP-MD5 support was first included in Windows 2000 and deprecated in Windows Vista.[7]
EAP-PSK, defined in RFC 4764, is an EAP method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). It provides a protected communication channel when mutual authentication is successful for both parties to communicate over and is designed for authentication over insecure networks such as IEEE 802.11.
EAP-PSK is documented in an experimental RFC that provides a lightweight and extensible EAP method that does not require any public-key cryptography. The EAP method protocol exchange is done in a minimum of four messages.
EAP-Tunneled Transport Layer Security (EAP-TTLS) is an EAP protocol that extends TLS. It was co-developed by Funk Software and Certicom. It is widely supported across platforms, although there is no native OS support for this EAP protocol in Microsoft Windows, it requires the installation of small extra programs such as SecureW2or [http://www.open1x.org/ xSupplicant.
EAP-TTLS offers very good security . The client can but does not have to be authenticated via a CA-signed PKI certificate to the server. This greatly simplifies the setup procedure as a certificate does not need to be installed on every client.
After the server is securely authenticated to the client via its CA certificate and optionally the client to the server, the server can then use the established secure connection ("tunnel") to authenticate the client. It can use an existing and widely deployed authentication protocol and infrastructure, incorporating legacy password mechanisms and authentication databases, while the secure tunnel provides protection from eavesdropping and man-in-the-middle attack. Note that the user's name is never transmitted in unencrypted cleartext, thus improving privacy.
Two distinct versions of EAP-TTLS exist: original EAP-TTLS (a.k.a. EAP-TTLSv0) and EAP-TTLSv1. EAP-TTLSv0 is described in RFC 5281, EAP-TTLSv1 is available as an Internet draft.[8]
EAP-IKEv2 is an EAP method based on the Internet Key Exchange protocol version 2 (IKEv2). It provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on the following types of credentials:
It is possible to use a different authentication credential (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. In particular, the following combinations are expected to be used in practice:
| EAP server | EAP peer |
|---|---|
| Asymmetric key pair | Asymmetric key pair |
| Asymmetric key pair | Symmetric key |
| Asymmetric key pair | Password |
| Symmetric key | Symmetric key |
EAP-IKEv2 is described in RFC 5106. A prototype implementation can be found at http://eap-ikev2.sourceforge.net.
EAP-FAST (Flexible Authentication via Secure Tunneling) is a protocol proposal by Cisco Systems as a replacement for LEAP.[9] The protocol was designed to address the weaknesses of LEAP while preserving the "lightweight" implementation. Use of server certificates is optional in EAP-FAST. EAP-FAST uses a Protected Access Credential (PAC) to establish a TLS tunnel in which client credentials are verified. EAP-FAST has three phases. Phase 0 is an optional phase in which the PAC can be provisioned manually or dynamically, but is outside the scope of EAP-FAST as defined in RFC4851. PAC provisioning is still officially Work-in-progress, even though there are many implementations. PAC provisioning typically only needs to be done once for a RADIUS server, client pair. In Phase 1, the client and the AAA server uses the PAC to establish TLS tunnel. In Phase 2, the client credentials are exchanged inside the encrypted tunnel.
When automatic PAC provisioning is enabled, EAP-FAST has a slight vulnerability that an attacker can intercept the PAC and subsequently use that to compromise user credentials. This vulnerability is mitigated by manual PAC provisioning or by using server certificates for the PAC provisioning phase.
There is also a vulnerability where an attacker's AP can use the same SSID, reject the users PAC and supply a new one. Most supplicants can be set to prompt the user this credentials using the inner method to the hacker, who will then get either a cleartext password (EAP-FAST w/ GTC) or a vulnerable to dictionary attack MSCHAPv2 hash.
It is worth noting that the PAC file is issued on a per-user basis. This is a requirement in RFC 4851 sec 7.4.4 so if a new user logs on the network from a device, he needs a new PAC file provisioned first. This is one reason why it is difficult not to run EAP-FAST in insecure anonymous provisioning mode. The alternative is to use device passwords instead, but then it is not the user that is validated on the network.
EAP-FAST can be used without PAC files, falling back to normal TLS.
EAP-FAST is natively supported in Apple OS X 10.4.8 and newer. Cisco supplies an EAP-FAST module[10] for Windows Vista [11] and later operating systems which have an extensible EAPHost architecture for new authentication methods and supplicants.[12]
EAP-FAST is defined in RFC 4851.
EAP for GSM Subscriber Identity is used for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). The A3/A8 algorithms are being run a few times, with different 128 bit challenges, so there will be more 64 bit Kc-s which will be combined/mixed to create stronger keys (Kc-s won't be used directly). The lack of mutual authentication in GSM has also been overcome. EAP-SIM is defined in RFC 4186.
EAP for UMTS Authentication and Key Agreement is used for authentication and session key distribution using the Universal Mobile Telecommunications System (UMTS) Universal Subscriber Identity Module (USIM). EAP AKA is defined in RFC 4187.
The EAP-AKA' (AKA Prime) variant of EAP-AKA is defined in RFC 5448 and is used for non-3GPP access to a 3GPP core network, for example via EVDO, WiFi, or WiMax.
EAP Generic Token Card, or EAP-GTC, is an EAP method created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2 and defined in RFC 2284 and RFC 3748. EAP-GTC carries a text challenge from the authentication server, and a reply generated by a security token. The PEAP-GTC authentication mechanism allows generic authentication to a number of databases such as Novell Directory Service (NDS) and Lightweight Directory Access Protocol (LDAP), as well as the use of a one-time password.
EAP with the Encrypted key exchange, or EAP-EKE, is one of the few EAP methods that provide secure mutual authentication using short passwords, and with no need for public key certificates. This method is specified in RFC 6124. It is a 3-round exchange, based on the Diffie-Hellman variant of the well-known EKE protocol.
EAP is not a wire protocol; instead it only defines message formats. Each protocol that uses EAP defines a way to encapsulate EAP messages within that protocol's messages.
The encapsulation of EAP over IEEE 802 is defined in IEEE 802.1X and known as "EAP over LANs" or EAPOL.[13][14][15] EAPOL was originally designed for IEEE 802.3 ethernet in 802.1X-2001, but was clarified to suit other IEEE 802 LAN technologies such as IEEE 802.11 wireless and Fiber Distributed Data Interface (ISO 9314-2) in 802.1X-2004.[16] The EAPOL protocol was also modified for use with IEEE 802.1AE (MACsec) and IEEE 802.1AR (Initial Device Identity, IDevID) in 802.1X-2010.[17]
When EAP is invoked by an 802.1X enabled Network Access Server (NAS) device such as an IEEE 802.11i-2004 Wireless Access Point (WAP), modern EAP methods can provide a secure authentication mechanism and negotiate a secure private key (Pair-wise Master Key, PMK) between the client and NAS which can then be used for a wireless encryption session which uses TKIP or CCMP (based on AES) encryption.
The Protected Extensible Authentication Protocol, also known as Protected EAP or simply PEAP, is a protocol that encapsulates EAP within a potentially encrypted and authenticated Transport Layer Security (TLS) tunnel.[18][19][20] The purpose was to correct deficiencies in EAP; EAP assumed a protected communication channel, such as that provided by physical security, so facilities for protection of the EAP conversation were not provided.[21]
PEAP was jointly developed by Cisco Systems, Microsoft, and RSA Security. PEAPv0 was the version included with Microsoft Windows XP and was nominally defined in draft-kamath-pppext-peapv0-00. PEAPv1 and PEAPv2 were defined in different versions of draft-josefsson-pppext-eap-tls-eap. PEAPv1 was defined in draft-josefsson-pppext-eap-tls-eap-00 through draft-josefsson-pppext-eap-tls-eap-05,[22] and PEAPv2 was defined in versions beginning with draft-josefsson-pppext-eap-tls-eap-06.[23]
The protocol only specifies chaining multiple EAP mechanisms and not any specific method.[19][24] However, use of the EAP-MSCHAPv2 and EAP-GTC methods are the most commonly supported.
The Protocol for Carrying Authentication for Network Access (PANA) is an IP-based protocol that allows a device to authenticate itself with a network to be granted access. PANA will not define any new authentication protocol, key distribution, key agreement or key derivation protocols. For these purposes, EAP will be used, and PANA will carry the EAP payload. PANA allows dynamic service provider selection, supports various authentication methods, is suitable for roaming users, and is independent from the link layer mechanisms.