Re: Secure legacy authentication for IKEv2

["Valery Smyslov" <svan@trustworks.com>]

----- 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.