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

["Bernie Volz (volz)" <volz at cisco.com>]

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: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of MILES DAVID
Sent: Wednesday, March 04, 2009 10:53 AM
To: dhcwg at ietf.org
Cc: James.Bristow at swisscom.com
Subject: [dhcwg] draft-miles-dhc-forcerenew-key-00

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
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg