Re: l2tp as ipsra solution

["CHINNA N.R. PELLACURU" <pcn@xxxxxxxxx>]

On Wed, 21 Jun 2000, David Jablon wrote:

> 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.


So, the real goal of the PIC protocol, is to transperantly raise the bar
for security, even though the customer still wants to use insecure legacy
authentication systems. So, even if the customer really wants a less
secure system, we transperantly give them the feeling that they are infact
using a less secure system like PAP, but using PIC, we are infact making
sure that it is absolutely secure to a much higher standard! No doudt a
noble cause, but aren't you ignoring the fact that there could be
legitimate reasons for why there is a wide variety of choices as to the
strength of the security in different schemes, and the customers should be
able to pick and choose the mechanisms according to their requirements.

Yeah, I hear this all the time, customers are dumb, and users are dumb,
and only the cryptographers in the IPSRA and IPSec WGs are the smartest
people, and so you should impose the most secure system on customers/users
so that even if they choose to be not very secure, you infact make sure
that they are absolutely secure. So, even if a customer wants to use PAP,
we force him to have a PKI, and then authenticate the AS with certificates
and digital signatures, and then provision the certs onto the client, and
then he has the state-of-the-art authentiation system, that is infact
predicated on the PAP authentication to some extent.


> 
> 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.
> 


On what basis do you disagree. Do you think that much secure legacy
systems are not available in the market, or is this just because the
"best crypto" never gets sold.


> > 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!  :-)
> 

Not our customers. We are proud of our customers (atleast most of them).
 ;-) We infact have customers who actually want to understand the internal
details of our IPSec implementation (can be considered a review to some
extent). We often get very technical questions from our customers.
Although this is a bit aside, we have some customers who don't want to use
GUI config tools, and want to use our CLI (command line interface) to have
more control over the overall behaviour, when combined with all the other
features like routing, queueing, firewall, GRE, L2TP, HSRP etc.

You are not the first one to tell me that customers are mostly dumb, but I
personally haven't come across such customers, although there might me
some exceptions. Atleast the real BIG customers are very security
aware, I guess because they can afford the real scarce/in-demand
cryptographers ;-)

But I don't think this discussion about customers is very relevant to our
debate. Is it?

> >> > [...] 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?


The assumption is that a customer who is still using PAP for remote
access, will not even think about IPSec in the foreseeable future.

If he ever wants to upgrade, there will be always someone to provide him
global preshared key based IPSec.

    chinna

> 
> >> 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
> 
> 

chinna narasimha reddy pellacuru
s/w engineer