EAP, LEAP, PEAP and EAP-TLS and EAP-TTLS

Once the popularity of WiFi started to take off in the early 2000s, a major issue that was identified with the inherent security included in the 802.11 standard was the weakness of WEP encryption. Although a number of competing security methods have emerged since this time, the EAP, LEAP, PEAP, EAP-TLS, and EAP-TTLS protocols were developed in order to help provide additional security for the transmission or transport of authenticating information over a network. The 802.1X standard includes several of these protocols and is able to provide a network administrator with both a stronger authentication methodology than WEP provides as well as a means to both derive and distribute stronger keys to network clients to further improve the strength of WEP.

What is EAP?

The EAP (Extensible Authentication Protocol) was developed to provide an authentication framework that can be used for both Point-Point connections as well as wireless networks. The current definition of the protocol was originally included in the IETF’s RFC 3748 and later updated by RFC 5247. The purpose of the framework is to provide a means for the secure transport of keying material and related parameters that are created by the various methods included in the framework. Despite a common misperception, EAP is not considered to be a wire protocol. Instead, it solely defines a message format that allows other protocols to include or encapsulate the EAP message within a containing message format. Since the original definition and release of the EAP message format, it has found widespread usage across newer security protocols used on the Web to include the WPA and WPA2 standards which use EAP as the primary authentication method.

What Methods are Defined by EAP?

Since EAP was created in order to provide and authentication framework and not an authentication mechanism, it provides commonly defined methods that are available for implementing applications or protocols to leverage. Some of the more popular baseline methods that are defined in the IETF standard include EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-MD, EAP-SIM, and SAP-AKA. Since the original release of the standard, there have also been a number of vendor-specific ‘add-ons’ and methods developed. Although some of these have been included in the latest proposals for update to the standard, not all have been adopted by industry. The IETF RFC 4017 includes the methods recommended for implementation in a WiFi authentication scheme which include EAP-TTLS, LEAP, EAP-SIM, EAP-TLS, and EAP-AKA. This recent standard also includes the means by which AAA key management can be implemented and be conformant with the standard.

How Does LEAP Work?

The LEAP (Lightweight Extensible Authentication Protocol) was originally created by Cisco Systems prior to the official ratification of the 802.11i standard. The LEAP protocol was first distributed via Cisco Certified Extensions (CCX) as part of trying to get industry to adopt 802.1X as well as dynamic WEP adopted by industry. Although there is not native LEAP support in the Windows OS, it is commonly supported by the various third party software included with widely sold wireless routers and devices. In order to add LEAP support for Microsoft Windows Vista or Windows 7, a simple client application has to be downloaded (for free) from Cisco that includes support for both EAP-FAST and LEAP. As LEAP has grown in popularity, there are a number of wireless network vendors who have subsequently claimed support for the protocol.
One of the drawbacks of LEAP is that it uses a modified version of MS-CHAP. MS-CHAP is an authentication protocol that does not strongly protect the end-user’s credentials. As a result, this information can be easily compromised using a tool called ASLEAP that was published in 2004. Due to the compromise of the protocol allowing “script kiddies” to obtain information, Cisco now recommends that clients who insist on using the LEAP protocol only do so while requiring complex passwords. When possible, the company actually recommends shifting to newer EAP protocols such as EAP-TLS, EAP-FAST, or PEAP.

What is PEAP?

PEAP (Protected Extensible Authentication Protocol) fully encapsulates EAP and is designed to work within a TLS (Transport Layer Security) tunnel that may be encrypted but is authenticated. The primary motivation behind the creation of PEAP was to help correct the deficiencies discovered within EAP since that protocol assumes that the communications channel are protected. As a result, when EAP messages are able to be discovered in the “clear” they do not provide the protection that was assumed when the protocol was originally authored.

The PEAP protocol was created as a joint effort between RSA Security, Microsoft, and Cisco Systems. The first version of the protocol to be released to the public was PEAPv0 that was bundled with Microsoft Windows XP. Subsequent versions included PEAPv1 and PEAPv2 that were included in later products.

How Does EAP-TLS Work?

