[dhcwg] AD Evaluation: draft-ietf-dhc-sedhcpv6

[Brian Haberman <[e-mail]>]

All,
     I have performed an initial review of draft-ietf-dhc-sedhcpv6 as a
part of the publication process.  As a heads up, I have also solicited a
security-related review that should be available by the Prague meeting.

     The following comments/questions came up during my review.

1. General

* I am very concerned about the lack of discussion of *how* a PKI will
function in this approach. This is similar to the general failure of
SEND, in that you need addresses in order to communicate with the PKI
unless it is local to the link.  With symmetric keying, there is a known
process that can be carried out, albeit not in a scalable way. With a
PKI, I can see how it can work for a server verifying messages coming
from clients, but I don't see how it works robustly for clients
verifying messages coming from a server.  At a minimum, I would like to
see a section that discusses some of these limitations in detail.  I
cannot say how the security ADs will react to this approach though.

* While I see the benefit of TOFU in certain settings (e.g., enterprise
networks), I am skeptical of how well that will work in a wireless
hot-spot setting (e.g., Starbucks).  An attacker sitting at the table
next to me will have the advantage of low RTT in order to become the
"trusted" server. The draft should provide more guidance on how TOFU
should/could be applied in this context.

* I think the document as a whole would benefit from the inclusion of a
state diagram in order to ensure that all the possible scenarios and
message processing descriptions are complete.

2. I see the following text in Section 4:

   A trust relationship for a public key can be the result either of a
   Trust-on-first-use (TOFU) policy, or a list of trusted keys
   configured on the recipient.

How is a list of trusted keys any different than a set of
pre-established secret keys? In other words, would that approach be any
different than the status-quo?

3. In Section 4.2, I see:

   It is NOT RECOMMENDED that the same sender and recipient use various
   algorithms in a single communication session.

What constitutes a session? There is a rather weak definition in 3315
based on the client sending Solicit messages.  It could be good to give
a more concrete definition in this document.

4. Section 5.3 says that the signature field may be padded. How does the
receiver know where the padding is located within the signature?

5. Section 5.4, you specify the use of the NTP Timestamp format.  Do you
have any concerns on how that will function when the current epoch ends
February 8, 2036?  If so, you could use the NTP Date format.

6. Section 6.1

* The text about the number of timestamp options seems odd ("A Secure
DHCPv6 message SHOULD contain one and only one Timestamp option").  Do
you really mean "A Secure DHCPv6 message MUST contain 0 or 1 Timestamp
options"?  If that is the case, how does the recipient handle multiple
timestamp options in section 6.2?

* The 4th paragraph says "A Secure DHCPv6 message sent by a DHCPv6
server or a client, which may be encapsulated by a Relay-forward or
Relay-reply message..."  How does a client know if its message will be
handled by a relay?

* The text says a sender receiving an authentication failure response
SHOULD NOT retry the message with the same certificate.  I am not sure
why this is not a "MUST NOT". In what scenario would retrying with the
same certificate lead to a different response code?

* The text in 6.2 says that its an error for a DHCPv6 message to have
both a Public Key option and a Certificate option. However, the text in
6.1 is a little looser depending on how you parse the "or" in the 4th
paragraph.  This should be tightened up.

7. Section 6.2

* How does a client do certificate validation?

* How do TOFU policies interact with validation failures?

* The last paragraph states that any Relay messages that contain public
key, certificate, or signature options is invalid and MUST be discarded.
 The text in 6.3 says relays SHOULD NOT add any security options.  Why
isn't the guidance in 6.3 not a "MUST NOT"?

8. Section 6.4 - For clarity, I would suggest specifying that RDnew and
TSnew come from the received Timestamp option.

Regards,
Brian