Analysis of Possible DHCPv6 and CGA Interactions
draft-ietf-csi-dhcpv6-cga-ps-09
Discuss
(Tim Polk)
Yes
(Ralph Droms)
No Objection
(Gonzalo Camarillo)
(Wesley Eddy)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Jari Arkko Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2010-10-20)
Unknown
This is a good document, even if the actual message is quite short and simple, and at times the draft struggles a bit to explain its conclusions clearly. FWIW, I disagree with some of the discusses that I have seen. I do have a few concerns (one shared with Russ), however: Section 3 claims without good justification that CGA parameters should be managed by a central entity. I think a reasonable case can be made for some parameters (like algorithms, Sec) but maybe not all. I can see also good reasons why central administration would be a bad idea (e.g., prefix is a local network matter and comes from the RAs). In any case, the document is silent about all this. Section 3 also suggests that with Sec>0 the generation of the hashes is something that should be centralized. Again, I can see also some reasons not to. In particular, Sec was not designed as a way to burden current machines but to enable higher cost searches when machines get faster. That is, if generating a Sec>0 value is a big burden for our computers, we should probably still use Sec=0. (I think there is a better argument than the one used in the draft. A very low-power host might want to delegate its key and hash generation to a more general purpose computer.) Section 4 should expand on what the implications for using CGAs by DHCPv6 servers. I believe that might actually be useful, as you could tie different transactions with the same DHCPv6 server together, ensuring that it is still the same node. But you could not prevent someone claiming to be a DHCPv6 server. I agree with other ADs that the draft should handwave less when it describes the security implications of some new design. The idea of the draft should be to describe what CGA can bring to DHCP security, and the security implications cannot be skipped. One example where you could easily write some more specific analysis is the above issue on using unauthorized CGAs by DHCPv6 servers and what the security impacts of that are.
Ron Bonica Former IESG member
(was No Record, Abstain)
Discuss
Discuss
[Treat as non-blocking comment]
(2010-10-21)
Unknown
Support DISCUSS positions from security ADs
Russ Housley Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2010-10-03)
Unknown
The direction suggested by this document will undermine the privacy features associated with host-generated CGAs. In general, CGAs are not used in the same environment as a DHCP server, and I do not see a justification for this to change. Without providing a reason, this document asserts that local a administrator ought to manage CGA generation parameters. I am guessing that the concern is the computation burden, but this is not compelling. Further, RFC 3315 already allows a DHCPv6 server to reject a CGA generated with unacceptable parameters. This document discusses the use of DHCPv6 to assign certificates to CGA address owners. CGA 'ownership' can already be validated with the private key, so the need for a certificate is unclear. This document states: "... the generation of the Modifier field of a CGA address is computationally intensive." RFC 3972 seems indicate otherwise for most key sizes. In general, RSA key pair generation is not a big concern on modern processors. It might be a mild concern on mobile devices, but some detailed explanation is required.
Sean Turner Former IESG member
(was Abstain)
Discuss
Discuss
[Treat as non-blocking comment]
(2011-12-01)
Unknown
This is an updated position based on -07. 1) I share the concerns raised by others. 2) s1: Using CGA to protect DHCPv6 is recommended though the concrete protocol is not defined in this document. In s2 it say: also using the CGA for DHCPv6 security purpose, analyzed in section 4 this document, etc. I didn't think this document was providing recommendations on analyzing possible solutions. Maybe just delete this sentence? 3) s4: I'll have to think some more about this one: The usage of CGAs can also avoid DHCPv6's dependence on IPsec [RFC3315] in relay scenarios. How do CGAs provide replay protection? 4) s4: contains the following about pre-configured a CGA-enabled DHCPv6 server: But in this case the address will be fixed. It may increase the vulnerability to, e.g., brute force attacks. Brute force attacks against? 5) I think this is a typo but I want to be sure: However, DHCPv6 servers are suitable to serve such computational delegation requests from thousands clients. Shouldn't this be "not suitable" 6) s7 contains the following: Without other pre-configured security mechanism, like pre-notified DHCPv6 server address, using host-based CGA by DHCPv6 servers could not prevent attacks claiming to be a DHCPv6 server. I think you're talking about spoofing here. Is this really true? What happens when they use IPsec? 7) s7: One thing I think you also need to talk about is when the DHCPv6 server says no to the address based on a Sec value and then the DHCPv6 server says use a value one that is weaker.
Stephen Farrell Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2012-04-17)
Unknown
So since the authors clarified in -09 that this is not a problem statement (seems late in the day but whatever) I re-read the document and re-wrote my discuss points. However, the overall thrust of the discuss remains: I don't see that this document is useful or needed. But to the details: #0 I agree with other discussing ADs. #1 CGA's have privacy benefits, and the idea of "registering" those with a dhcp server would entirely remove that feature. I fail to see why a client would *ever* want to register its CGA, and the document makes only one incidental mention of privacy. That seems entirely insufficient to me. This echoes Russ' discuss with which I fully agree. You could resolve this discuss point by for example stating that, for privacy preserving reasons, there is no known use-case where it would make sense for a DHCP client to use a CGA. Additional changes would flow from that I would expect, if you were happy to take that approach. (But then that leaves *very* little text.) #2 Related to #1, but I don't get this bit: "However, after CGA has been defined, as an independent security property, many other CGA usages have been proposed and defined, such as SHIM6 [RFC5533], Enhanced Route Optimization for Mobile IPv6 [RFC4866], etc. In these scenarios, CGAs may be used in DHCPv6- managed networks." *Exactly* what use-cases exist for this involving a DHCP client? You need to explain, if you don't accept the approach suggested in #1. #3 I agree that it might, in principle, be interesting to use CGAs for DHCP servers or relays. However, I fail to see why section 4 (with DHCP client text removed) justifies this document and only section 4 (<1 page) seems to remain, if you accept #1. There are sometimes reasons why an RFC might be worthwhile with only one page of real content but this is not one of those cases IMO. You can just include that page in the relevant DHC WG document. I'm sorry, but I just don't think this is a useful document to produce.
Tim Polk Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2010-10-20)
Unknown
I am submitting these issues as a discuss position, but please note that I expect to move from Discuss to Abstain since I have significant issues with the overall direction. My issues include one "discuss-discuss" and a number of specific issues. Discuss-discuss: The document implies that centrally managed CGAs were envisioned in the original specs ("The current CGA specifications do not mandate which device generates a CGA address.") However, I see no evidence in RFC 3972 that centrally generated CGAs were envisioned. My reading assumes locally generated CGAs. Is there any evidence that the wg really thought CGAs would be generated centrally? Specific Issues: In my opinion, this document fails to establish that a problem exists. The current DHCPv6-CGA coexistence model is dismissed without a clear explanation, and the impact of centrally generated key pairs and modifiers on the security assumptions for protocols that employ CGAs is not explored at all. [sections 1 and 2] I believe that sections 3 and 4 should be addressed in separate documents, unless the authors believe that DHCPv6 only benefits from centrally managed CGAs. Putting both concepts in one document is confusing. [global] Increasing the security of a CGA against a brute force attack while weakening the base security assumptions may not be a good compromise. [section 3, glaringly absent from section 5] The rationale for centrally generated key pairs is very weak, since a node (e.g. a cell phone) can reuse the same key pair each time it joins a subnet and generates a new CGA. [section 3] It is unclear whether the concepts proposed in Section 4 ("What CGA can do for DHCPv6") rely on centrally managed CGAs or not. From what I can tell, traditional CGAs might be very useful for DHCPv6 deployments, but I am unsure about that. The document states that when DHCPv6 is used to manage CGAs "it does not increase privacy risks". Relative to what? IMHO, centrally generated CGAs have to increase privacy risks in comparison to CGAs generated by the host itself. [section 5] As stated in the security consideration, "This work does not include a complete security analysis". In my opinion, such an analysis is crucial to determining whether this "problem" should be solved. As alluded to above, that analysis needs to review the impact on current protocols that use CGAs. If those protocols assume local generation, what is the impact of the mechanisms described here? [section 5]
Ralph Droms Former IESG member
Yes
Yes
()
Unknown
David Harrington Former IESG member
(was Discuss)
No Objection
No Objection
(2012-03-28)
Unknown
Updated for revision -09- This comment is about the inadequacies of security considerations. I think more would would be needed to assess whether the proposals contained in the document are viable in an Internet environment. To a large degree, these comments mirror those from other ADs, so I will simplify my discuss to save I support the discusses raised by Tim and Russ and Stephen and Sean.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2011-12-01)
Unknown
I reluctantly ballot "No objection" to this document, but given the other DISCUSSes, I think it's not an issue. Essentially, I agree with Stephen's first DISCUSS: I don't know why the publication of this document is necessary. In particular, I note that the writeup says: The document is an informational problem statement. The WG expressed no interest in working in the solutions to the problem though. If the WG has no interest in addressing the issues here (indeed, there isn't a WG working on this problem anymore), and there are a list of questions not sufficiently addressed by this draft, it should probably be shelved until there is such a group. But it is only informational, so I won't object if it ends up going forward.
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2011-11-30)
Unknown
I concur with the DISCUSS position lodged by Jari Arkko, and share some of the concerns expressed by other IESG members.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown