Subject: [dhcwg] Security review of draft-ietf-dhc-sedhcpv6-08.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 15 Jul 2015 14:26:14 -0400

All,
     Russ Housley has reviewed the sedhcp draft from a security
perspective.  His comments are below.  I have included him on the
distribution so that he can engage in the discussion.

Regards,
Brian

------

I was surprised by the use of "public key signatures"; we usually say
"digital signatures".  Also, please use the terms in RFC 5280: CA =
Certification Authority (not Certificate Authority).

Section 3 should be recast as the things that need improvement in
DHCPv6.  A different intro paragraph may be sufficient.

Section 4 says that TOFU is an option.  I like leap-of-faith mechanisms
in some situations, but I am not convinced that this is one of them.
The discussion in Security Considerations provide useful advice to an
implementer, but it does not tell what risk an operator is accepting or
what risk a client is accepting.  This analysis is needed for an
educated decision about actually using TOFU or not.

The document really says that we know how to do TOFU today, but it does
not explain the residual risks associated with it.  It says that PKI
will resolve mitigate those additional risks, but the ability to deploy
PKI in this context is for further study.  I'm not sure we are really
improving things if the only approach that we know how to do today
involve manual key management.  You can't do manual key management for
some coffee shop WiFi that you did not know you would be visiting in
advance.

One possible way forward is to look at the certificates that are being
discussed in 802.1 for MACsec.  They bind a MAC address to a public key.
 Can the 802.1 certificate be used here too?

---

From: 神明達哉 <[email-masked]>
Date: Tue, 28 Jul 2015 03:24:26 +0900

> in some situations, but I am not convinced that this is one of them.

Specifically what are you referring to by "this"?  The paragraph
beginning with "TOFU can also be used" and talking about hijack
prevention?

>  Can the 802.1 certificate be used here too?

I'm not familiar with MACsec, but I'm afraid the answer is "no", since
a client and a server may not be in the same layer 2 network (they can
be off-link and communicate via a relay agent).

--
JINMEI, Tatuya

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Jul 2015 15:16:43 -0400

> beginning with "TOFU can also be used" and talking about hijack

I interpret the "this" to be referring to the DHCP client/server
interaction.

Regards,
Brian

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 27 Jul 2015 19:50:18 +0000

Couldn't one replace MAC address with client-id and server-id options (DUID)?

I'm not sure we'd want to do this, but in theory it is possible -- yet requires a certificate to be issued for these which gets back to the distribution problem and how does a client without a global address verify the server's certificate is valid and usable (if it has no way to confirm certificate authority/revocation lists).

And doesn't all of this open up privacy concerns, especially if one has to use the true MAC address (or consistent DUID).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, July 27, 2015 2:24 PM
To: Brian Haberman
Cc: [email-masked]; Russ Housley
Subject: Re: [dhcwg] Security review of draft-ietf-dhc-sedhcpv6-08.txt

> Section 4 says that TOFU is an option.  I like leap-of-faith 
> mechanisms in some situations, but I am not convinced that this is one of them.

Specifically what are you referring to by "this"?  The paragraph beginning with "TOFU can also be used" and talking about hijack prevention?

>  Can the 802.1 certificate be used here too?

I'm not familiar with MACsec, but I'm afraid the answer is "no", since a client and a server may not be in the same layer 2 network (they can be off-link and communicate via a relay agent).

--
JINMEI, Tatuya

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