>>>>> "Christian" == Christian Huitema <huit...@microsoft.com> writes:
Christian> On Tuesday, July 14, 2015 9:01 AM, Kathleen Moriarty wrote: >> Is there interest in reviewing this draft? Sam pointed out the >> importance of moving this work forward, it would be helpful to >> have volunteers to review the work and also to understand the >> level of interest (if any) before this goes forward as AD >> sponsored. Christian> The draft is short and clear enough, but it acknowledges Christian> a pretty big security issue: "the salted password from a Christian> compromised database can be used directly to impersonate Christian> the client-- there is no dictionary attack needed to Christian> recover the plaintext password." If you want to use an pre-existing salted database and you want to use some cryptographic mechanism rather than transporting plaintext passwords over encrypted transport, I think you have to accept that particular vulnerability or something similar. To defeat this you'd need some function that the peer, knowing the full plaintext password could compute, and the EAP server knowing the salted database entry could verify, but an attacker could not verify. Most of the ways I can think of of doing that would defeat other properties that the eap-pwd designers would probably consider important. You might be able to do something with a secondary authentication after the primary authentication had succeeded (vulnerable to attackers who own your database). Of course once an attacker gets your database, they could impersonate the server towards the peer and defeate this secondary authentication. However if the plaintext password were strong enough they could not log into the original server. Which is to say there are probably different tradeoffs that could be made, but the ones in this protocol are ones that reasonable folks have considered acceptable in the past. I'll note that password-protected Kerberos as described in RFC 4120/6112 is an example of another system with this vulnerability. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu