Subject: [dhcwg] IPsec for DHCPv6 client ?

From: Jean-Mickael Guerin <[email-masked]>
Date: Mon, 09 Sep 2002 14:54:59 +0200

Hello,

I have a question about security mechanisms proposed in the draft, 
hoping it has not be discussed before, in case I'd appreciate pointers. 
The delayed authentication uses a shared secret and considers mainly 
intradomain roaming. IPsec is proposed between relays and servers 
because they're likely to belong to the same administrative domain.
Why is not proposed using IPsec to secure communications between clients 
and servers with the some restrictions, i.e. installation of static keys 
as shared secret, in intra-domain ?

Regards,

-- 

Jean-Mickael GUERIN
Tel : +33 1 39 30 92 33
Web site : www.6wind.com

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2002 20:28:24 -0400

> Why is not proposed using IPsec to secure communications between 
> clients and servers with the some restrictions, i.e. installation of 
> static keys as shared secret, in intra-domain ?

Because in general we don't expect that such a security association 
would exist.   In general, you are plugging a device into the network, 
and you want it to work - you don't want to have to configure it before 
you plug it in.   If you wanted that, you wouldn't be using DHCP, 
right?   The only plausible exception I can come up with is a cell 
phone, where perhaps the provider would install an IPsec key in the 
phone.   But even then, I'm skeptical that it could be made to work the 
way you describe.

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Tue, 10 Sep 2002 09:38:59 +0200

Ted Lemon wrote:

> and you want it to work - you don't want to have to configure it 
> before you plug it in.   If you wanted that, you wouldn't be using 
> DHCP, right?   The only plausible exception I can come up with is a 
> cell phone, where perhaps the provider would install an IPsec key in 
> the phone.   But even then, I'm skeptical that it could be made to 
> work the way you describe.
>
My point concerns the possibility of using IPsec in scenario where DHCP 
Authentication is proposed. Because DHCP Authentication relies on shared 
secret, I think the draft should have a section about this, even if it 
would be limited to client and relays or client and server on same link.

Jean-Mickael

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2002 04:20:57 -0400

> My point concerns the possibility of using IPsec in scenario where 
> DHCP Authentication is proposed. Because DHCP Authentication relies on 
> shared secret, I think the draft should have a section about this, 
> even if it would be limited to client and relays or client and server 
> on same link.

Your reasoning is flawed.   IPsec is not shared-secret authentication.  
  It is an entire security infrastructure, carefully designed to solve a 
certain class of problems.   It happens to support the use of 
shared-secret authentication, among other authentication schemes.  The 
DHCP security option also supports shared-secret authentication.   This 
is nothing more than a coincidence - it does not mean that DHCP 
security can work with IPsec.

The DHCP server and clients need to see packets with "bad" 
authentication keys in order for DHCP authentication to work, because 
they can't really prepare in advance for all the possible uses of keys 
by roaming clients and servers in locations to which they may roam.   
If the packet is signed with the wrong key with IPsec, it will simply 
be dropped by the DHCP agent's IP stack.   This is not what we want.

Intuitively it seems obvious that one should use IPsec for DHCP 
authentication.   Personally, I'd *love* to be able to claim that IPsec 
was a solution to securing DHCP transactions.   But this working group 
has a long history of trying to solve this problem with IPsec.   Every 
time we've tried to figure out a good way to do it, we've come up 
either with nothing, or with an unworkable kludge.   So there's a good 
reason why we didn't do it - it's not an oversight.

If you think that there is a way to make IPsec work with DHCP 
authentication, please take the extra time to actually sit down and 
reason it through before insisting that we make changes.   What happens 
when a server sees a new client for the first time?   What happens when 
a client that's got a security association with a server at one site 
roams to a different site?   Does the server at the other site even see 
packets from that client?   How does it get them?   How does all this 
work with relay agents?   Like it or not, DHCP *requires* relay agents, 
so the protocol has to work when the DHCP client is talking to a relay 
agent rather than a server.   If you put the signature in the payload, 
all these problems go away.   That's why we've put the signature in the 
payload.