EAP is an authentication framework for providing 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 one-hundred EAP Types as the official authentication mechanisms.

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-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA and EAP-AKA'. Additionally 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 list of type and packets codes used in EAP is available from the IANA EAP Registry.

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) method was 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 provides support for both LEAP and EAP-FAST. Due to the wide adoption of LEAP in the networking industry many other WLAN vendors[who?] claim support for LEAP.

LEAP uses a modified version of MS-CHAP, an authentication protocol in which user credentials are not strongly protected and easily compromised; an exploit tool called ASLEAP was released in early 2004 by Joshua Wright.[3] Cisco recommends that customers who absolutely must use LEAP do so only with sufficiently complex passwords, though complex passwords are difficult to administer and enforce. Cisco's current recommendation is to use newer and stronger EAP protocols such as EAP-FAST, PEAP, or EAP-TLS.

EAP-TLS is still considered one of the most secure EAP standards available, although TLS provides strong security only as long as the user understands potential warnings about false credentials, and is universally supported by all manufacturers of wireless LAN hardware and software. Until April 2005, EAP-TLS was the only EAP type vendors needed to certify for a WPA or WPA2 logo.[4] 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, Windows CE 4.2, and Apple's iOS mobile operating system.

Unlike most TLS implementations of HTTPS, such as on the World Wide Web, the majority of implementations of EAP-TLS require client-side X.509 certificates without giving the option to disable the requirement, even though the standard does not mandate their use.[5][6] Some have identified this as having the potential to dramatically reduce adoption of EAP-TLS and prevent "open" but encrypted access points.[5][6] On 22 August 2012 hostapd (and wpa_supplicant) added support in its Git repository for an UNAUTH-TLS vendor-specific EAP type (using the hostapd/wpa_supplicant project RFC 5612 Private Enterprise Number),[7] and on 25 February 2014 added support for the WFA-UNAUTH-TLS vendor-specific EAP type (using the Wi-Fi Alliance Private Enterprise Number),[8][9] which only do server authentication. This would allow for situations much like HTTPS, where a wireless hotspot allows free access and does not authenticate station clients but station clients wish to use encryption (IEEE 802.11i-2004 i.e. WPA2) and potentially authenticate the wireless hotspot. There have also been proposals to use IEEE 802.11u for access points to signal that they allow EAP-TLS using only server-side authentication, using the standard EAP-TLS IETF type instead of a vendor-specific EAP type.[10]

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. With a client-side certificate, a compromised password is not enough to break into EAP-TLS enabled systems because the intruder still needs to have the client-side certificate; indeed, a password is not even needed, as it is only used to encrypt the client-side certificate for storage. The highest security available is when the "private keys" of client-side certificate are housed in smart cards.[11] This is because there is no way to steal a client-side certificate's corresponding private key from a smart card without stealing the card itself. It is 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.

EAP-MD5 was the only IETF Standards Track based EAP method when it was first defined in the original RFC for EAP, RFC 2284. It offers minimal security; the MD5hash 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.[12] EAP-MD5 support was first included in Windows 2000 and deprecated in Windows Vista.[13]

EAP Protected One-Time Password (EAP-POTP), which is described in RFC 4793, is an EAP method developed by RSA Laboratories that uses one-time password (OTP) tokens, such as a handheld hardware device or a hardware or software module running on a personal computer, to generate authentication keys. EAP-POTP can be used to provide unilateral or mutual authentication and key material in protocols that use EAP.

The EAP-POTP method provides two-factor user authentication, meaning that a user needs both physical access to a token and knowledge of a personal identification number (PIN) to perform authentication.[14]

EAP Pre-shared key (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 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 Password (EAP-PWD), defined in RFC 5931, is an EAP method which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.

EAP-PWD is in the base of Android 4.0 (ICS), it is in FreeRADIUS [15] and Radiator [16] RADIUS servers, it is in hostapd and wpa_supplicant.[17]

EAP Tunneled Transport Layer Security (EAP-TTLS) is an EAP protocol that extends TLS. It was co-developed by Funk Software and Certicom and is widely supported across platforms. Microsoft did not incorporate native support for the EAP-TTLS protocol in Windows XP, Vista, or 7. Supporting TTLS on these platforms requires third-party Encryption Control Protocol (ECP) certified software. Microsoft Windows started EAP-TTLS support with Windows 8,[18] however, Windows Phone 8 does not support EAP-TTLS[19] while version 8.1 supports it.[20]

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 since a certificate is not needed 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 clear text, 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.[21]

EAP Internet Key Exchange v. 2 (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:

Asymmetric key pairs

Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party.

Passwords

Low-entropy bit strings that are known to both the server and the peer.

Symmetric keys

High-entropy bit strings that are known to both the server and the peer.

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:

Flexible Authentication via Secure Tunneling (EAP-FAST; RFC 4851) is a protocol proposal by Cisco Systems as a replacement for LEAP.[22] 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.

When automatic PAC provisioning is enabled, EAP-FAST has a slight vulnerability where an attacker can intercept the PAC and use that to compromise user credentials. This vulnerability is mitigated by manual PAC provisioning or by using server certificates for the PAC provisioning phase.

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, a new PAC file must be 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 the device is validated on the network not the user.

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[24] for Windows Vista[25] and later operating systems which have an extensible EAPHost architecture for new authentication methods and supplicants.[26]

EAP Subscriber Identity Module (EAP-SIM) is used for authentication and session key distribution using the subscriber identity module (SIM) from the Global System for Mobile Communications (GSM).

GSM cellular networks use a subscriber identity module card to carry out user authentication. EAP-SIM use a SIM authentication algorithm between the client and an Authentication, Authorization and Accounting (AAA) server providing mutual authentication between the client and the network.

In EAP-SIM the communication between the SIM card and the Authentication Centre (AuC) replaces the need for a pre-established password between the client and the AAA server.

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.

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 utilizing TKIP or CCMP (based on AES) encryption.

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.

^ abRFC 5216: The EAP-TLS Authentication Protocol, Internet Engineering Task Force, March 2008, The certificate_request message is included when the server desires the peer to authenticate itself via public key. While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means.