Subject: Re: [dhcwg] DUID on a Virtual Host

From: "David W. Hankins" <[email-masked]>
Date: Thu, 1 Mar 2007 15:46:28 -0800

On Tue, Feb 20, 2007 at 02:52:38PM -0700, Ted Lemon wrote:
> In fact, what I would say about this whole conversation is that keys,  
> like clients, are *things to be identified*, not *identifiers*.   You  
> call a key something.

It amounts to the same thing since most key names (at least the
ones that are "usually unique") are reductions of the original
key.

> by name.   It may be that for some reason it makes sense to include a  
> public key in a DHCP transaction, but including it *as the  
> identifier* strikes me as confusing two functions - identification  
> and authentication.

A single client, identified by a single DUID, is going to be
authenticated multiple times in one DHCP exchange?

-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 1 Mar 2007 16:12:54 -0800

On Wed, Feb 21, 2007 at 11:28:43AM +0900, Markus Stenberg wrote:
> There is of course the question of what we want to accomplish with  
> this scheme;

There you go again.  Insisting that IETF work have some kind of
relevance to real world practice.

Killjoy.

> content; however, are those desirable characteristics for DHCPv6?

I think the short answer is yes.  Keys for authenticating both
the client and server are obvious neccessities to anyone who
understands DHCP, but encryption is an odd duck - which I think
would be a good feature for DHCPv6 in order to carry some kinds
of options we can't today.

The long answer probably belongs in a draft.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Mar 2007 17:20:00 -0700

> ones that are "usually unique") are reductions of the original

No, this is almost completely untrue.   I say almost because PGP key  
signing uses key fingerprints to make the process easier, and those  
are things you could call identifiers, which are derived from the  
actual content of the public key.   However, even in the case of a  
PGP key, the key is used to assert ownership of an identity.   A PGP  
key asserts that you are, for example, [email-masked], and  
this is a unique identifier.   An SSL key asserts that you are, for  
instance, www.isc.org, and that is the unique identifier associated  
with the key.   A DNS key asserts the identity, for example, daves- 
key.isc.org., and then you use that key to sign updates to a server  
that allows you to do updates if you can prove that you know the  
private half of the key identified by the unique domain name daves- 
key.isc.org.   I'm not aware of any key where the binary data in the  
key is used as an identifier, or where it is that binary data that is  
the identity being asserted through use of the private key.

> authenticated multiple times in one DHCP exchange?

Right, there's no reason to include the entire text of the key in  
every exchange; indeed, if you have to include it, you've proven  
nothing except that you have the private half of the public key  
you've presented.   There's no reason at all to include the key in  
every message, even if that is all you want to assert - you can  
present the key once, and subsequently refer to it by a much shorter  
unique identifier.   You can even establish a unique name by which to  
call the key when you talk to the server, if that is needed.    
Sending the key multiple times, and using its large hunk of binary  
data as an index into a database, doesn't make much sense.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 1 Mar 2007 16:45:46 -0800

> No, this is almost completely untrue.   I say almost because PGP key  

Awesome.

> actual content of the public key.

I suppose you and I have vastly different ideas about how this
works, but it's pretty tangential to this discussion.

Suffice to say, PGP would not work unless you could differentiate
multiple keys with the same or similar UID string by their
fingerprint derivatives.

> data as an index into a database, doesn't make much sense.

Excellent, we are agreed then.  You did forget to mention that if
we reuse the method for DHCPv4 RFC3315-style client identifiers,
that sending the whole key as DUID would run us out of packet
space fast.  That's a minor detail.

Anyway, I'll sum up what we just agreed on:

It would be perfectly acceptable to use a derivative of a key as a
DUID.  If you actually wanted to make use of the key of course,
in authentication or encryption or what have you, there would need
to be some additional mechanism to transfer its content.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Mar 2007 17:57:51 -0700

> to be some additional mechanism to transfer its content.

No, we didn't agree on that.   You assert that the key is unique, and  
that therefore the fingerprint (derivative) is unique, but in fact  
nothing of the sort is true - the only reason the fingerprint works  
as an identifier is that there are additional disambiguation  
mechanisms that (a) make the likelihood of an undetected collision  
acceptably small and (b) provide a path for both detecting and  
dealing with a collision.   Unfortunately, these mechanisms require  
the intervention of an intelligent agent (a person) and can't really  
be automated in the way you're suggesting.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 1 Mar 2007 20:53:09 -0800

