Re: [dhcwg] DUID on a Virtual Host

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  
> the intervention of an intelligent agent (a person) and can't really  
> be automated in the way you're suggesting.

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.

-- 
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