Re: l2tp as ipsra solution

[David Jablon <dpj@xxxxxxxxxxxxx>]

At 10:57 AM 6/21/00 -0700, CHINNA N.R. PELLACURU wrote:
>On Wed, 21 Jun 2000, David Jablon wrote:
>> Off-line brute-force attack is a serious consideration for any protocol.
>> Unconstrained on-line attack can be prevented by a server by counting
>> bad access attempts, regardless of the protocol.
>
>I don't think any security consious customer is still using protocols that
>are vulnerable to passive off-line brute-force attacks.

Just a few problems here ...

(1)  Why limit concern to just "passive" off-line brute-force attacks?

(2)  Many security conscious customers DO NOT HAVE A CLUE ABOUT
CRYPTO, but they still want it, for good reasons.

(3)  Most password-based products, and standards for that matter,
do not prevent off-line brute force attacks.

(4)  Lots of people care, and know what problems to care about, and some even
know what solutions are possible, but still cannot find suitable products.

For those who care, here's some elaboration of these points ...

It's conservative to presume that an enemy who can read packets
can also write them.  Most deployed password-based protocols and
products are vulnerable to off-line brute-force attack, whether it's
passive, requiring one to receive a few packets, or active, in that it
also means one has to send a few packets.

Customers want the benefits of crypto without having to think about
how or why.  Some go to the trouble to learn what they can, but at some point
they almost always end up trusting their vendors to do the "right thing".
Yet, sadly, I've heard many vendors, even in this forum, complain that there's
no "market demand" for the best crypto.

I still say that latent demand is out there. Take me. Your average user. (Sure. :-)
I use clear-text and crude hashed-password methods almost every day, not
really by choice, but because the available selection of industry standard
products and services doesn't give me any other choice.

Anyway, as for the next point ...

> So, there is no value in providing a migration path from a protocol that
> is vulnerable to passive off-line bruteforce attacks to a PKI based
> authentication. I don't think these customers will ever migrate to PKI,
> if they haven't migrated to a much secure legacy authentication.

Wow.  Count me among those who strongly disagree.

> I don't think these customers are necessarily dumb. It may be that the
> customer needs just the amount of security, that those simple systems
> provide. I guess it depends on what they are trying to protect.

I think it really depends on what they know they can get.

Lots of customers are comparison shoppers.  Sure they make crude
judgements, but they tend to want the best that they can get at a fair price. 
Let the vendor with the longest checklist win!  :-)

>> > [...] I guess, the off-line dictionary attack threat model is too simple to
>> >guard against, because there is a general assumption that the legacy
>> >authentication infrastructure(server) is reasonably secure, and doesn't
>> >have to be connected to the Internet for everybody to hack it, and take
>> >the information to do off-line dictionary attacks.
>> 
>> "Too simple to guard against"?
>> 
>> This confuses attacks on stored data, with the bigger threat of attacks
>> on protocol messages.  Unlike the password file, the protocol messages
>> are sent over the Internet.  That's the model where you need to defend
>> against unconstrained guessing.
>
>I made the above assumption.

Which one?

>> Machine authentication is a simpler problem, since machines,
>> once properly configured, have no trouble remembering and handling
>> big random secrets.  People have trouble with this, so any process for
>> secure user authentication must deal with this added constraint.
>
>That is my point, here the user is not involved at all in providing the
>credentials for authentication, and thus that should be the discriminator
>between "user authentication" and "machine authentication". If the user is
>involved, like if he has to provide a password (from his memory, from a
>PostIt TM, in his wallet), or if his retina is scanned, or thumbprint is
>scanned, then it should be considered "user authentication". Just becaue
>the process of retina scan can have a lot of entropy, it can't be
>considered "machine authentication.

At this we agree.

But discussing the entropy in biometric data opens up a wholly different
can of worms.  I wouldn't consider biometrics to be a significant part
of the legacy infrastructure.  It's also much different than the well-understood
ways to leverage a password, or a SecurID hash result,
as a user authentication key over a network.

---------------------------------------------------
David P. Jablon
Integrity Sciences, Inc.
dpj@xxxxxxxxxxxxxxxxxxxxx
www.IntegritySciences.com