Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt

[Stephen Kent <[e-mail]>]

At 2:33 AM +0000 2/22/12, Sheng Jiang wrote:
>Hi, Stephen,
>
>Thanks for your review. I have integrated them in a new version or 
>make some correspondent improvements. However, I do not agree the 
>below comment and would like to discuss it further.
>
><Stephen> The fact that the signature option can be placed anywhere 
>in the DHCPv6 message strikes me as dangerous. It imposes a 
>requirement on a receiver to treat the protected and unprotected 
>portions of the message differently, for any possible placement of 
>the signature option. This adds complexity to implementations, since 
>the security checking would have to indicate to the rest of message 
>processing which parts of a message were checked and which were not 
>verified. Unless there are DHCHv6 options that may be modified (or 
>added) legitimately when a message traverses a relay, it is not 
>clear why there needs to be a provision to exclude any portions of a 
>DHCPv6 message from  the integrity/authentication check.
>
><Sheng> The charge is not right here. Although the signature option 
>can be placed anywhere, it actually protects ALL DHCPv6 options and 
>payload (except for itself and auth option), see Section 5.2 for how 
>to perform signature. Therefore, there is no unprotected  portion at 
>all. The place of signature option does not mean the portion after 
>it is unprotected.

The text in 5.2 states, when it describes the Sig option:

"It protects all the DHCPv6 header and options before it. Any options 
after the Signature option can be processed, but it should be noticed 
that they are not protected by this Signature option."

This text contradicts what you said above. The text later in 5.2, in 
the discussion of how to compute the sig value, says what you meant 
(sort of), but that contradicts the text cited above.  Also, the text 
describing how to compute the sig is incorrect, since it says:

" The signature constructed by using the sender's private key over 
the following sequence of octets:..."

The private key is used to sign the hash value computed over the 
sequence of octets described in this part of 5.2. Also, allowing the 
sig option  to appear anywhere in the message is, as I indicated 
earlier, a bad idea. Even if the text is corrected to make clear that 
the whole message is protected, it is "cleaner" to put the sig option 
at the end, so that the sender and receiver does not have to skip 
over it in computing the hash value that is to be signed.

Steve