Re: [dhcwg] IPsec for DHCPv6 client ?
Ted Lemon <Ted.Lemon@nominum.com> Tue, 10 September 2002 08:24 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07218 for <dhcwg-archive@odin.ietf.org>; Tue, 10 Sep 2002 04:24:53 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8A8Q8s09717 for dhcwg-archive@odin.ietf.org; Tue, 10 Sep 2002 04:26:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A8Q8v09714 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 10 Sep 2002 04:26:08 -0400
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07213 for <dhcwg-web-archive@ietf.org>; Tue, 10 Sep 2002 04:24:22 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A8N6v09559; Tue, 10 Sep 2002 04:23:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A8LCv09486 for <dhcwg@optimus.ietf.org>; Tue, 10 Sep 2002 04:21:12 -0400
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07135 for <dhcwg@ietf.org>; Tue, 10 Sep 2002 04:19:26 -0400 (EDT)
Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g8A8Evv13061; Tue, 10 Sep 2002 03:14:57 -0500 (CDT)
Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g8A8KwUa000788; Tue, 10 Sep 2002 03:20:58 -0500 (CDT)
Date: Tue, 10 Sep 2002 04:20:57 -0400
Subject: Re: [dhcwg] IPsec for DHCPv6 client ?
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v543)
Cc: dhcwg@ietf.org
To: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <3D7DA193.8030906@6wind.com>
Message-Id: <3B493994-C496-11D6-8C0A-00039367340A@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.543)
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
> 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] IPsec for DHCPv6 client ? Jean-Mickael Guerin
- Re: [dhcwg] IPsec for DHCPv6 client ? Ted Lemon
- Re: [dhcwg] IPsec for DHCPv6 client ? Jean-Mickael Guerin
- Re: [dhcwg] IPsec for DHCPv6 client ? Ted Lemon
- RE: [dhcwg] IPsec for DHCPv6 client ? Bound, Jim