Re: Secure legacy authentication for IKEv2

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

----- Original Message -----
From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
To: <ipsec@lists.tislabs.com>
Sent: Thursday, December 19, 2002 8:30 PM
Subject: Secure legacy authentication for IKEv2


> Greetings again. The following draft comes out of the meeting we had
> after the IPsec WG meeting in Atlanta. It represents the thinking of
> many folks about the cleanest way to do legacy authentication in
> IKEv2. Please read it and comment here on the list.
>
> <http://www.ietf.org/internet-drafts/draft-hoffman-sla-00.txt>

Hi,

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.

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 will provide an indication to
client
that legacy authentication process must be restarted according to new LAM
type.

For example:

       Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni        -->

                                 <--    HDR, SAr1, KEr, Nr, AUTH

Client doesn't know yet what LAM type server will accept. So, she tries the
first
one she supports, for example - PASSWORD.

       HDR*, CHRE(LAM Type = SLA_PASSWORD),
             SAi2, TSi, TSr  -->

At this point server decides, that this particular user must be
authenticated with OTP
instead of PASSWORD. So, he changes LAM type to SLA_OTP and sends it back to
client.

                                <--    HDR*, CHRE(LAM Type = SLA_OTP)

Client restarts authentication process with OTP.

        HDR*, CHRE(LAM Type = SLA_OTP)  -->

and an excahnge continues as described in the draft.

As a side affect, it will also allow server to perform successive user
authentication
by multiple LAM (not sure if it is really useful).

Regards,
Valery Smyslov.