See my reply in lines. Cheers, Sheng
> 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. I understand this. Now, the problem is, for the same reason – to protect all DHCP message, including AUTH option, the Signature option wants to be generated after AUTH option. > 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. This is fine. I knew it. Again, the point is two options both want to be generated after another one. > 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. Yes, this can work. But one assumption you take here is AUTH provide more protection. I am not convinced yet. For me, AUTH and Signature have different purposes and it is not suitable to say one is safer than another one. They should be equal. Only one reason I can think out: AUTH has been clearly defined to be last-generated and we don’t want change the existing. If so, I am fine with above design. > 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. Are you suggestion to disable signature option to be used in relay message? This is fine, if the relay agent does not add its own options. However, if the relay agent does add some options, these options need to be protected too. In this case, the client has two signature options to be validated: first one from the relay agent, the second one is from the server within the encapsulated server message. However, I noticed that even the first one failed, the second one might success. This is something I am not very sure yet. For me, it seems mean options from relay agent are unsecure, but the options from server are secure. > 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. This is not about public key provision or distribution. It is after key has been configured. Servers and clients can validate the identity of message sender and the integrity of the message. > 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). Yes, this is one of the major scenarios. Also the client-to-server authentication is also important, to verify the client has the right to access and receive the service from the network/DHCP server. Regards, Sheng > -----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
