Re: l2tp as ipsra solution

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

On Wed, 21 Jun 2000, Hugo Krawczyk 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.
> > 
> 
> I disagree.
> 
> An *off-line* guessing attack against a password-authentication protocol
> is one in which with a piece of public information produced by the protocol
> an attacker can seat at his home's PC and scan, say, 100K passwords to find
> the one used to generate that information (assuming the used password is
> one of the 100K scanned passwords).

I am sorry, I was under the assumption that we shouldn't be bothered about
simplisitc password bases systems like PAP, CHAP which are vulerable to
this kind of off-line dictionary attacks. My assumption is based on the
fact that no customer is using these in the real world today, and even if
some is still using these historic protocols, I don't think that kind of
customers will ever migrate to IPSec in the foreseeable future.

> 
> Contrast this with the *on-line* attack where the attacker *actively* 
> tries to authenticate to a remote server by *trying* guesses to the 
> actual password. If the system limits the failed authentication attempts
> to, say, 20, then such an attacker has a probability of 20/100000 to
> succeed.
> 


> A well-designed password protocol is one that makes the on-line attack the
> only viable way to attack the system.

This is the kind of authentiction mechanisms, that *all* (atleast *all*
security consious customers) are using currently. I don't think any
security consious customer is using PAP or CHAP. I think these protocols
are provided in the litrature for completeness (or from a historic
perspective).


> 
> Using pre-shared IKE mode with a password is NOT a well designed password
> authentication protocol since it allows for the first attack.

To make IKE pre-shared keys secure enough that they are only vulnerable to
an on-line attack, is an implementation detail, and needs no change to the
protocol itself (IE. the bits on the wire don't have to change). So, this
is not a valid argument, to add another layer of protocol in a pre-IKE
phase.


> 
> 
> > Using challenge-response mechanisms within the context of IKE, doesn't
> > make sense because, our main goal in IKE is not just authenticate the
> > user, but also authenticate the SA parameters that are negotiated, and
> > also the DH.
> 
> You can have GOOD password protocols that will also authenticate the DH
> key exchange. PIC is just one example.
> 

That is my point, use IKE itself to do it, and we don't need another
protocol.


> > 
> > one-time-passwords, if can be made accessable from a legacy authentication
> > system to IKE, could actually mean a high entropy password mechanism, that
> 
> Depends on the one-time-password scheme. Some of these schemes derive 
> the "one-time" passwords from a fixed password and then are subject 
> to off-line attacks.  A well-designed one-time-password scheme 
> can indeed be of value.  In any case, in the ipsra group we cannot 
> choose the legacy system, the protocol has to be as good as posssible 
> with every legacy system (including those based on a single 
> human-memorizable  password)
> 

I think at the bottom of any one-time-password scheme is a master
pre-shared secret, and I don't follow  your argument about "fixed
password".


> > is to some degree secure against online dictionary attacks. I guess this
> > is more useful in the context of IKE. Or even if just the master
> > pre-shared secret is provided to IKE, we can use a one-time-password type
> > of mechanism for IKE authentication, instead of directly using the master
> > pre-shared key. This is just an implementation detail, and doesn't need
> > any change in the IKE protocol. We are just leveraging the existing legacy
> > authentication infrastructure that already maintains a database of
> > pre-shared secrets with each individual user/machine that we need to
> > communicate to. Routers do use legacy authentication to authenticate to
> > other routers, when trying to initiate PPP sessions, and so it could be a
> > machine that we are authenticating using legacy authentication systems.
> > 
> > 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.
> 
> As explained above, if a protocol is not well-designed then off-line attacks 
> can succeed even when the legacy dtabase is perfectly protected.
> 

As I said above, I don't think anyone is using the password based
mechanisms like PAP/CHAP that are vulnerable to the kind of off-line
attakcs that you are trying to protect using PIC.

> 
> > 
> > > 
> > > 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". Of
> > > course, there is another important security aspect of "user
> > > authentication"  which is the granularity of policy decisions that you
> > > can make at the level of individual users.
> > 
> > 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"?!
> 
> Let's not make this a linguistic discussion.  Cryptography does not care
> about "users" and "machines".  In cryptography these are all "entities"
> (or principals). 

If cryptography doesn't care about "users" and "machines" then why are you
trying to provide a cryptographic definition of "user authentication" Vs
"machine authentication".

The real cryptographic issue is what keys these entities
> have, what functions are keyed with these keys, and how the protocol that
> uses these functions is designed.  Thus from a cryptographic point of view
> the case of the router using low-entropy passwords is similar to the human
> user authenticating with his memorizable password. While the case of a
> router authenticating with a digital signature is closer to the user that
> authenticates herself via a digital signature produced by her smartcard. 
> 

Using low entropy passwords is "_similar_ to" "user authentication", and
using a cryptographically strong authentiation like a digital signature
based on RSA or DSS is "_similar_ to" "machine authentication"!?

> (From a security point of view, however, it is sad to see routers
> authenticating with low-entropy keys...)
> 

You seem to be missing the BIG "_**IF**_", in the above statement. This is
a "__**Fictitious**__" scenario that I used for making an argument.


> > 
> > 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".
> 
> this is certainly a valid literary definition, but not very useful in
> a technical cryptographic context.
> 
> Hugo
> 

If cryptography doesn't have any sense of a "user" Vs "system", there is
no use in even trying to provide a cryptographic definition of "user
authentication" Vs "machine authentication".

    chinna



> > 
> >     chinna
> > 
> > > 
> > > Hugo
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > chinna narasimha reddy pellacuru
> > s/w engineer
> > 
> > 
> 
> 
> 

chinna narasimha reddy pellacuru
s/w engineer