EAP-MSCHAPv2
acronymStands for: Microsoft Challenge Handshake Authentication Protocol version 2 (RFC 2759), carried inside EAP
Microsoft's CHAP version 2 of RFC 2759, a challenge-response that proves a password without sending it and adds mutual authentication, carried inside EAP and, in practice, inside the PEAP or EAP-TTLS tunnel.
RFC 2759 (Zorn of Microsoft, January 2000, Informational) specifies MS-CHAP-V2. Its advance over the first version is mutual authentication, achieved "by piggybacking a peer challenge on the Response packet and an authenticator response on the Success packet": the client answers the server's challenge and sends its own 16-octet Peer-Challenge; the 24-octet NT-Response is computed from the challenges and an MD4 hash of the password using DES; the server then proves it knew the password too. The method needs the server to hold the NT hash of the password, which is why it fits Active Directory and does not fit directories that store passwords in other forms. On its own, over the air, the exchange can be captured and attacked offline, and the RFC already advises that the authenticator "SHOULD limit the number of password retries"; wrapped as an EAP method inside PEAP (PEAP-MSCHAPv2) or EAP-TTLS, the tunnel hides the exchange from eavesdroppers, which is the only configuration in which it should appear on a network today. The tunnel protects nothing if the client does not validate the server's certificate.
MS-CHAP-V2 is the challenge-response at the bottom of most password-based enterprise Wi-Fi, and it predates Wi-Fi: RFC 2759, published in January 2000 by Glen Zorn of Microsoft as an Informational document, specifies it as a PPP authentication protocol, Microsoft's second extension of CHAP, for dial-up and VPN clients. The RFC describes the improvement over version 1 as mutual authentication, obtained "by piggybacking a peer challenge on the Response packet and an authenticator response on the Success packet". The server sends a challenge; the client's Response packet carries a 16-octet Peer-Challenge of its own and a 24-octet NT-Response derived from both challenges and an MD4 hash of the user's password, with DES as the cipher; on success the server returns an authenticator response that proves it also knew the password. Neither side ever sends the password, and the client learns whether the server was genuine, which CHAP alone could not tell it.
The protocol's dependence on the NT hash shaped where it could be used. Because the server must compute the same function of the password that the client did, it has to hold the password in the MD4 form Windows stores, or the clear password; a directory that stores salted hashes of another kind cannot verify MS-CHAP-V2 at all. That is why the method pairs naturally with Active Directory, why RADIUS servers that front a domain speak it fluently, and why sites with an LDAP directory of a different lineage are steered towards EAP-TTLS with PAP inside the tunnel instead.
As an EAP method, MS-CHAP-V2 is carried in Request and Response packets and known as EAP-MSCHAPv2; its proper home is inside a tunnel. The challenge-response exchange, captured from the air, can be attacked offline against the password, and the cryptography of the response is DES on a 1990s design; RFC 2759 itself advises that the authenticator "SHOULD limit the number of password retries" against online guessing, and the offline exposure is addressed only by hiding the exchange. PEAP's expired draft describes the inner EAP methods it protects, and RFC 5281 lists MS-CHAP-V2 among the legacy methods EAP-TTLS can carry; PEAP with EAP-MSCHAPv2 inside became the default enterprise Wi-Fi configuration for Windows networks because it combined a method the domain could verify with a tunnel the air could not read.
The security of that arrangement is therefore the tunnel's, and the tunnel's security is the client's certificate validation. An attacker who can persuade a supplicant to complete a TLS tunnel with an impostor access point receives the MSCHAPv2 challenge-response inside it and can attack it offline, which turns a wireless network into a password-collection device; the only defence is a supplicant configured to trust a named server certificate and nothing else. Engineers asked why their security team wants certificates on clients, the EAP-TLS answer, can point at this paragraph: with EAP-TLS there is no password exchange to collect. Where passwords remain, as they do on most networks, EAP-MSCHAPv2 inside PEAP with validation enforced on every client is the configuration, and the retries limit on the server is the second control the RFC already asked for.
Also known as: ms-chap v2, mschapv2, ms-chapv2, ms-chap-v2, eap-mschap-v2