Re: [dhcwg] FW: A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!

[Robert Elz <kre at munnari.OZ.AU>]

    Date:        Mon, 14 Jul 2008 11:20:36 +0800
    From:        Sean Shuo Shen <sshen at huawei.com>
    Message-ID:  <002301c8e560$95c53690$c80c6f0a at china.huawei.com>

  | Our design does prevent from faking a server when this server's public key
  | is known by other users.

How are they going to know what DHCP server key is valid, and which is not?

  | If a DHCPv6 server's public key is well known, no
  | advertise can be faked on behalf of this server.

Sure, but where does this knowledge come from?   The client is a
new system, just out of the box, never been connected to a real
network before, never run its OS before, and has no local config at
all yet (that's what it is getting from DHCP after all).

How does it know which DHCP server is trusted and which is not?

If it does somehow (eventually) learn of trusted server keys (actually,
just learning the trusted CGAs for the servers is easier, they're smaller,
easier to test, and have the same properties) then how does the local
network admin go about retiring the old DHCP server and replacing it
with a new one (assuming that moving the key pair & CGA is not feasible).
Or, how do we implement a new key pair, if we suspect that the old private
key may have been compromised?   The clients will all reject the new one
as bogus won't they?

Or ...

  | In this case, the
  | receiver can find out that the fake public key does not match the server
  | (either from the local public key list or from certificate trust chain),
  | hence drop the fake advertise.

Is the mechanism for doing all of this specified?   If so, that's fine,
but if not, how can the client possibly actually do it?   Where does it
find the "local public key list"?   Remember it has no config, and because
of what's happening here, it obviously cannot get that info from DHCP!
The same with a certificate trust chain - where does that come from and
how does the client know what is valid and what is not?

Don't misunderstand me.   I think CGAs are a great idea, but only when
they're used for what they're designed for,   That is, they can absolutely
prove that the message received came from the address it claims to have
come from (and was actually sent by the legitimate owner of that address.)
Attempting to get anything beyond that out of a CGA however is almost doomed
to failure.   You have to know (via some other method) that the address
is the right one, then the CGA will prove the packet was not a forgery.
You cannot use anything about a CGA for the first part however.

kre

ps: in case it is not patently clear already, I have not (yet) read your
draft, I'm just reacting to some odds and ends I've seen here on the list.
If the answer to some of this is "it is all in the draft" just tell me
that and I will go read it...

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg