Deploying 802.1X for WLANs: EAP Types Page 1

Deploying 802.1X for WLANs: EAP Types Page 1

By Lisa Phifer

September 10, 2003

Knowing the framework of how 802.1X authentication works is just the beginning — you also need to know the types of authentication protocols available, and who supports them, to make wise purchasing decisions.

Part one of this primer explained how IEEE 802.1X provides a framework for authorizing station access to Ethernet and wireless LANs. 802.1X uses the Extensible Authentication Protocol (EAP) to relay port access requests between LAN stations (“supplicants”), Ethernet switches or wireless access points (“authenticators”), and RADIUS servers (“authentication servers”). This article explains how select EAP types and what you’ll need in order to add 802.1X to your wireless LAN.

Understanding EAP Types

Different types of EAP have been defined to support authentication methods and associated network security policies. The most widely-deployed EAP types are summarized in the following table.

EAP-MD5LEAPEAP-TLSEAP-TTLSPEAP
Server AuthenticationNonePassword HashPublic Key (Certificate)Public Key (Certificate)Public Key (Certificate)
Supplicant AuthenticationPassword HashPassword HashPublic Key (Certificate or Smart Card)Related Articles802.1X Port Access Control for WLANsLEAPing Over Wireless LANsLWAPP: Standardizing Centralized Wi-Fi ManagementSearching for Wi-Fi Security SolutionsCHAP, PAP, MS-CHAP(v2), EAPAny EAP, like EAP-MS-CHAPv2 or Public Key
Dynamic Key DeliveryNoYesYesYesYes
Security RisksIdentity exposed, Dictionary attack, Man-in-the-Middle (MitM) attack, Session hijackingIdentity exposed, Dictionary attackIdentity exposedMitM attackMitM attack; Identity hidden in Phase 2 but potential exposure in Phase 1

EAP-MD5 lets a RADIUS server authenticate LAN stations by verifying an MD5 hash of each user’s password. This is a simple and reasonable choice for trusted Ethernets where there is low risk of outsider sniffing or active attack. However, EAP-MD5 is not suitable for public Ethernets or wireless LANs because outsiders can easily sniff station identities and password hashes, or masquerade as access points to trick stations into authenticating with them instead of the real deal.

Cisco’s Lightweight EAP (LEAP) goes a notch beyond EAP-MD5 by requiring mutual authentication and delivering keys used for WLAN encryption. Mutual authentication reduces the risk of access point masquerading — a type of Man-in-the-Middle (MitM) attack. However, station identities and passwords remain vulnerable to attackers armed with sniffers and dictionary attack tools. LEAP is mostly attractive to organizations that use Cisco access points and cards and want to modestly raise the security bar.

EAP with Transport Layer Security (EAP-TLS) is the only standard secure option for wireless LANs at this time. EAP-TLS requires the station and RADIUS server to both prove their identities via public key cryptography (i.e., digital certificates or smart cards). This exchange is secured by an encrypted TLS tunnel, making EAP-TLS very resistant to dictionary or other MitM attacks. However, the station’s identity — the name bound to the certificate — can still be sniffed by outsiders. EAP-TLS is most attractive to large enterprises that use only Windows XP/2000/2003 with deployed certificates.

EAP with Tunneled TLS (EAP-TTLS) and Protected EAP (PEAP) are Internet Drafts that have been proposed to simplify 802.1X deployment. Both require certificate-based RADIUS server authentication, but support an extensible set of user authentication methods. Organizations that have not yet issued certificates to every station and don’t want to just for 802.1X can use Windows logins and passwords instead. RADIUS servers that support EAP-TTLS and PEAP can check LAN access requests with Windows Domain Controllers, Active Directories, and other existing user databases. From a sniffing perspective, these options are just as strong as EAP-TLS. However, user passwords are still more likely to be guessed, shared, or disclosed through social engineering than client-side certificates.

Continue to Page 2

Latest posts by Eric Sandler (see all)

Give a Comment