Bernie, Thanks so much for your comments. This really helps our work become better. Our design/solution is still remaining open for better. So do comment/discuss further. Please see my reply in lines.
Best regards, Sheng > I'm (still) a bit concerned about: > > 5.2. Signature Option > > The Signature option allows public key-based signatures to be > attached to a DHCPv6 message. The Signature option COULD be any place > > within the DHCPv6 message. 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. The format of the Signature option is > described as follows: > > Why is this protection positional? Can you explain why you think this is > useful? Why not secure the entire message with this? We are thinking how the receiver side is able to decide the protected part of a DHCP message in order to get the right input for verification computing. There are three possible solutions in our minds: 1, the signature option is the last-generated option, it protects all options, including itself; 2, the signature option has a set of sub-options to clear indicate which options are protected; 3, the position of the signature indicates its protected range. The first design is the best solution except for two scenarios: a, there are some options, such as the AUTH option you mentioned, request to be last generated too; b, some options may added at the end of a DHCP message after signature options has been generated. We don't have a clear example for this. But we cannot rule out the possibility. The second design is too complicated giving the fact we cannot limit the number of options. Then, the third design becomes the most reasonable one for us. > The only interesting issue is if a client's message includes both a > SIGNATURE and AUTH (RFC 3315) option -- since in this case, two > different hashes over the entire message would need to be run and that > doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH > option. (The AUTH option would include the SIGNATURE option as RFC 3315 > already requires that it cover the entire client message.) En... This is interesting. The AUTH option has already taken the last-generated position. And I assume by the time of design this, the designers already rule out the possibility that some option may request to be generated/added after AUTH option. Now, we have one, at least, it is equally to be last generated comparing the AUTH option. > I wonder whether this positional text is a hold over from DHCPv4 to > handle the Relay Agent Option (82) - which is added at the end? Relaying > in DHCPv6 is done far differently. > > If there's a reason why the SIGNATURE needs to be positional, we still > have the AUTH option conflict that would need to be discussed (if the > AUTH option isn't excluded from coverage regardless of where it appeared > in the message, it would require the AUTH to follow the SIGNATURE). En... this could be a possible answer, I guess. Both AUTH and SIGNATURE are only protects what in front of them. So, there would have no fixed order for both their positions and generation order. AUTH can be behind SIGNATURE, vice verse. This may also release the restriction "Any DHCP message MUST NOT include more than one Authentication option." [21.2, RFC 3315] > --- > > The draft allows a node to be a DHCPv6 relay agent. I think more text is > required to detail this. Suppose you have: > Client --> Relay 1 --> Relay 2 --> Server > > If Relay 1 includes a SIGNATURE option, and relay 2 does not support > this, what should the server do? How does the server know whether relay > 2 validated the SIGNATURE of Relay 1 or not (is there a requirement for > the relay to validate -- it is after all a "node")? Should the server > validate all SIGNATURE options (as in this case, there could be 3 - one > in the Client message, one in the Relay 1 message (which encapsulates > the client's message), and one in the Relay 2 message (which > encapsulates Relay 1's message (which encapsulates the client's > message))? > > Perhaps the ability for a relay to be a node should be removed? It keeps > it simpler. I agree that we should put more text to explain the process for relaying if we get sure relaying need to be protected. In the above scenario, I don't think reply agent needs to validate the SIGNATURE option unless it uses some information from its received DHCP message. The server, in this case, needs to validate all 3 SIGNATURE options. However, if relay agent does not add its only options, the signature option from it may not be very useful and the SIGNATURE options from relay agent are optional. Best regards, Sheng > - Bernie > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of JiangSheng 66104 > Sent: Tuesday, January 13, 2009 4:43 PM > To: [email protected]; [email protected] > Subject: [dhcwg] "Secure DHCPv6 Using CGAs" > draft-jiang-dhc-secure-dhcpv6-01 > > The below "Secure DHCPv6 Using CGAs" has been updated, according to > comments that have been discussed in dhc maillist and IETF meeting. > Since early collaboration is requested for this CGA and DHCP interaction > work, this update message is sent to both CSI WG and DHC WG. > > Best regards, > > Sheng > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Secure DHCPv6 Using CGAs > Author(s) : S. Jiang, S. Shen > Filename : draft-jiang-dhc-secure-dhcpv6-01.txt > Pages : 14 > Date : 2009-1-8 > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables > DHCP servers to pass configuration parameters. It offers > configuration flexibility. If not secured, DHCPv6 is vulnerable to > various attacks, particularly fake attack. This document analyzes the > > security issues of DHCPv6 and specifies security mechanisms, mainly > using CGAs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt > > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
