HI, Bernie, Thanks again. Please see my reply in lines.
Best regards, Sheng > I noticed that the draft is actually self conflicting in terms of the > Signature option: > > 5.2. Signature Option > > ... 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. ... > > 6.1. Processing Rules of Sender > > ... The Signature option MUST be constructed as explained in > Section 5.2 and be the last DHCPv6 option. > > Again, per my earlier comments I think its position should not matter. This text in 6.1 is a careless mistake. It remains unchanged from 00 version. It will be fixed in the future version. > --- > > In 6.2. Processing Rules of Receiver: > > The receiving node MUST verify the Signature option as follows: the > receiver MUST ignore any options that come after the Signature > option. > > What about the contents of the Signature option itself? The document > needs to indicate which, if any, portion of the Signature option is > included in the signature hashing. (The SEND RFC (3791) excludes the > signature option.) Yes, this Signature option protects its own header. We describe this in the signature field of Signature option, section 5.2 > Note that earlier in section 5.2. Signature Option is written: > > 6. The content between the option-len field and > the signature field in this Signature option, in > the format described above. > > Might be best to just refer to section 5.2 instead of duplicating the > information (less chance for it to conflict)? Ok, we will add quotation there to make it clearer. > --- > > This probably exposes my ignorance of CGAs, but is the intent in this > draft that the CGA source address used by the client remains the (CGA) > link-local address? > > If this is the case (client uses CGA link-local as IPv6 source address), > all is well. > > If the CGA address is not the link-local, then there is a conflict with > RFC 3315: > > 16. Client Source Address and Interface Selection > > When a client sends a DHCP message to the > All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message > through the interface for which configuration information is being > requested. However, the client MAY send the message through another > interface attached to the same link, if and only if the client is > -> certain the two interfaces are attached to the same link. The client > -> MUST use a link-local address assigned to the interface for which it > -> is requesting configuration information as the source address in the > -> header of the IP datagram. > > When a client sends a DHCP message directly to a server using unicast > (after receiving the Server Unicast option from that server), the > source address in the header of the IP datagram MUST be an address > assigned to the interface for which the client is interested in > obtaining configuration and which is suitable for use by the server > in responding to the client. > > A non-link-local address is only allowed if the server previously > provided the client with the Server Unicast option. I believe we are talking about link-local CGAs here. However, "link-local (CGA) addresses are vulnerable because the same prefix is used by all IPv6 node", [section 7.2, rfc 3972]. Fortunately, the same section provides a hash extension mechanism to protect link-local address. > --- > > The following text is rather odd: > > If a node has been configured to use Secure DHCPv6, the node MUST > send a message using a CGA, which be constructed as specified in > Section 4 of [RFC3972], as the source address unless they are sent > -> with the unspecified source address. In the message, both the CGA > option and the Signature option MUST be present in all DHCPv6 > messages. The CGA Parameter field in the CGA option is filled > according to the rules presented above and in [RFC3972]. The public > key in the field is taken from the configuration used to generate the > > CGA, typically from a data structure associated with the source > address. The Signature option MUST be constructed as explained in > Section 5.2 and be the last DHCPv6 option. > > DHCPv6 never uses an unspecified source address. This came from the similar claim in SEND. Ok, "unless they are sent > -> with the unspecified source address" will be revomed. > Also be good to use "CGA Parameter option" instead of "CGA option", as > that is what the option is called. This is an issue throughout the > document. Will change it. "CGA Parameter option" is the name to be. My thanks, again. Best regards, Sheng > - Bernie > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Bernie Volz (volz) > Sent: Saturday, January 17, 2009 11:03 PM > To: JiangSheng 66104; [email protected]; [email protected] > Subject: Re: [dhcwg] "Secure DHCPv6 Using > CGAs"draft-jiang-dhc-secure-dhcpv6-01 > > 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? > > 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.) > > 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). > > --- > > 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. > > - 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 > _______________________________________________ > 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
