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

[Sheng Jiang <[e-mail]>]

Hi, Stephen,

We have modified our draft according to your comments. It improves our draft a lot. Could you please review the latest version? The attachment are txt version and the diff

Many thanks and best regards,

Sheng

From: Sheng Jiang
Sent: Monday, February 27, 2012 4:17 PM
To: Sheng Jiang; 'Stephen Kent'
Cc: '[e-mail]'; '[e-mail]'; '[e-mail]'; '[e-mail]'; '[e-mail]'
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

We are still working on your comments. You wrote "it appears that algorithm agility support for Secure DHCPv6 is based (in large part) on carrying the hash and signature algorithm IDs in the Signature Option. That is different from the RFC 4270 analysis of how to enable algorithm agility for the CGA itself."

Could you give further suggestion: if you don't like the way of agility support? What is better mechanism to support algorithm agility in our approach?

Many thanks and best regards,

Sheng

From: Sheng Jiang
Sent: Thursday, February 23, 2012 9:39 AM
To: 'Stephen Kent'
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

Thanks for point out the incorrect text. It was there from early stage design. I have corrected it in the new version.

Many thanks,

Sheng

From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, February 23, 2012 9:32 AM
To: Sheng Jiang
Cc: Sheng Jiang; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Stephen Kent
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

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