Subject: [dhcwg] Review of draft-ietf-dhc-sedhcpv6-01

From: Qi Sun <[email-masked]>
Date: Thu, 3 Apr 2014 17:27:47 +0800

Hi all,

I volunteered to review the document. Here are my comments (sorry if some of them have been discussed). But most are editorial. 

1. Technical
1) About the Signature Option
a) Different description of Signature Option:
Sec 5.3: "It protects the entire DHCPv6 header and options, except for the Authentication Option.” 
Sec 6.1: "It protects the message header and the message payload and all DHCPv6 options except for the Signature option itself and the Authentication Option.”

b) As is described above, Signature option does not protect itself including the timestamp which will be used to judge the message's validity. It means attackers can change the timestamp without destroying the signature. So attackers changes the timestamp of message, then the recipient will inspect the signature which is "correct" despite the change of the timestamp. This might cause a replay attack.

2) Inequality on the bottom of Page 12
"TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz"

What if RDnew < RDlast, maybe caused by a bad clock? In this case, the inequality holds (so that the message is accepted) but there might be something wrong. For the security reason, it would be better to drop the message, IMHO.

2. Editorial
1) Section titles:
Sec 3: Security Overview of DHCPv6
Sec 4: Secure DHCPv6 Overview
They are kind of close at the first glance.
Suggestion:
s/Sec 4: Secure DHCPv6 Overview/Sec 4: Secure DHCPv6 Mechanism Overview/

2) Add a section of Terminology
There are some terms that are not well-known to the readers. It would be clearer if a section of Terminology could define them before using.
For example:
CA; leap of faith mode; TSlast; RDlast; TSnew; RDnew; drift; etc.

3) Sec 3, 2nd paragraph (and followed paras)
Unnecessary indentation

4) Sec 4, 3rd para
  In this document, we introduce a public key option, a certificate
  option and a signature options with a corresponding verification
  mechanism.
s/a signature options/a signature option/

5) Sec 4.1, bullet 1
  A second option is defined to carry the certificate.
s/A second option/Another option/
Note: “A second option” reads like the two options are kind of linked to each other. But from the description, the two options should not appear at the same time.

6) Sec 5.1
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     OPTION_Public_Key         |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                Public Key (variable length)                   .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s/OPTION_Public_Key/OPTION_PK_PARAMETER/

7) Sec 5.2
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    OPTION_Certificate         |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                Public Key (variable length)                   .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s/OPTION_Certificate/OPTION_CERT_PARAMETER/

8) Sec 6.2, the last para
   A Relay-forward or Relay-reply message with any Public Key,
   Certificate or the Signature option is invilad.  The message SHOULD
   be discarded silently.
s/invilad/invalid/
Use MUST instead of SHOULD?

9) Sec 6.3, 1st para
   Actually, be definition in
   this document, relay agents MUST NOT add any secure DHCPv6 options.
10) Sec 6.4, bullet 2
   o  The time stamp in the last received and accepted DHCPv6 message. 
      This is called TSlast. 
s/time stamp/timestamp/

11) Sec 7, 3rd para
   The Secure DHCPv6 mechanism is based on the pre-condition that the
   recipient knows the public key of senders or the sender’s certificate
   can be verified through a trust CA.
s/through a trust CA/through a trusted CA/

12) Sec 7, Page 14
   However, the two communciating nodes can be synchronized is out of
   scope of this work.
s/the two/how the two/
s/communciating nodes/communicating nodes/

Best Regards,
Qi

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 4 Apr 2014 07:52:22 +0000

Hi, Qi,

Thanks so much for your carefully review. All editorial comments will be applied in the next update in a couple of week time. Your technical comments are also valid, they will be applied too.

Some explanation for technical point 1, regarding to signature option.  In the section 5.3, the signature “constructed by using the sender's private key protects the following sequence of octets:

               1. The DHCPv6 message header.

               2. All DHCPv6 options including the Signature
               option (fill the signature field with zeroes)
               except for the Authentication Option.”

So, the signature option itself, including timestamp is actually protected. Changing the wrong description in Section 6.1 would be sufficient to address this comment.

Regards,

Sheng

From: Qi Sun [mailto:[email-masked]]
Sent: Thursday, April 03, 2014 5:28 PM
To: <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Review of draft-ietf-dhc-sedhcpv6-01

Hi all,

1. Technical

2. Editorial
1) Section titles:

4) Sec 4, 3rd para

5) Sec 4.1, bullet 1

6) Sec 5.1
 0                   1                   2                   3

7) Sec 5.2
 0                   1                   2                   3

   be discarded silently.
s/invilad/invalid/

9) Sec 6.3, 1st para

      This is called TSlast.
s/time stamp/timestamp/

11) Sec 7, 3rd para

12) Sec 7, Page 14

   scope of this work.
s/the two/how the two/

Best Regards,
Qi

---

From: Qi Sun <[email-masked]>
Date: Fri, 4 Apr 2014 16:35:17 +0800

Hi Sheng, 

Yes, correcting description in Sec 6.1 is sufficient. Thanks!

Best Regards,
Qi