Re: [saag] Feedback on Salted EAP draft

[Sam Hartman <[e-mail]>]

>>>>> "Christian" == Christian Huitema <[e-mail]> 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.