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

From: Sean Shuo Shen <[email-masked]>
Date: Mon, 14 Jul 2008 11:20:36 +0800

_____  

From: Sheng Jiang [mailto:[email-masked]] 
Sent: Friday, July 11, 2008 9:06 AM
To: 'Shane Kerr'
Cc: [email-masked]; [email-masked]
Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

Hi, Shane,

Thanks Shane for your comments. For some reason, my reply to you on July 8th
did not show up on the DHC mail list. So I post it again.

What you listed are all good examples while there are many more examples. In
this draft, we were trying to do was to explain security feature of our
design in a general way, such as "prevent faking a server or client" instead
of giving details like "prevent a fake server to do *.*", since we probably
cannot enumerate all scenarios.

Our design does prevent from faking a server when this server's public key
is known by other users. If a DHCPv6 server's public key is well known, no
advertise can be faked on behalf of this server. If I understand you right,
you are talking about the case when a malicious user uses his own pub/priv
key to generate a signature and pretend to be a server. 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.

Best regards,

Sheng & Sean

  _____  

From: Shane Kerr [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 5:06 AM
To: Sheng Jiang
Cc: [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

Sheng Jiang, 

On Jul 4, 2008, at 10:58 +0200, Sheng Jiang wrote:

A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are
welcome!

Filename:    draft-jiang-dhc-secure-dhcpv6

I haven't done a detailed review, but I think this is an interesting idea
worthy of being pursued.

But maybe in the draft you can explain a bit more about the specific attacks
this is designed to prevent?

As I understand it, this technique will prevent an attacker:

- from sending an invalid binding in a Request

- from Declining a message on behalf of a client

- from Releasing a lease of a client (or renewing, but I don't see that as a
major problem)

- from causing a client to Reconfigure

It will not prevent an attacker from sending an Advertise and acting as a
DHCPv6 server. (Maybe something like the RA spoofing prevention draft could
be used for this, but that is probably the subject of a separate draft.)

--

Shane

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 17:51:38 +0700

Date:        Mon, 14 Jul 2008 11:20:36 +0800
    From:        Sean Shuo Shen <[email-masked]>
    Message-ID:  <[email-masked]>

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