EAP: The Basics

Community Manager
Community Manager

Back to the future with this Airheads Online article from June 2007

 

The Extensible Authentication Protocol (EAP) or RFC 3748 is, very simply, a transport protocol that has been optimized for authentication. It is important to note that EAP is not, in itself, an authentication protocol, even though it is often referred to that way. The EAP protocol expands on authentication methods used by the Point- to-Point Protocol (PPP). EAP can support multiple authentication mechanisms such as token cards, smart cards, digital certificates, one- time passwords, and public key encryption. This section will focus on the popular EAP/authentication combinations and discuss how each works within a wireless security framework. 
 
In this article, EAP is always used in a wireless LAN context – therefore a more correct name for the EAP protocol is EAPOL, or EAP over LAN. 
 

How EAP Works

Here's how it works: a user requests connection to a wireless network through an access point. The access point requests identification data from the user and transmits that data to an authentication server. The authentication server asks the access point for proof of the validity of the credentials. After the access point obtains that verification from the user and sends it back to the authentication server, the user is connected to the network as requested.  There are many different types or “flavors” of EAP. The difference between these is in how the identification credentials are requested and transmitted.


EAP Flavors

 There are many different combinations of EAP and authentication types. A complete listing is available at http://www.iana.org/assignments/eap- numbers. The following list offers a description of the most popular versions as well as some design considerations:

  • EAP-MD-5 (Message Digest) is an EAP authentication type that provides base-level EAP support. EAP-MD-5 is typically not recommended for wireless LAN implementations because it may allow a user's password to be derived. It also provides for one-way authentication only - there is no mutual authentication of wireless client and the network. More importantly it does not provide a means to derive dynamic, per session wired equivalent privacy (WEP) keys
  • EAP-TLS (Transport Layer Security) provides for certificate-based and mutual authentication of the client and the network. It relies on client-side and server-side certificates to perform authentication and can be used to dynamically generate user-based and session-based WEP keys to secure subsequent communications between the WLAN client and the access point. One drawback of EAP-TLS is that certificates must be managed on both the client and server side. For a large WLAN installation, this could be a very cumbersome task EAP-TTLS (Tunneled Transport Layer Security) was developed by Funk Software and Certicom, as an extension of EAP-TLS. This security method provides for certificate-based, mutual authentication of the client and network through an encrypted channel (or "tunnel"), as well as a means to derive dynamic, per-user, per-session WEP keys. Unlike EAP-TLS, EAP-TTLS requires only server-side certificates
  • LEAP (Lightweight Extensible Authentication Protocol) is a proprietary EAP authentication type used primarily in Cisco Aironet WLANs. It encrypts data transmissions using dynamically generated WEP keys, and supports mutual authentication. Like WEP, LEAP has also been broken with publicly available tools; compromising user credentials and accounts.
  • EAP-FAST (Flexible Authentication via Secure Tunneling) is another proprietary EAP developed by Cisco.  Instead of using a certificate, mutual authentication is achieved by means of a PAC (Protected Access Credential), which can be managed dynamically by the authentication server.  The PAC can be provisioned (distributed one time) to the client either manually or automatically.  EAP-FAST has seen some popularity, but has been shown to have security issues.
  • PEAP (Protected Extensible Authentication Protocol) provides a method to transport securely authentication data, including legacy password-based protocols, via 802.11 wireless networks. PEAP accomplishes this by using tunneling between PEAP clients and an authentication server. Like the competing standard, Tunneled Transport Layer Security (TTLS), PEAP authenticates wireless LAN clients using only server-side certificates (although client certificates are allowed as an option), thus simplifying the implementation and administration of a secure wireless LAN. There are two competing versions today: PEAPv0 (PEAP-EAP-MSChapv2) from Microsoft and PEAPv1 (PEAP-GTC) from Cisco. Microsoft PEAP is considered the mainstream PEAP and user authentication protocol. As mentioned before, PEAP requires a tunneling protocol that actually performs the authentication.
  • EAP-MSCHAP2 is an EAP encapsulation of MS-CHAP-v2 (RFC- 2759). MS-CHAP-v2 requires a user name and password. This protocol is rarely used on its own. Instead it is typically used inside of a PEAP-encrypted tunnel as described above
  • EAP-GTC (Generic Token Card) is an alternative to EAP-MSCHAPv2 and is used in Cisco’s PEAPv1 protocol. This protocol makes use of digital certificates  to establish the inner tunnel

Each combination of EAP plus an authentication type offers a unique approach to authentication. Which one to use is generally determined by the level of security required, the amount of administrative/management overhead desired, and the limitations of the clients (supplicants) that will implement EAP as well as the capabilities of the RADIUS servers used in the deployment. 

The following table provides a side-by-side comparison of the EAP types: 
 

 

 Feature/Benefit MD5 TLS TTLS PEAP LEAP FAST GTC
Client-side authentication/certificate required No Yes No No No No (PAC) No
Server-side authentication/certificate required No Yes Yes Yes No No (PAC) Yes
Authentication method  One-way Mutual Mutual Mutual Mutual Mutual Mutual
Deployment complexity Low High Moderate Moderate Moderate Moderate to high Moderate
 Security strength Low Highest High High Low Medium to high High

 

 
EAP Summary

 Based on this table, we can draw some reasonably clear conclusions:

  • TLS, while very secure, requires client certificates to be installed on each wireless workstation. Installing and maintaining a PKI infrastructure must be part of any TLS installation and does create more administrative overhead. If a working PKI already exists, TLS is a very good option
  • TTLS addresses the certificate issue by tunneling TLS, and thus eliminating the need for a certificate on the client side. If a working PKI structure does not exist, this is an option worth considering
  • LEAP is one of the earliest EAP implementations; however inherent security flaws have now made it less popular and it is not recommended
  • EAP-FAST promises to be as easy as LEAP but as secure as PEAP, however it has different implementation and operational modes that, ultimately, offer a compromise. The highest security, ultimately, ends up looking very similar to PEAP – without the widespread client support that PEAP enjoys
  • PEAP works similarly to EAP-TTLS in that it does not require a certificate on the client side and is natively supported by many client operating systems. PEAP is the protocol of choice when client-side certificates are not required. When deploying PEAP, EAP-MSChapv2 is likewise the protocol of choice as compared to EAP-GTC. This is primarily due to the fact that EAP-GTC it is not supported by Microsoft’s IAS RADIUS server or the native Windows supplicant
Version history
Revision #:
1 of 1
Last update:
‎02-03-2012 03:59 PM
Updated by:
 
Labels (1)
Contributors
Comments
vin.singh4u

Hello, I wanted to know that in an EAP exchange is the request message necessary to be sent by the authenticator to peer? Can peer send the EAP request message first as part of actual authentication exchange?

Can I have this sequence: 1) Request identity sent by authenticator and response by peer as usual. 2)Request EAP start by authenticator and response by peer as usual. 3) * Request from peer for authentication with data and response by authenticator. 4) * Request from authenticator for authentication with data and response from peer. 5) EAP success from authenticator to peer Can such a sequence be allowed as part of 802.1x/EAP mechanism?
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: