[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hybrid Authentication and Remote Access
I'm curious about the design goals of ipsec-isakmp-xauth ...
At 12:48 PM 7/16/98 -0700, Vipul Gupta wrote:
> Since others on this list may have an interest in using
> IPSec for remote access scenarios, I'd like to share the
> following e-mail exchange with Moshe Litvin.
>From: Moshe Litvin <moshe@CheckPoint.COM>
>To: Vipul Gupta <vgupta@nobel.eng.sun.com>
>CC: moshe@CheckPoint.COM, roy@CheckPoint.COM
>Subject: Re: Your draft on Hybrid Authentication
>
>Vipul Gupta wrote:
>> [...] What is your opinion regarding draft-ietf-ipsec-isakmp
>> -xauth-02.txt which also describes the use of token cards
>> and one-time passwords for authentication with ISAKMP?
>> That draft assumes that the OTP/token card interaction
>> occurs *after* a phase one ISAKMP SA has already been
>> established (i.e. the ISAKMP negotiators have already
>> authenticated themselves mutually). With these assumptions,
>> it isn't clear to me that there are many scenarios where
>> the xauth draft will be applicable.
>>
>> Your draft proposed the use of existing authentication
>> mechanisms like token cards etc for Phase I SA establishment
>> and seems to have wider applicability. Any comments/feedback
>> appreciated.
Moshe Litvin wrote:
>I think that the hybrid mode has several advantages over ISAKMP/XAUTH.
>There is reason that you stated that ISAKMP/XAUTH can be done only after
>phase 1, so we have the problem of established ISAKMP SA which is yet
>completely secure because the ISAKMP/XAUTH hadn't started.
>
>It also has security advantage that are gained through the use of public
>keys, without the need for a full blown PKI as in the case of the full
>public keys modes.
>
>The most natural way to apply ISAKMP/XAUTH is to have a PHASE 1
>authenticated by pre-shared secrets (because if you can do something
>more powerful in phase 1 you probably don't want ISAKMP/XAUTH) and then
>authenticate only the user with the ISAKMP/XAUTH.
Are you concerned that the "more powerful" techniques are precluded
by cost of computation, or by inconvenience?
>But since a user must remember the pre-shared secret is is vulnerable to
>dictionary attacks, and without the pre-shared secret there is no server
>authentication and you are vulnerable to man in the middle attack.
If computational cost is not the overriding concern,
have you (Vipal or Moshe) considered using an EKE-class
shared-secret authentication method, which is immune to these
attacks? These were specifically designed to handle
memorized secrets.
-- dpj
References: