EAP-pwd Moving Towards a Deployable Standard
Contents:
What is EAP-pwd?
The Geant project to address shortomings in current RFC
What is EAP-pwd?
EAP-pwd is an EAP method that addresses the problem of password-based authenticated key exchange-- using a possibly weak password for authentication to derive an authenticated and cryptographically strong shared secret.
EAP-pwd is an extremely efficient EAP method which has the pot
The security of EAP-pwd relies upon each side, the peer and server, producing quality secret random numbers. A poor random number chosen by either side in a single exchange can compromise the shared secret from that exchange and open up the possibility of dictionary attack.
Producing quality random numbers without specialized hardware entails using a cryptographic mixing function (like a strong hash function) to distill entropy from multiple, uncorrelated sources of information and events.
EAP-pwd defines three message exchanges, an Identity exchange, a Commit exchange and a Confirm exchange. A successful authentication is shown below.
The peer and server use the Identity exchange to discover each other's identities and to agree upon a ciphersuite to use in the subsequent exchanges; in addition, the EAP Server uses the EAP-pwd-ID/Request message to inform the client of any password preprocessing that may be required. In the Commit exchange the peer and server exchange information to generate a shared key and also to bind each other to a particular guess of the password. In the Confirm exchange the peer and server prove liveness and knowledge of the password by generating and verifying verification data.
+--------+ +--------+
| | EAP-pwd-ID/Request | |
| EAP |<------------------------------------ | EAP |
| peer | | server |
| | EAP-pwd-ID/Response | |
| |------------------------------------> | |
| | | |
| | EAP-pwd-Commit/Request | |
| |<------------------------------------ | |
| | | |
| | EAP-pwd-Commit/Response | |
| |------------------------------------> | |
| | | |
| | EAP-pwd-Confirm/Request | |
| |<------------------------------------ | |
| | | |
| | EAP-pwd-Confirm/Response | |
| |------------------------------------> | |
| | | |
| | EAP-Success | |
| |<------------------------------------ | |
+--------+ +--------+
Figure: A Successful EAP-pwd Exchange
The components of the EAP-pwd-* messages are as follows:
EAP-pwd-ID/Request
Ciphersuite, Token, Password Processing Method, Server_ID
EAP-pwd-ID/Response
Ciphersuite, Token, Password Processing Method, Peer_ID
EAP-pwd-Commit/Request
Scalar_S, Element_S
EAP-pwd-Commit/Response
Scalar_P, Element_P
EAP-pwd-Confirm/Request
Confirm_S
EAP-pwd-Confirm/Response
Confirm_P
For the full RFC see:
http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-14
Geant Project to Address Shortcomings
JRA3-T1's evaluation of EAP-pwd for user authentication concluded that it contained many positive properties, but also a few drawbacks.
One of those drawbacks was that the storage of the password on the IdP side (Home organisation) had to be either one of cleartext or NT-Hash (both of which being somewhat lame), and that support for more hashes and/or salting would need a new RFC. Stefan Winter of RESTENA reports that we're on our way to issue that new RFC. See http://tools.ietf.org/html/rfc5931
You'll notice that the following storage backends would be supported when this draft becomes an RFC:
- a random salt with SHA-1
- a random salt with SHA-256
- a random salt with SHA-512
(length of the salt is not infinite, but some three-digit number)
