Extensible Authentication Protocol (EAP)
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. The WPA and WPA2 standard has officially adopted five EAP types as its official authentication mechanisms.
There are two varieties of EAP: one for wireless and one for LAN connections, commonly called EAP over LAN (EAPoL).
One of the concerns in wireless is allowing a WLAN client to communicate to devices behind an AP. Three standards define this process: EAP, 802.1x, and Remote Authentication Dial In User Service (RADIUS). EAP defines a standard way of encapsulating authentication information, such as a username and password or a digital certificate that the AP can use to authenticate the user. 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”. EAP is basically an extension of the Point-to-Point Protocol (PPP) and one of the first forms of EAP was EAP-MD5, which used Challenge Handshake Authentication Protocol (CHAP) for authentication. 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. Here are some of the extensions of EAP:
Supports CHAP with static passwords for authentication. 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
Supports x.509v3 digital certificates for authentication. 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.
(Lightweight EAP) Supports static passwords and allows for per-session WEP keys. It provides mutual authentication and session key establishment between an EAP peer and an EAP server
(Protected EAP) Supports static and one-time passwords (OTP), where SSL secures the connection so that MS-CHAP can be used for authentication and the username and password are encrypted to protect them from an eavesdropping attack (a digital certificate is required only on the server). 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. So wide is the marketplace adoption of PEAP that even Funk Software, the inventor and backer of EAP-TTLS, had little choice but to support PEAP in their server and client software for wireless networks.
Supports faster authentication, where a shared secret key is used to encrypt authentication information (similar to PEAP)
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.