Re: l2tp as ipsra solution

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

On Wed, 21 Jun 2000, David Jablon wrote:

> >On Tue, 20 Jun 2000, Hugo Krawczyk wrote:
> >> ... using this password as the pre-shared 
> >> secret in pre-shared mode would be insecure. It would be open to 
> >> off-line dictionary attacks!  ...
> 
> At 10:53 PM 6/20/00 -0700, CHINNA N.R. PELLACURU wrote:
> >Any low entropy password based system is vulnerable to dictionary attack
> >(not necessarily off-line). I don't see how using the password as a
> >pre-shared key worsens the situation, or how any other scheme makes it
> >better. This is an inherent vulnerability of password based systems.
> 
> 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.

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.

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


> 
> >On Tue, 20 Jun 2000, Hugo Krawczyk wrote:
> >> There have been several questions in this list regarding the meaning
> >> of "user authentication".  From a cryptographic point of view the
> >> short (low entropy) secret that (human) users use is the main line
> >> separating "user authentication" from "machine authentication".  [...]
> 
> At 10:53 PM 6/20/00 -0700, CHINNA N.R. PELLACURU wrote:
> >Cryptographic definition of "user authentication"! I disagree. If a router
> >uses a low entropy CHAP password to authenticate to another router to
> >bring up a ppp link, then is it considered "user authentication"?!
> 
> Why would anyone use a low entropy secret for a machine-to-machine key?
> Interesting question.  After all, machines should have no trouble memorizing
> 100-bit random numbers.  On the other hand, user-configured keys may be
> a potential concern ...
> 
> >I think that the diffrence between "user authentication" and "machine
> >authentication" is much more basic than that. If only the user
> >has/provides the information needed in the authentication process, then it
> >is "user authentication" and if only the machine has/provides the
> >information needed in the authentication process, then it would be
> >"machine authentication".
> 
> These definitions miss the point.
> 
> Take the example of a router configured by a user with a low-entropy key,
> perhaps because the user had to either memorize the key, or type it in
> manually.  Under both constraints, people tend to use small keys when
> possible.
> 
> In this case, I would say that machine authentication is essentially
> being "bootstrapped" by user authentication.
> 


The user doesn't have to remember it, but hypothetically, if a machine is
using a low entropy password, and no user has to actually remember this
password ever, then still is it considered "user authentication"?!


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

    chinna

> 
> For pure machine authentication, you can insure that all secret keys are
> large and random.  For any process where a human handles the secret key,
> I would hope the system could tolerate a relatively low entropy key.
> 
> ---------------------------------------------------
> David P. Jablon
> Integrity Sciences, Inc.
> dpj@xxxxxxxxxxxxxxxxxxxxx
> www.IntegritySciences.com
> 

chinna narasimha reddy pellacuru
s/w engineer