[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Secure legacy authentication for IKEv2



Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC
?  It seems you are re-inventing EAP types here.  For every new or
different auth method type, you'd have to define a new one in the IKEv2
spec.

-----Original Message-----
From: Valery Smyslov [mailto:svan@trustworks.com] 
Sent: Friday, December 20, 2002 10:03 AM
To: ipsec@lists.tislabs.com; Paul Hoffman / VPNC
Subject: Re: Secure legacy authentication for IKEv2


----- Original Message -----
From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>
Sent: Friday, December 20, 2002 7:39 PM
Subject: Re: Secure legacy authentication for IKEv2


> At 3:06 PM +0300 12/20/02, Valery Smyslov wrote:
> >draft suggests that no negotiation of LAM type is possible between 
> >client and server: server can just accept or reject LAM type that 
> >client proposed, and he
has
> >no means
> >to indicate to client which LAM type he is willing to do. This can 
> >lead
to
> >situation,
> >when client will have to perform up to 4 connection attempts with
different
> >LAM types.
> >Not only will it delay the connection setup, but also it will put an 
> >unnecessary load to server - for each attempt he will have to do both

> >DH and RSA/DSA.
>
> Er, do you really think that the client and server haven't agreed out 
> of band which legacy auth mechanism they will do? In the real world, 
> companies tell their users which auth mechanism they will use, and the

> information needed to do it.

I've been thinking of situation when company upgrades its legathy auth
from one type to another (i.e. from passwords to SecurID). This will not
happen overnight, so a transition period will take place. During such
period both types will be in use.

> >I think better way to handle this situation is to allow server to 
> >change
LAM
> >type
> >if he doesn't like what client proposed.
>
> This adds a lot of complexity for a usage model that no one seems to 
> have. Am I wrong here? Do any of the VPN makers out there have 
> customers who want to do legacy auth negotiation?

It will add some complexity to the protocol, but it will reduce client
configuration complexity. Currently, both XAUTH and Hybrid are designed
so, that client plays a passive role in legacy auth process (with an
exception that she must indicate to server that she can and will do
legacy auth). It is server who decides what type of legacy auth will
take place and what attributes are needed. Client just displays
corresponding prompts to user and sends back reply to server. This allow
client to be configurationless with this regard. In your proposal client
plays more active role in the process. Therefore, either client needs to
be preconfigured, or should use "try-and-catch" technique. The first
alternative adds configuration complexity (espeshially during transition
period), the second delays connection setup and puts an extra load to
server. Anyway, I'm not very happy with both.

> --Paul Hoffman, Director
> --VPN Consortium

Regards,
Valery Smyslov.