Re: l2tp as ipsra solution

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

I don't think cryptographically there is any difference between using the
legacy authentication secret directly as a pre-shared key and the other
proposal of PIC protocol type of pre IKE phase usage, because
cryptographically in both systems the weakest link is the legacy
authentication system, and all you are concerned about is the weakest
link, and it does not matter if you do RSA or DSS later and do DH group
10, because your initial trust is predicated on the legacy authentication
system. The PIC protocol just adds another layer of protocol above IKE,
and that is all it is doing differently. It also doesn't make any
difference whether the AS is using RSA or DSS to authenticate to the
client, because it will authenticate to any incoming client whether it is
a legitimate clinet or not.

    chinna

On Tue, 20 Jun 2000, CHINNA N.R. PELLACURU wrote:

> On Tue, 20 Jun 2000, Hugo Krawczyk wrote:
> 
> > 
> > 
> > On Tue, 13 Jun 2000, CHINNA N.R. PELLACURU wrote:
> > 
> > > As I pointed out before, all the legacy authentication mechanisms that I
> > > have come to know, use symmetric key cryptography, where there has to be a
> > > pre-shared secret between the user and the authenticating device,
> > > (whether it is explicit like in passwords, or whether it is implicit as
> > > in token systems).
> > > 
> > > IKE supports this form of authentication via pre-shared key
> > > authentication. And as I said before, it doesn't make sense to do a
> > > challenge-response like legacy systems do, within the context of IKE,
> > > because all you are really concerned about is authenticating the DH, and
> > > other stuff. So, as I already pointed out, I see it as more a problem of
> > > the legacy authentication systems, because most (all?) of them don't
> > > provide an interface to get this shared secret, so that IKE can do it's
> > > pre-shared key authentication. I see this more as an implementation issue,
> > > not a protocol issue. I guess this can be considered a protocol issue for
> > > the legacy authentication systems that want to support IKE.
> > > 
> > >     chinna
> > 
> > For the (typical) cases where the legacy secret is human-memorizable 
> > (a password, or information derived from a password) then even if IKE 
> > had access to the the secret, using this password as the pre-shared 
> > secret in pre-shared mode would be insecure. It would be open to 
> > off-line dictionary attacks!  So avoiding the use of the legacy 
> > authentication secret with pre-shared mode of IKE is not just an 
> > implementation issue but also an essentil security consideration.
> 
> 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.
> 
> 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.
> 
> one-time-passwords, if can be made accessable from a legacy authentication
> system to IKE, could actually mean a high entropy password mechanism, that
> 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.
> 
> > 
> > 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"?!
> 
> 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".
> 
>     chinna
> 
> > 
> > Hugo
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> chinna narasimha reddy pellacuru
> s/w engineer
> 
> 

chinna narasimha reddy pellacuru
s/w engineer