On Thu, Mar 01, 2007 at 05:57:51PM -0700, Ted Lemon wrote:
> No, we didn't agree on that.

Pity.  You seemed to agree that there's no reason for a client
to present multiple keys, since it's only going to authenticate
itself one given way in any given exchange.

So there really shouldn't be a reason to artifically introduce a
client->key disambiguation problem that would no doubt cost money
to solve.

> You assert that the key is unique,

Boy I hope so!

If someone else has an identical binary public key, and can produce
a matching signature on a DHCP packet, then you've lost, no matter
how you found the key, or what kinds of disambiguation craziness
you put inbetween the process.

> Unfortunately, these mechanisms require  

You seem to think from an identity, you can determine the correct key.

This is not true without human intervention in any of the examples
you've cited.  You've got it backwards.

key->identity, in some kinds of keys, is a given (or is a cached
state in others).  You can check the identity contained within the
key against what you expected, and then verify the key against your
trust anchor.  You've just proved the identity which the trust anchor
has signed.

identity->key is hard, and ultimately requires human intervention
to do properly.  The biggest problem is that many keys might be
introduced (a number you can't control), and the only way to verify
any of them is through expensive cryptography.

Not to mention that many DHCP clients (and servers) have no idea
what their "identity" is when they boot the first time, and the
methods they do have are prone to user-produced collisions.

The "SSH model" is the right one for most DHCP environments.  It has
the exact same bootstrap (from fresh software install) problem DHCP
does ('hostname' is probably "default.example.com"...hints from
hardware are probably ambiguous...), and in my opinion the best key
distribution model for the DHCP problem.  It does need some tweaking.

But the basic similarity is that the key "is" the identity, and any
external identities you can apply to it are a function of how you
come by (such as key->lease->hostname) and then cache the key, not
a property of the key itself.

Putting the key in an additional space in the packet rather than the
DUID just wastes space to no positive results, since what you're
really validating before processing the message is the key (and its
signature of the packet), and not the DUID.  Briefly, the DUID's
function in "lease ownership" is replaced through cryptography.

The one thing you said that's absolutely true (although in the casual
case statistically highly unlikely) is that fingerprints might need
disambiguation by looking at the binary public key contents comparing
two identical fingerprints.  In the attack case, that absolutely
needs human intervention to work (and usually it doesn't).

But in such a case, it requires;

A) Foreknowledge - knowing the fingerprint someone will use before
   they use it, and manufacturing a key whose fingerprint matches.
   Getting your (probably different) binary public key into the
   DHCP endpoint's cache before the subverted system can.

   Manufacturing such a key is difficult enough.

B) Some way to fault the DHCP endpoint's cache without operator
   intervention, so that it will take on your newly manufactured
   binary-different-public-key with matching fingerprint.

   Again, just manufacturing the key is difficult enough.

In short, these are both non-issues.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Mar 2007 07:36:26 -0800

> be automated in the way you're suggesting.

Forgive me if I am missing the point completely, but is't
handing out unique pieces of information to clients exactly
the reason why we have DHCP servers in the first place? For
example, why can't it be such that a client could walk up
to the server and say:

 "My name is James Horatio Blankenship Esquire the Third."

and the server replies:

 "That's great; we'll just call you "Jim" from now on."

So, as long as the server accepts the client's (long) public
key as an identifier and gives it back a (short) nickname to
be used in subsequent transactions it should be OK - right?

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Mar 2007 11:42:25 -0800

On this whole public-key-as-DUID topic, it's too late to
put in a -00 draft for IETF68 now, but I hope to ask some
help from others and get a draft out soon after IETF68.
(If anyone wants to beat me/us to it, that's up to them.)

Thanks - Fred

> -----Original Message-----
> From: Templin, Fred L 
> Sent: Friday, March 02, 2007 7:36 AM
> To: Ted Lemon; David W. Hankins
> Cc: DHC WG
> Subject: RE: [dhcwg] DUID on a Virtual Host
>