Subject: DHCP and IPSec

From: [email-masked]
Date: Mon, 10 Jul 2000 16:29:00 -0400 (EDT)

Hello,

I am probably not the first to ask this, but are there any provisions for
IPSec to provide authentication during host configuration or for the
authentication proposed for DHCP to work as part of the IP Security
Architecture?

Thank you,
Jordan

---

From: "William A. Arbaugh" <[email-masked]>
Date: Mon, 10 Jul 2000 17:27:55 -0400 (EDT)

> authentication proposed for DHCP to work as part of the IP Security
The current proposal can work as part of the IP Security Architecture. A
client would first obtain a lease through use of the DHCP authentication
framework.  Once the lease is obtained, the client can negotiate a IPSec
SA in the usual way.

Bill

---

From: [email-masked]
Date: Mon, 10 Jul 2000 18:06:19 -0400 (EDT)

I suppose.  It doesn't really work with it, though.  I can't take
advantage of ISAKMP to re-key me.  Is there a way that DHCP can be more
integrated?  Is there a reason why it shouldn't be?  The proposed DHCP
authentication method only allows me to authenticate DHCP messages.  I
think it would make sense to make DHCP part of the larger authentication
and encryption framework.  

The security side of networking is fairly new to me, so what I'm saying
could well be ridiculous and I would be happy if someone would point it
out to me.

Thanks,
Jordan

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Mon, 10 Jul 2000 23:23:30 -0800 (GMT-0800)

See draft-ietf-ipsec-dhcp-0x.txt

---

From: [email-masked]
Date: Tue, 11 Jul 2000 09:08:44 -0400 (EDT)

That draft discusses VPN operation.  If I understand correctly, the
operation is roughly as follows:

1) The remote host acquires an IP address which the VPN gateway
understands.  The draft is not concerned with this step.

2) The remote host creates a security association with the VPN gateway and
then creates an IPSec tunnel to it for DHCP.

3) The remote host acquires a second IP address using DHCP . . .

This not the scenario that the DHCP authentication mechanism addresses.
DHCP auth is intended to provide identity guarantees when IP addresses are
being assigned.  If the VPN gateway uses DHCP to configure the remote host
in (1) it is still open to attacks on its address pool which DHCP auth
would address.  But now it has to conform to a second security
architecture because DHCP authentication does its own thing.

I realize that the VPN gateway is unlikely to be the one giving out the IP
address to the remote client in normal VPN operation, but someone will
have to give out the IP address, and they may want guarantees about who
they're giving the address out to.  They may also want guarantees about
who is using the address.  IPSec can be used to provide this second
guarantee.

Is there a way to make the two of them work together?  Is there a reason
not to do so?

Thanks,
Jordan

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2000 10:38:34 -0700

The trick is to establish a security association without a network
connection.  :'} So it either has to be prearranged, or you have to
add a packet exchange to the DHCP protocol and probably use bigger
packets.  We have talked about this, but nobody's put a serious
proposal on the table other than the "get an address and then get a
security association" model.  Also, people have expressed resistance
to using DHCP as part of a network sign-on, for reasons I won't
attempt to explain because I don't quite accept that this is a bad
idea.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Jul 2000 06:53:19 -0400

> Is there a way to make the two of them work together?  Is there a reason

Ted has already pointed out that it's hard to use IPsec if one doesn't
already have an address. Another fundamental one is that relay agents
modify DHCP packets. IPsec, not surprisingly, notices this and barfs.

I have a hard time coming to any conclusion other than that DHCP needs
a tailor-made authentication solution because of its unique situation
stemming from the fact that the IP stack is not fully configured at
the time DHCP is typically invoked.

Thomas