Re: [dhcwg] FW: RFC3315 question

On Sat, Feb 17, 2007 at 11:38:12AM -0800, Templin, Fred L wrote:
> In particular, it might be useful to define
> a new DUID type that includes a client's public key such as
> required by RFC3972. The actual format of the DUID type is for
> further study, e.g., in addition to the public key it might be
> desireable to include a link-layer address, a timestamp, etc.

I think it's a fantastic idea.

If servers and clients could identify themselves with a public
key, then we could exchange greater varieties of configuration
information (which may require encryption) over an encapsulated
option.

The trust model for such exchanges would need some careful
thought, but on first inspection I see no reason why the SSH
model can't be adopted here (ask the operator, then cache the
key with link layer hints).

I've long wanted to experiment with public keys in DHCPv4
authentication...due to the size limitations in DHCPv4 payloads,
that's sent me down some ratholes I have vague notions for, but
nothing (yet) I wish to expose to the scrutiny of public review.

Since DHCPv4 now defines RFC3315 DUID's as client-identifier
contents (with the IAID prepended), I think there's a great
deal of good that could come from defining a method to transport
unique indexes to public keys, rather than the keys themselves,
in the DUID so that we could leverage the same mechanism for
both protocols (by writing a draft that lifts the DHCPv4 server
restriction that client identifiers be opaque).

I think there are some non-trivial challenges here, but any
effort down this path is worth our learning something from it.

-- 
ISC Training!  http://www.isc.org/training/  training@isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins