To explain what EAP (Extensible Authentication Protocol) is, we will need to have a basic understanding of IEEE 802.1X standard. What is 802.1X?
802.1X is a port based access control standard for protecting networks via authentication. It allows the flow of traffic via an open virtual port only after a successful authentication has occurred. For a failed authentication no communication is allowed and the virtual port remains shut.
The IEEE 802.1X standard defines the three basic requirements for 802.1X authentication:
- Supplicant: A software client running on the workstation.
- Authenticator: Could be a Wi-Fi access point or a wireless controller or a Switch (This is the device that will block or allow the traffic to pass)
- Authentication Server: An authentication database, usually a radius server such as Aruba Clearpass, Cisco ACS/ISE etc that validated user credentials.
802.1X is the authentication standard used for traversing EAP over wired and Wireless Local Area Networks (WLAN). It offers an encrypted EAP tunnel that thwarts hackers from capturing user login information.
Here is how it works in simple terms
- First an end device must have a supplicant installed in the network stack. It is essential as it will participate in the initial negotiation of the EAP transaction with the Authenticator (AP/Switch or Controller)
- 2ndly, the AP/Switch or Wireless controller acts as a ‘negotiator’ in the exchange of 802.1X information. The Supplicant will not connect until the client is authenticated successfully, and no other communication is allowed between the client and the Authenticator in the 802.1X exchange
- 3rdly, the Authentication Server acts as the “bouncer” of the network. It is responsible for authentication of user identities and authorization of the user requesting the service.
Now that we understand the basic concept of 801.1X lets jump in to understand what EAP is. It is a Data Link (Layer 2) protocol that offers many flavors. It was originally defined in RFC 2284 which has since been updated to RFC 3748 to support 802.1X. It was developed to enhance the Point-to-Point (PPP) authentication that provided for only simple username and password authentication without any encryption. The need for encryption gave birth to Extensible Authentication Protocol (EAP), that provides a secure method to send login information for network authentication. EAP supports many authentication methods which are defined by both, by RFCs and Vendors. We need to keep in mind that EAP only defines message formats. All protocols using EAP describe a method to encapsulate EAP messages within that protocol’s payload.
EAP-MD5 currently defined in RFC 2248 enables an authentication server to authenticate a users password by confirming an MD5 hash of his password. The authentication server sends a random challenge value to a client, and the client attests his identity by hashing the challenge and its password with MD5.There is no mutual authentication.
As per this Pulsesecure article “EAP-MD5-Challenge is typically used on trusted networks where risk of packet sniffing or active attack are fairly low.” EAP-MD5 is not considered very secure because of its vulnerabilities. EAP-MD5 is vulnerable to spoofing as it doesn’t provide server authentication.
Lightweight EAP (LEAP) is an exclusive EAP technique developed by Cisco Systems. Windows OS does not have any inherent support for LEAP in any newer versions but many third party client software still support it and is mostly built-in to wireless LAN devices.
LEAP uses an amended form of MS-CHAP, a protocol with many inherent vulnerabilities . An exploit tool called ASLEAP was written by Joshua Wright in early 2004 demonstrating a serious deficiency in this protocol. To learn more about ASLEAP please refer to “ASLEAP to Exploit Vulnerabilities in Cisco LEAP” paper by Todd Whitley at giac.org.
Cisco recommends that customers who absolutely must use LEAP should use sufficiently strong passwords. Cisco now recommends the use of newer and stronger protocols such as EAP-FAST, PEAP, or EAPTLS. LEAP does not require Server or Client certificates.
Protected EAP (PEAP) was developed jointly by Cisco Systems, Microsoft, and RSA Security though later they couldn’t agree on a single standard. With PEAP only the server needs to authenticate itself with a certificate and the encryption keys are derived from the public key in the certificate. PEAP is cheaper to implement than the TLS (Doesn’t require client side Digital certificates) and for that reason it is the most commonly used and supported. It involves a two-step authentication process.
By using a server side certificate, the EAP credentials are protected using a TLS tunnel – . Once the tunnel is built referred to as the Outer Identity (Step 1), a “bogus” username is sent to start the process after which the server presents a certificate to establish the outer identity SSL tunnel. Once established one of the various EAP methods are used to perform the inner identity(Step 2). Three important PEAP versions (as these vendors couldn’t agree on one) are:
PEAP v0 – uses EAP-MSCHAPv2 (Microsoft) – uses username / Password
PEAP v0 – uses EAP-TLS – client side certificate
PEAP v1 – uses EAP-GTC (Cisco) – uses OTP [username / Password]
EAP Tunneled Transport Layer Security (EAP-TTLS) defined in RFC 5281 is very similar to PEAP in that it has an inner and outer method. The only difference is that PEAP requires the inner authentication to be a stronger EAP type (MS-CHAP v2, EAP-GTC and TLS) , but EAP-TTLS allows a weaker EAP method (PAP, CHAP, MS-CHAP v1) to be used for inner authentication protocol.
EAP-TTLS requires a server certificate for the establishment of a tunnel for the outer identity. A client side certificate is optional and typically will depend on the inner authentication used.
EAP Transport Layer Security (EAP-TLS) Defined in RFC 5216 uses the Transport Layer Security (TLS) to secure communication to a RADIUS authentication server or another type of authentication server. Unlike most TLS implementations such as HTTPS EAP-TLS requires the client to use X.509 certificates.
EAP-TLS is still one of the most safe EAP standards and is braced by majority of wireless vendors. The EAP-TLS derives its power from a necessary requirement of a client-side certificate. Without having access to client side private key, an intruder even with a compromised password would not be able to break into EAP-TLS enabled systems.
To determine which EAP method to use in your organization, you must first determine the following:
if your existing client (supplicant) and the server would support your preferred method of choice.
Cost is the 3rd option to consider as implementing solution with client-server digital certificates could be expensive.
- what level of security is required
- if your existing client (supplicant) and the server would support your preferred method of choice
- Cost for implementing and managing the solution ( client-server digital certificates could be expensive)
References