EAP-TLS (EAP Transport Layer Security) was subsequently defined by IETF RFC 5216. The protocol was created as an open standard leveraging the TLS (Transport Layer Security) protocol and has found wide-spread support with the various wireless vendors on the market. It primarily consists of the original EAP authentication protocol and is still considered to be one of the most secure EAP standards on the market.
EAP-TLS does make the assumption that the end-user understands any warnings that are provided by the network or system about “false credentials” and finds widespread support amongst most if not all manufacturers of wireless software and hardware. Through mid-2005, if a vendor was able to prove compliant support with the EAP-TLS standard, then their company was able to certify compliance for receiving the right to display the WPA and/or WPA2 logos.
Some of the operating systems and companies that include native client/server implementation and support of the standard include: Avaya, Apple, Brocade, 3Com, Cisco, Foundry, Enterasys Networks, NP, Microsoft, Juniper, and other open source-based operating systems. Apple native support for the protocol can be assumed starting with Mac OS X 10.3 and newer, Windows XP and newer, the Apple iOS operating system, and Windows Mobile 2003 or newer.
Although most implementations riding on TLS such as HTTPS do not need a client side X.509 certificate, at the time of this writing many of the deployments of the standard still require this cert for operations. Many do not include a means to disable the requirement, although the IETF standard does not mandate their usage.
There has been conjecture that this requirement was implemented in order to reduce the overall adoption of EAP-TLS and the associated growth of encrypted wireless access points. By the later portion of 2012, there were efforts ongoing by Hostpad and WPA_Supplicant to add support for only requiring server-side authentication to support the protocol. This capability would permit hotspots to provide both free and encrypted WiFi access helping prevent some of the security vulnerabilities commonly found with unencrypted hotspots.
When EAP-TLS functions with a client-side certificate; however, the protocol provides the strongest authentication and overall security as compared to competing protocols. When the client-side certificate is in use, even a cracked password is not sufficient enough to break into a system that has implemented EAP-TLS. This is due to the fact of a rogue actor needing to have access to the certificate  to gain access to the system since the password is only used for encrypting the certificate itself.

What Advantages Does EAP-TTLS Provide Network Administrators?

EAP-TTLS (EAP-Tunneled Transport Layer Security) is another EAP protocol created t further extend TLS. It was originally created by Certicom and Funk Software and finds support across a wide variety of computing platforms. Although Microsoft does not include native support for the protocol in its latest operating systems to include Windows XP, Vista, or Windows 7, it only requires installation of a certified third-party Encryption Control Protocol (ECP) client to support the product. Windows 8 does include support for the protocol natively; however, it was not included in Windows Phone 8 software builds at the time of this writing.

Under EAP-TTLS, the client computer does not have a requirement to be authenticated via a signed PKI certificate (validated by a Certifying Authority) to the server to work. This aspect of the protocol helps to simplify the overall setup procedure required to leverage the protocol by eliminating the need for a certificate to be found on every network client. Once the server computing device has been authenticated to the client, the server is able to use the established “tunnel” or secure connection to further authenticate the client. The protocol can also be used with an existing authentication infrastructure and incorporate legacy passwords or databases while the tunnel helps protect the information from the “Man in the Middle” or eavesdropping attacks. At no time is the end-user’s name transmitted in the clear while using EAP-TTLS helping to improve the overall level of security of the protocol.

What is EAP-FAST?

In order to provide industry with a suitable replacement to overcome the shortcomings found with LEAP, CISCO proposed EAP-FAST (Flexible Authentication via Secure Tunneling). The protocol was created in order to help maintain the “lightweight” approach for implementation that made LEAP popular while also addressing the security weaknesses inherent in LEAP. EAP-FAST allows the optional use of security weaknesses and also makes use of a PAC (Protected Access Credential) in order to establish a TLS tunnel. The tunnel is subsequently used to verify the client credentials.

What are the Three Phases of EAP-FAST?

The EAP-FAST protocol operates in three phases:  Phase 0 (In-band provisioning), Phase 1 (Tunnel establishment), and Phase 2 (Authentication). In Phase 0, the protocol uses ADHP (Authenticated Diffie-Hellman Protocol) to share a secret that will be used during the secure Phase 1 communication. This aspect of the protocol eliminates the need to establish a primary or master secret every time a client desires to connect to the network.
During Phase 1, the protocol authenticates using PAC and then establishes a tunnel key. This ensures that both integrity of the connection and confidentiality are maintained during Phase 2. In Phase 2, the protocol authenticates the peer by exchanging credentials. The protocol can be implemented without the use of PAC files and then simply uses TLS. The protocol can be installed on Windows computer by installing a Cisco provided EAP-FAST module and has native support in OS X starting with OS version 10.4.8 and newer.