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

Re: Proposed Configuration payload for IKEv2





On Wed, 18 Dec 2002, Darren Dukes wrote:

> Attached is a draft which is intended to be merged with the IKEv2 draft.
> There is no intent for this draft to continue on its own.  It contains a
> payload and description of how an IPsec Remote Access Client (IRAC) may use
> that payload to get configuration information (internal IP, subnets, etc.)
> from an IPsec Remote Access Server (IRAS).
> 
> The payload in this draft is very similar to the IKEv1 modecfg draft, this
> draft states the differences between the two.
> 
> Why do this?  (copied from vpnc.org) "At the IETF meeting in Atlanta in
> November, 2002, the IPsec WG decided to add remote access capabilities
> (legacy authentication and remote client configuration) to IKEv2. At an

If I understand it correctly, your draft only addresses the remote client
configuration issue, not the legacy authentication. How do you envision
adding the legacy authentication support and still making use of the
configuration mechanism described in the draft? Note that you add the
configuration mechanism to messages 3 and 4 of ikev2 and assume that it is
protected under the IKE-SA, however if you need to perform legacy
authentication then you will not have an established IKE-SA in messages 3
and 4.

Also, it is worth noting that even if client and server use regular IKE
authentication (signatures or preshared key) then in message 3 the server
(responder) is not yet authenticated by the client so the information
transmitted from IRAC to IRAS in this message is NOT protected. This
should be documented and explicitly said that this message should not
contain any confidential information.

These problems are solved if the configuration information exchange
happens in phase 2 (at the expense, of course, of more round trips).

Hugo

> informal design team meeting after the WG meeting, the VPN vendors attending
> decided that the best options to propose to the WG were to add capabilities
> similar to XAUTH and MODE-CFG."
> 
> Please send all comments regarding this draft to ipsec@lists.tislabs.com
> 
> Thanks,
>   Darren
>