PEAP
acronymStands for: Protected Extensible Authentication Protocol (EAP Type 25)
Protected EAP, EAP Type 25: a TLS tunnel authenticated by the server's certificate, inside which a second, weaker EAP method (in practice almost always EAP-MSCHAPv2) authenticates the user with a password.
PEAP solves the problem that passwords cannot travel safely in a bare EAP exchange: part one is a TLS handshake in which the server presents a certificate and the client checks it, and part two runs zero or more EAP methods inside the resulting tunnel, protected from eavesdropping and from a rogue authenticator. The specification, draft-josefsson-pppext-eap-tls-eap-10, Protected EAP Protocol (PEAP) Version 2, of 15 October 2004, is an expired Internet-Draft by Palekar, Simon, Salowey, Zhou, Zorn and Josefsson; it assigns Type 25 and describes the goals as protection against rogue authenticators, protection of the confidentiality and integrity of the inner exchange, and identity privacy for the peer. It mandates a Crypto-Binding TLV that ties the inner method to the outer tunnel. The entire security of a PEAP deployment rests on one client setting: whether the supplicant validates the server certificate and the name on it. A client that does not will complete the tunnel with any access point that offers a certificate, and hand its MSCHAPv2 exchange to whoever is on the other end. PEAP with EAP-MSCHAPv2 is the method that made enterprise Wi-Fi possible with Active Directory passwords, and the one that most needs that setting checked.
Protected EAP was designed for a world in which the thing an enterprise had was a password database and the thing it wanted was wireless authentication. Bare EAP methods that use passwords expose them, or at least expose a challenge-response that can be attacked offline, to anyone in radio range; a certificate for every client, the EAP-TLS answer, was more administration than most organisations would take on. PEAP's answer was to borrow TLS for the first half of the conversation. The draft, draft-josefsson-pppext-eap-tls-eap-10 of 15 October 2004, titled Protected EAP Protocol (PEAP) Version 2 and written by Palekar, Simon, Salowey, Zhou, Zorn and Josefsson, describes it in two parts. In part one the server responds to the peer with a PEAP/Start, a TLS handshake follows using certificate-based ciphersuites, and the server is authenticated by its certificate; the peer may or may not present one. In part two, inside the tunnel the handshake produced, "zero or more EAP methods" run. In practice the inner method is almost always EAP-MSCHAPv2, which is why the combination is written PEAP-MSCHAPv2 and why it maps so naturally onto a Windows domain.
The draft states the goals plainly. PEAPv2 "uses TLS to protect against rogue authenticators, protect against various attacks on the confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity privacy". Identity privacy matters because the EAP Identity exchange that starts every 802.1X conversation happens before any tunnel exists: the outer identity is sent in the clear, and PEAP lets it be a placeholder, with the real username disclosed only inside the tunnel. The draft also makes the Crypto-Binding TLV mandatory, a construction that proves to both sides that the peer who completed the inner method is the same peer who built the outer tunnel; without such binding, tunnelled methods are open to a man-in-the-middle who runs the inner method with the victim and the outer tunnel with the server.
The status of the document is worth recording accurately. The specification is an expired Internet-Draft; PEAP reached ubiquity through implementations, above all the Windows supplicant and the server products that matched it, rather than through a published standard, and the version most widely deployed is not the one the draft describes as version 2. For a practitioner the consequence is that interoperability details live in vendor documentation and in testing, not in an RFC that can be cited against a vendor.
The security of PEAP is almost entirely a client configuration question. The tunnel protects the inner exchange only against parties outside the tunnel; if the supplicant accepts any server certificate, the tunnel can be terminated by an impostor access point, and the inner MSCHAPv2 exchange, challenge and response, is delivered to the attacker, who can attack it offline. Every supplicant therefore has a setting to validate the server certificate, usually with a list of trusted certification authorities and an expected server name, and the difference between a secure PEAP deployment and a credential-harvesting opportunity is whether that setting is enforced, by policy, on every device. Devices outside management, personal phones joining a corporate SSID, are where it is most often left off, and they are also the devices whose users will click through any warning.
Against its siblings, PEAP sits between EAP-TLS, which authenticates the client with a certificate and has no password to steal, and EAP-TTLS, which also builds a TLS tunnel but allows non-EAP legacy methods such as PAP and CHAP inside it. TEAP, the standards-track tunnel method of RFC 7170, was written to replace this generation with one that can chain user and machine authentication and provision credentials inside the tunnel. Where PEAP remains, and it remains almost everywhere passwords are used for Wi-Fi, the design questions are the inner method, the certificate on the server, and the validation on the clients.
Also known as: protected eap, peapv0, peap-mschapv2, peap mschapv2