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

[Qi Sun <[e-mail]>]

Hi Sheng, 

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

Best Regards,
Qi

On Apr 4, 2014, at 3:52 PM, Sheng Jiang <[e-mail]> wrote:

> 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:[e-mail]] 
> Sent: Thursday, April 03, 2014 5:28 PM
> To: <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Review of draft-ietf-dhc-sedhcpv6-01
>  
> 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