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

Re: Proposed Configuration payload for IKEv2



Hello Gents,


Is <draft-ietf-ipsec-dhcp-13.txt> not intended for IP configuration of
remote hosts ?
IMHO, <draft-ietf-ipsec-dhcp-13.txt> decouples IPSec and IRAC config in the
sense that only a short lived tunnel is required for DHCP messages hence all
other complexity is in DHCP.

What is gained from decoupling IKE from host configuration is that only a
single mechanism is required for host configuration. In that way a system
administrator must not learn new mechanisms/methods to configure hosts. To
her/him it is the same whether configuring a central office or a remote
IPSec protected host.
 
Best regards - Dirk
                           

-----Original Message-----
From: Darren Dukes [mailto:ddukes@cisco.com]
Sent: donderdag 19 december 2002 20:39
To: Hugo Krawczyk
Cc: ipsec@lists.tislabs.com; ietf-mode-cfg@vpnc.org
Subject: RE: Proposed Configuration payload for IKEv2


> From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il]
> Sent: Thursday, December 19, 2002 12:30 PM
>
> 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?

After taking a quick look at Paul's draft he just sent out, I think CP will
go in the LAS exchange message 3 and message N the same way it's specified
for message 3 and 4 now.

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

You are right about message 3, and the IRAS not being authenticated to IRAC.
I think text about the lack of authentication should suffice with strong
suggestions of what configuration attributes should go into the CFG_REQUEST.

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

I had originally thought of this as just a post 'phase-1' exchange but since
the first Child-SA is always created in message 3 and 4 we will need the
configuration data before or during its creation.  Without it the IRAS has
no way of knowing how to narrow TSi in message 4.

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