[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: l2tp as ipsra solution
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