EAP-pwd
acronymnetworkingsecuritycryptography
Stands for: EAP Authentication Using Only a Password (RFC 5931, EAP Type 52)
EAP Authentication Using Only a Password, RFC 5931 at EAP Type 52: a password-authenticated key exchange that is secure against offline dictionary attacks even with a weak password, and needs no certificates or PKI on either side.
RFC 5931 (Harkins and Zorn, August 2010, Informational) presents EAP-pwd as "a robust authentication method that is secure even when used with a weak password in the presence of a strong adversary". The password "may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary", and the method still gives an eavesdropper nothing to attack offline: each run of the protocol tests exactly one guess, which is the property that distinguishes a password-authenticated key exchange from a challenge-response such as MS-CHAP-V2. The exchange has three parts, Identity, Commit and Confirm, authenticates both sides, derives the MSK and EMSK that 802.1X needs for link keys, and does so without certificates, so there is no server certificate for a client to fail to validate. Its limits are deployment ones: the server must hold the password or a form of it the method can use, support in supplicants and servers has been narrower than for the tunnelled methods, and the property it offers, no offline guessing, is the one WPA3's handshake later brought to personal networks.
Most password methods in the EAP family protect the password by hiding the exchange inside a TLS tunnel; EAP-pwd protects it by changing the mathematics so that there is nothing useful to hide. RFC 5931, published in August 2010 by Harkins and Zorn as an Informational document, specifies EAP Authentication Using Only a Password at EAP Type 52 and states its claim directly: it is "a robust authentication method that is secure even when used with a weak password in the presence of a strong adversary". The RFC is explicit that the password "may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary", and that the method still resists offline attack.
The mechanism is a password-authenticated key exchange. Rather than sending a function of the password that a listener can test against candidate passwords at leisure, which is what every challenge-response does, the two sides first use their identities and the agreed ciphersuite "to fix an element in the negotiated group called the Password Element", derived from the password, and then prove in the Commit and Confirm exchanges that each holds the same element. The RFC states the requirement it meets: "any advantage an adversary can gain must be directly related to the number of interactions she makes with an honest protocol participant and not through computation", and in its security considerations, "the best advantage an attacker can gain in a single active attack is to determine whether a single guess at the password was correct". An eavesdropper learns nothing to test offline; an active attacker buys one guess per run, and the server can count runs and lock the account. The WPA3 entry describes the same property arriving in personal Wi-Fi, where the older handshake had allowed exactly the offline guessing this design forbids.
Two consequences follow for a network designer. The first is that EAP-pwd needs no certificates and no PKI: there is no server certificate, so there is no client-side validation setting to be left off, which removes the failure that undermines PEAP and EAP-TTLS deployments. The method authenticates both sides, in the RFC's security claims "by proving possession of a shared password", and an MSK and EMSK are derived from the shared secret, so it is complete on its own. The second is that the server must have the password in a form the method can use, which is a question to ask of the directory before choosing it.
The method's adoption has been narrower than its properties might suggest. The tunnelled methods arrived first, were built into the dominant operating-system supplicants and the servers that matched them, and solved the password problem well enough for the organisations that could manage certificate validation; EAP-pwd's support in clients and servers has been partial, and sites choosing it have to confirm both ends. Where it is available it is the method that lets a password be used over the air without a PKI and without the offline exposure of MS-CHAP-V2, and that is a short list.
Also known as: eap pwd, dragonfly eap, password-only eap