Subject: [dhcwg] draft-miles-dhc-forcerenew-key-00

From: "MILES DAVID" <[email-masked]>
Date: Wed, 4 Mar 2009 23:53:14 +0800

We have submitted a new draft for adding a new authentication protocol
to RFC 3118 for the DHCPv4 Forcerenew message. This new submission is
based on comments received on draft-vinokour-dhcp-reconfigure-option-00
that was presented at IETF 72 in Dublin. The mechanism in this draft is
re-using the DHCPv6 Reconfigure Key Authentication method per comments
received on the DHC WG mailing list.
This will be presented at IETF74 in San Francisco.

http://tools.ietf.org/html/draft-miles-dhc-forcerenew-key 

Filename:	 draft-miles-dhc-forcerenew-key
Revision:	 00
Title:		 Forcerenew Key Authentication
Creation_date:	 2009-03-03
WG ID:		 Independent Submission
Number_of_pages: 9

Abstract:
DHCP Forcerenew allows for the reconfiguration of a single host by
forcing the DHCP client into a Renew state on a trigger from the DHCP
server.  In Forcerenew Key Authentication the server exchanges a key
with the client on the initial DHCP ACK that is used for subsequent
validation of a Forcerenew message.

Cheers,

-David Miles

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 4 Mar 2009 16:46:50 -0500

I took a quick look at this and have a few questions/issues:

1. We already have 0-length data options in DHCPv4 (see
http://www.ietf.org/rfc/rfc4039.txt), so not sure what the value of
using a 1-byte data option is for the Forcerenew Key Protocol Capability
Option.

2. Why not use the same techniques as used for DHCPv6 ...

DISCOVER includes Forcerenew Key Protocol Capability Option.
OFFER includes Forcerenew Key Protocol Capability Option.
REQUEST includes Forcerenew Key Protocol Capability Option.
ACK includes Forcerenew Key Protocol Capability Option & Auth Option
(with key).

This avoids the need to send back the AUTH option in the OFFER (and the
need for Type of 0).

3. I don't understand why the following is needed:

   The client would indicate that it supports the functionality by
   inserting an Parameter Request List option (option 55, [RFC2131])
   containing option <TBD> in the DHCP Discover message.

The client has provided the option and if the server supports it, it
MUST send it back (if adopt #2 above). This is a "core" protocol option
so I see little value to also include it in the PRL.

4. While perhaps it doesn't matter much because it is easy to snoop
packets via promiscous mode anyway, but I wonder whether something needs
to be said about the BROADCAST ACK which contains the key (in DHCPv6,
messages to the client are always unicast)? Certainly something should
be said about it in the Security Considerations?

Otherwise, I see this as a good start on this and a good way to address
this capability.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of MILES DAVID
Sent: Wednesday, March 04, 2009 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] draft-miles-dhc-forcerenew-key-00

Abstract:

Cheers,

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

---

From: "MILES DAVID" <[email-masked]>
Date: Thu, 5 Mar 2009 11:52:24 +0800

Hi Bernie,

Thanks for the quick review. Comments inline:

>> Understood. This was part of the original proposal and I admit we
glossed over this particular detail. A zero-len option would be fine.

>> Will update this in -01. 

The client has provided the option and if the server supports it, it
MUST send it back (if adopt #2 above). This is a "core" protocol option
so I see little value to also include it in the PRL.-

>> Will remove this line.

>> Ill add a section describing the problem when the broadcast bit is
set. Thanks again!

---

From: "MILES DAVID" <[email-masked]>
Date: Mon, 9 Mar 2009 13:40:17 +0800

Updated version of Forcerenew Key Authentication incorporating comments
from the list (thanks Bernie!). Chairs, could you update the agenda to
reference this version?

The DHCPv4 Forcerenew Key auth protocol is now operating the same as
DHCPv6 Reconfigure Key auth protocol.

Filename:	 draft-miles-dhc-forcerenew-key
Revision:	 01
Title:		 Forcerenew Key Authentication
Creation_date:	 2009-03-08
WG ID:		 Independent Submission
Number_of_pages: 11

http://www.ietf.org/internet-drafts/draft-miles-dhc-forcerenew-key-01.tx
t

Thanks,

-David