Extensible Authentication Protocol

Extensible Authentication Protocol, or EAP, is a universal authentication framework frequently used in wireless networks and Point-to-Point connections. It is defined in RFC 3748, which has been updated by RFC 5247. Although the EAP protocol is not limited to wireless LANs and can be used for wired LAN authentication, it is most often used in wireless LANs. Recently, the WPA and WPA2 standard has officially adopted five EAP types as its official authentication mechanisms.

EAP is an authentication framework, not a specific authentication mechanism. The EAP provides some common functions and a negotiation of the desired authentication mechanism. Such mechanisms are called EAP methods and there are currently about 40 different methods. Methods defined in IETF RFCs include EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, 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, PEAP, LEAP and EAP-TTLS. Requirements for EAP methods used in wireless LAN authentication are described in RFC 4017.

When EAP is invoked by an 802.1X enabled NAS (Network Access Server) device such as an 802.11 a/b/g Wireless Access Point, modern EAP methods can provide a secure authentication mechanism and negotiate a secure PMK (Pair-wise Master Key) between the client and NAS. The PMK can then be used for the wireless encryption session which uses TKIP or CCMP (based on AES) encryption.

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. In the case of 802.1X, this encapsulation is called EAPOL, "EAP over LANs".

LEAP

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. [citeweb|title=Ultimate wireless security guide: An introduction to LEAP authentication|url=http://articles.techrepublic.com.com/5100-1035-6148551.html|publisher=techrepublic.com|accessdate=2008-02-17] 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. 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 . [citeweb|title=Look Before You LEAP|url=http://www.unstrung.com/document.asp?doc_id=41185|publisher=unstrung.com|accessdate=2008-02-17] 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-TLS

EAP-Transport Layer Security or EAP-TLS, defined in RFC 5216, is an IETF open standard, and is well-supported among wireless vendors. The security of the TLS (formerly officially and still often unofficially called Secure Sockets Layer) protocol is strong, as long as the user understands potential warnings about false credentials. It uses PKI to secure communication to the 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 including Microsoft. 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 hacker still needs to have the client-side private key. The highest security available is when the client-side keys are housed in smartcards. This is because there is no way to steal a certificate's corresponding private key from a smartcard without stealing the smartcard itself. It is significantly more likely that the physical theft of a smartcard would be noticed (and the smartcard 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. [citeweb|title=Understanding the updated WPA and WPA2 standards|url=http://blogs.techrepublic.com.com/Ou/?p=67|publisher=techrepublic.com|accessdate=2008-02-17] There are client and server implementations of it in Microsoft, Cisco, Apple, and open source operating systems. EAP-TLS is natively supported in Mac OS X 10.3 and above, Windows 2000 SP4, Windows XP, Windows Vista, Windows Server 2003, Windows Mobile 2003 and above, and Windows CE 4.2.

EAP-MD5

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. [citeweb|title=Alternative Encryption Schemes: Targeting the weaknesses in static WEP|url=http://arstechnica.com/articles/paedia/security.ars/4|publisher=arstechnica.com|accessdate=2008-02-17]

EAP-PSK

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-TTLS

EAP-Tunneled Transport Layer Security, or 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 SecureW2.

EAP-TTLS offers very good security. The client does not need be authenticated via a CA-signed PKI certificate to the server, but only the server to the client. 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, 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.

EAP TTLS is described in RFC 5281.

EAP-IKEv2

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:

EAP-IKEv2 is described in RFC 5106. A prototype implementation can be found at http://eap-ikev2.sourceforge.net.

PEAP

PEAP is a joint proposal by Cisco Systems, Microsoft and RSA Security as an open standard. It is already widely available in products, and provides very good security. It is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication. [citeweb|title=Ultimate wireless security guide: An introduction to PEAP authentication|url=http://articles.techrepublic.com.com/5100-1035-6148543.html|publisher=techrepublic.com|accessdate=2008-02-17]

The PEAP standard was created by Microsoft, Cisco, and RSA after EAP-TTLS had already come on the market. Even with its late start, Microsoft’s and Cisco’s size allowed them to quickly overtake EAP-TTLS in the market. PEAP is so successful in the market place that even Funk Software, the inventor and backer of EAP-TTLS, had no choice but to support PEAP in their server and client software for wireless networks.

As of May 2005, there were two PEAP sub-types certified for the updated WPA and WPA2 standard. They are:
*PEAPv0/EAP-MSCHAPv2
*PEAPv1/EAP-GTC

The terms PEAPv0 and PEAPv1 refer to the outer authentication method, the mechanism that creates the secure TLS tunnel to protect subsequent authentication transactions. EAP-MSCHAPv2, EAP-GTC, and EAP-SIM refer to the inner authentication method which facilitates user or device authentication.

PEAPv0/EAP-MSCHAPv2

PEAPv0/EAP-MSCHAPv2 is the technical term for what people most commonly refer to as "PEAP". Whenever the word PEAP is used, it almost always refers to this form of PEAP since most people have no idea there are so many flavors of PEAP. Behind EAP-TLS, PEAPv0/EAP-MSCHAPv2 is the second most widely supported EAP standard in the world.

There are client and server implementations of it in Microsoft, Cisco, Apple, Linux, and open source. PEAPv0/EAP-MSCHAPv2 is natively supported in Mac OS X 10.3 and above, Windows 2000 SP4, Windows XP, Windows Server 2003 and above, and Windows CE 4.2. The server side implementation of PEAPv0/EAP-MSCHAPv2, called IAS (Internet Authentication Service), is also included in Windows 2003 server. PEAPv0/EAP-MSCHAPv2 enjoys universal support and is known as the PEAP standard.

This version of PEAP was defined in Internet Draft [http://tools.ietf.org/id/draft-kamath-pppext-peapv0-00.txt "draft-kamath-pppext-peapv0"] .

The support for inner EAP methods in PEAPv0 varies by vendor: while Cisco's implementation of PEAPv0 supports inner EAP methods EAP-MSCHAPv2 and EAP-SIM, Microsoft only supports the PEAPv0/EAP-MSCHAPv2 mode but not the PEAPv0/EAP-SIM mode. Microsoft also only supports PEAPv0 and doesn’t support PEAPv1, so they simply call PEAPv0 PEAP without the v0 or v1 designator.

Microsoft supports another form of PEAPv0 which they call PEAP-EAP-TLS, one that Cisco and other third-party server and client software don’t support. PEAP-EAP-TLS does require a client-side digital certificate located on the client’s hard drive or a more secure smartcard. PEAP-EAP-TLS is very similar in operation to the original EAP-TLS but provides slightly more protection due to the fact that portions of the client certificate that are unencrypted in EAP-TLS are encrypted in PEAP-EAP-TLS. Since few third-party clients and servers support PEAP-EAP-TLS, users should probably avoid it unless they only intend to use Microsoft desktop clients and servers.

PEAPv1/EAP-GTC

PEAPv1/EAP-GTC was created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2. It allows the use of an inner authentication protocol other than Microsoft's MSCHAPv2. EAP-GTC (Generic Token Card) is defined in RFC 3748. It carries a text challenge from the authentication server, and a reply which is assumed to be generated by a security token. EAP-GTC does not protect the authentication data in any way.

Even though Microsoft (along with RSA and Cisco) co-invented the PEAP standard, Microsoft never added support for PEAPv1 in general, which means PEAPv1/EAP-GTC has no native Windows OS support. Since Cisco has always favored the use of its own less secure proprietary LEAP and EAP-FAST protocols over PEAP and markets them as simpler certificate-less solutions, standardized PEAP is rarely promoted by Cisco.Fact|date=August 2008

With no interest from Microsoft to support PEAPv1 and little interest from Cisco to promote PEAP in general, PEAPv1 authentication is rarely used. There is no native OS support for this EAP protocol.

Although there is no in-built support for PEAP-GTC in MS Windows, it is supported by the Cisco CCX extensions program. CCX compatibility is enabled by default on many vendor-provided 802.11A/B/G clients.

This version of PEAP is defined through the IETF internet draft [http://tools.ietf.org/id/draft-josefsson-pppext-eap-tls-eap-10.txt "draft-josefsson-pppext-eap-tls-eap-10"] . Note that this is an individual submission and not standardized in the IETF.

Note that Cisco's implementation of PEAPv1 also supports EAP-SIM as the inner EAP method, other than EAP-GTC.

EAP-FAST

EAP-FAST (Flexible Authentication via Secure Tunneling) is a protocol proposal by Cisco Systems as a replacement for LEAP. [citeweb|title=Ultimate wireless security guide: A primer on Cisco EAP-FAST authentication|url=http://articles.techrepublic.com.com/5100-1035-6148557.html|publisher=techrepublic.com|accessdate=2008-02-17] 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 a hacker'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 to accept it, and if he does, then he will send his 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.

EAP-FAST is defined in RFC 4851.

EAP-SIM

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). EAP-SIM is defined in RFC 4186.

EAP-AKA

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.

ee also

*Diameter
*Handover Keying
*PPP
*RADIUS

References

External links

* RFC 3748: Extensible Authentication Protocol (EAP) (June 2004)
* RFC 5247: Extensible Authentication Protocol (EAP) Key Management Framework (August 2008)
* [http://articles.techrepublic.com.com/5100-1035-6148579.html Configure RADIUS for secure 802.1x wireless LAN]
* [http://articles.techrepublic.com.com/5100-1035-6148560.html How to self-sign a RADIUS server for secure PEAP or EAP-TTLS authentication]
* Wifiradis [http://www.wifiradis.net a free online RADIUS server for secure PEAP mschap-v2 authentication]
* [http://www.microsoft.com/technet/prodtechnol/winxppro/evaluate/eap.mspx EAP in Windows XP and Windows Server 2003]
* [http://www.microsoft.com/technet/technetmag/issues/2007/05/CableGuy/default.aspx EAPHost in Windows Vista and Windows Server 2008]
* [http://wire.cs.nthu.edu.tw/wire1x/ WIRE1x]
* [http://www.ietf.org/html.charters/emu-charter.html "IETF EAP Method Update (emu) Working Group"]