[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: l2tp as ipsra solution



As you look at the legacy, it might also be good to keep an eye on the future.

I would hope that a simple IPSRA "black box" model encompasses a range of
both legacy and emerging protocols, using both legacy and new database
formats, including clear-text, hashed-passwords, and better.

Expect that new roaming protocols for password-only authentication
will address both cracking attacks on network messages *and* cracking of
stored verifiers.

-- David


At 11:18 AM 6/14/00 -0400, Daniel Fox wrote:
>But I think we need to think more generically.  Are there *any* authentication
>databases that do not protect the secrecy of one-way-encryption output?  After
>all, that is the point of one-way encryption, that you do not need to keep it
>secret.
>
>This goes to the very heart of simple password exchanges.  If you are more
>worried about people snooping your databases than about snooping the wire, then
>you chose a simple password exchange (like PAP), and store the password in the
>database one-way encrypted.  On the other hand, if you are more worried about
>people snooping the wire, then you chose a challenge-response exchange (like
>CHAP), and store the password in the database in the clear.
>
>Don't we need to support both types of authentication exchanges?
>
>An interesting wrinkle to this is that PAP has been deprecated (a mistake, IMHO,
>but a reality nonetheless) by the PPP WG.  Does this mean that our scheme of
>supporting legacy authentication mechanisms can't take PAP into account?  But
>then there's LDAP...
>
>Henry Spencer wrote:
>
>> On Wed, 14 Jun 2000, Daniel Fox wrote:
>> > It's worse than that.  There are some authentication mechanisms (PAP
>> > with /etc/passwd) that do not store the cleartext password (the pre-shared
>> > secret) on the server, but a one-way hash encryption.  Therefore,
>> > there are some legacy secrets that cannot be downloaded...
>>
>> That problem can be circumvented by thinking of the situation differently:
>> the shared secret is the output of the one-way encryption, not the
>> original password.  (This does assume that the one-way-encryption output
>> really has been kept secret -- as opposed to trusting entirely in the
>> one-way encryption to preserve secrecy -- but that's normal these days...)

---------------------------------------------------
David P. Jablon
Integrity Sciences, Inc.
+1 508 898 9024
dpj@xxxxxxxxxxxxxxxxxxxxx
www.IntegritySciences.com