Subject: RE: Question about EAP payload

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Sun, 23 Feb 2003 22:58:27 -0500

Clarification...when I said "password in the clear",
it isn't really "in the clear". It's encrypted using
the IKE key created in messages 1 and 2. But from
Bob's point of view, Alice is just sending a raw
password, and Bob has a database of hashed passwords.
I think Phil's response was based on my being
less than clear in my original post (below).

Radia

Radia Perlman - Boston Center for Networking wrote:
> I've been reading the new draft of IKEv2, which
> has not yet been announced, but has been submitted.
> 
> Anyway, under EAP payload, there seems to be
> "OTP", "MD5-challenge", and "generic token card".
> But there doesn't seem to be anything there
> for just plain sending a name and password.
> 
> Is this intentional, perhaps because MD5-challenge
> is considered better? (though it requires the
> server to store a password-equivalent, whereas
> sending password in-the-clear allows the
> server to store hashes of passwords)
> 
> Or is name/password really covered under "generic
> token card", because EAP just passes text back
> and forth, and the server could ask for name
> and password, and the client could send it?
> 
> Radia

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 Feb 2003 19:45:35 -0800

> server to store hashes of passwords)

I have not looked at the MD5 challenge, but I did write
the original HTTP digest scheme, we had these arguments
ad nauseam and lost, so HTTP throws out base 64 
passwords...

It makes little sense to attempt to secure a network 
protocol with a technique that is vulnerable to a network
attack.

If your network is secure enough to send the
password enclair then you do not need IPSEC. 

There is no way you can have secure password storage 
and network security unless you go to public key.

The one way encrypted password technique adds some 
security but not really very much. The password file
will always be vulnerable to a dictionary attack,
a salt only causes minor inconvenience at this point.

So the real tradeoff is a choice between strong on the
wire protection and depending on the security of the
password file and zero security on the wire and depending
a heck of a lot but not quite so much on the security of
the password file.

The digest scheme has one other feature that is worth
making an effort to preserve, the domain is used to salt
the hash. This means that if a password file is compromised
it does not compromise any zone other than the one that
compilled it even though we know that the users will share
all their passwords on all their accounts.

		Phill