Note that while the AUTH option needs to be generated last (since it covers the entire message), it does not have to be the LAST option in the message.
In DHCPv6, no entity (relay agent or server) adds options to the messages while it is 'in-flight' as is done for the DHCPv4 relay agent option. Once the message is formed, a relay may encapsulate it in a Relay Message option in its own message, but that does NOT alter the original message. I think: - CGA Signature can be anywhere in the message. - CGA Signature covers the ENTIRE message EXCEPT for some of its own fields and the AUTH option. - The AUTH option covers the ENTIRE message, including the CGA Signature option. This way, the AUTH gives complete protection of the entire message as it was intended to. I'm not sure if it will be common for the SIGNATURE and AUTH to be used together, as it seems to me that using the AUTH message gives the better protection to begin with. But, if they are used together, it works. I'd also highly recommend the CGA stuff be limited to clients and servers (a client can add/server validate). Note that a server can NOT use this for to provide proof of a CGA (the server's source address) because this ONLY works when the client and server are on the same link. If a relay agent is involved, the source address of the packet sent to the client is a relay agent address and thus the Signature would never validate. This I think makes this much simpler (though perhaps it defeats some of the purpose). --- I also haven't yet figured out (again, perhaps due to my lack of fully understanding all of this CGA stuff) what the benefit of this is. It seems to me that if a client needs a public and private key, and the server needs the public key, that using the AUTH option could be possible and would be far better? Perhaps all you need here is a mechanism for the key to be communicated -- which might mean new values of the AUTH Option protocol and algorithm fields and a definition for what is in the "authentication information". Also, this might then allow client-to-server and server-to-client authentication since the "CGA" is itself not involved. And, perhaps this works better to match the SEND model which is (if I recall correctly) where the router is using a CGA and wants to prove that it is a valid router to the client -- so, you ideally want the DHCPv6 server to prove that is a valid DHCPv6 server to the client (and the client only needs the public key -- not a private key). Thus, the server-to-client authentication is really of the most interest? And, this would now work (whereas it does not using the original design). - Bernie -----Original Message----- From: JiangSheng 66104 [mailto:[email protected]] Sent: Monday, January 19, 2009 5:07 PM To: Bernie Volz (volz) Cc: [email protected]; [email protected]; [email protected] Subject: Re: RE: [dhcwg] "Secure DHCPv6 Using CGAs" draft-jiang-dhc-secure-dhcpv6-01 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
