Analysis of Possible DHCPv6 and CGA Interactions
draft-ietf-csi-dhcpv6-cga-ps-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
09 | (System) | Notify list changed from csi-chairs@ietf.org, draft-ietf-csi-dhcpv6-cga-ps@ietf.org to (None) |
2012-12-05
|
09 | (System) | Document has expired |
2012-12-05
|
09 | (System) | State changed to Dead from AD is watching::Revised ID Needed |
2012-12-04
|
09 | Ralph Droms | State changed to AD is watching::Revised ID Needed from IESG Evaluation::AD Followup |
2012-04-17
|
09 | Stephen Farrell | [Ballot discuss] So since the authors clarified in -09 that this is not a problem statement (seems late in the day but whatever) I re-read … [Ballot discuss] 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. |
2012-04-17
|
09 | Stephen Farrell | [Ballot comment] - intro: what does "management to hosts" mean |
2012-04-17
|
09 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-03-28
|
09 | David Harrington | [Ballot comment] Updated for revision -09- This comment is about the inadequacies of security considerations. I think more would would be needed to assess whether … [Ballot comment] 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. |
2012-03-28
|
09 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
2012-03-12
|
09 | Sheng Jiang | New version available: draft-ietf-csi-dhcpv6-cga-ps-09.txt |
2012-03-08
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-03-08
|
08 | Sheng Jiang | New version available: draft-ietf-csi-dhcpv6-cga-ps-08.txt |
2012-01-09
|
07 | David Harrington | [Ballot discuss] Updated for revision -07- This discuss is about the lack of security considerations that would be needed to assess whether the proposals contained … [Ballot discuss] Updated for revision -07- This discuss is about the lack of security considerations that 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 Tim and Russ. 1) This document includes multiple proposals for combining DHCPv6 and CGA; it might be better to write each one as a separate document, since the security implications of each of these proposals differs. The security considerations should discuss the threats associated with each proposal. An alternative would be to include text with each proposal to discuss the security considerations related to that proposal. Some of the questions that deserve to be answered: Do we need to worry about man-in-the-middle attacks, and if so, what impact would it have, and how do we mitigate that threat? Do we need to worry about DoS attacks? Do we need to worry about integrity checking? replay? |
2012-01-09
|
07 | David Harrington | [Ballot comment] 1) The change log has been modifed to reflect what changes have been made. That is much more useful than the chnage log … [Ballot comment] 1) The change log has been modifed to reflect what changes have been made. That is much more useful than the chnage log in -05-. Thank you. 2) The English is rough. This document really needs review by a proficient English-speaker. In some cases the English is difficult to understand. |
2012-01-09
|
07 | David Harrington | [Ballot discuss] This discuss is about the lack of security considerations that would be needed to assess whether the proposals contained in the document are … [Ballot discuss] This discuss is about the lack of security considerations that 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 Tim and Russ. 1) This document includes multiple proposals for combining DHCPv6 and CGA; it might be better to write each one as a separate document, since the security implications of each of these proposals differs. The security considerations should discuss the threats associated with each proposal. An alternative would be to include text with each proposal to discuss the security considerations related to that proposal. Some of the questions that deserve to be answered: Do we need to worry about man-in-the-middle attacks, and if so, what impact would it have, and how do we mitigate that threat? Do we need to worry about DoS attacks? Do we need to worry about integrity checking? replay? |
2011-12-01
|
07 | Cindy Morgan | Removed from agenda for telechat |
2011-12-01
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-12-01
|
07 | Sean Turner | [Ballot comment] #1) abstract and s1: Having trouble parsing the following: OLD: This document analyzes the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs), … [Ballot comment] #1) abstract and s1: Having trouble parsing the following: OLD: This document analyzes the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs), and gives recommendations and reasons whether these possibilities should be developed as solutions or be declined in the future. NEW: This document analyzes the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs), and gives recommendations on whether or not these interactions should be developed as solutions. #2) s1: OLD: Then, configuring CGA-relevant parameters using DHCPv6 is also discussed per parameters NEW: Then, configuring CGA-relevant parameters using DHCPv6 is discussed. #3) s2: The use of "should" here is throwing me off. I think what you want to say is that for DHCP managed networks hosts get their addressed form DHCPv6 servers. OLD: However, in a DHCPv6-managed network, hosts should get their addresses from DHCPv6 servers. This may result that a DHCPv6-managed network declines the network access requests from CGA owners. NEW: However, hosts in DHCPv6-managed network get their addresses from DHCPv6 servers. For a DHCPv6-managed network, CGA owners could be declined network access. #4) s2: OLD: There is no existing operation to allow DHCPv6 servers to decline the requested CGA and reply suggestion in order to generate a new address accordingly. New DHCPv6 options may be defined to support DHCPv6 servers to decline the requested CGA, notify the hosts the reason and give suggestion information in order to generate a new CGA accordingly. NEW: There is no existing operation to allow DHCPv6 servers to decline the host-requested address and to reply with information to generate a a new address. New DHCPv6 options could be defined to allow DHCPv6 servers to decline requested-CGAs, to inform the host about why the address has been declined, and to give information needed to construct an acceptable CGA. #5) s2: OLD: Specifically, a node can request that a DHCPv6 server grants the use of a self-generated CGA by sending a DHCPv6 Request message. NEW: Specifically, a node could request that a DHCPv6 server grant the use of a self-generated CGA by sending a DHCPv6 Request message. #6) s3: r/it is not possible that network/it is not possible for network and I think you could leave this bit off: Hosts may generate such CGA in order to get access or use network services. You already made that point earlier. r/Central managed/generated key/Centrally managed/generated keys Again, maybe I'm over-reacting but this draft doesn't provide requirements: r/Therefore, there are no requirements for network to configure/suggest it./ Therefore, a mechanism to configure/suggest a value is not analyzed. Actually do this one 3 times (public key/modifier/collision count). #7) s4: A CGA option with an address ownership proof mechanism and a signature option with a corresponding verification mechanism may be introduced into DHCPv6 protocol. With these two new options, the receiver NEW: A CGA option with an address ownership proof mechanism and a signature option with a corresponding verification mechanism would allow the receiver #8) s4: OLD: Then, hosts may decline the DHCPv6 messages from other servers, which may be fake servers. NEW: Then, hosts can decline the DHCPv6 messages from other servers. They might be fake they might be real it's just not needed. #9) s5: r/computationally powerful to take such heavy burden, too. /computationally powerful enough to also generate CGAs for all of its hosts. #10) s6: OLD: A few interactions has been declined by the analysis, including NEW: The analysis has determined that a few interactions are not worth pursuing including: OLD: This document suggests a few possible interactions may be defined in the future: - allowing DHCPv6 servers to decline the requested CGA and reply suggestion in order to generate a new CGA accordingly, - using DHCPv6 to propagate prefix to hosts, - propagate the suggested Sec value to hosts, - DHCPv6 servers, relays or clients use CGA addresses as source addresses, also in DHCPv6 message exchanging. NEW (lets have just one bullet for declining and replying and be specific about what can be replied, making it parallel too): This document suggests a few possible interactions be investigated: - allowing DHCPv6 servers to decline requested-CGAs and reply with Prefix or Sec values to generate an appropriate CGAs, - using CGA addresses for interactions between DHCPv6 servers/relays and clients #11) s7: OLD: By allowing DHCPv6 servers to decline the requested CGA and reply suggestion in order to generate a new CGA accordingly, is actually increase the network access flexibility. This may also benefit the network security too. NEW: Allowing DHCPv6 servers to decline the requested-CGA and reply with information to generate an appropriate CGA might actually increase network access flexibility. This might also benefit the network security too. OLD (there's no mechanism yet and I don't think you're making recommendation hence may/can switch): Prefix is information that should be advertised. However, the new mechanism using DHCPv6 to propagate prefix to hosts gives attackers another way to propagate bogus prefixes, which may waste hosts resources. NEW: Prefix is information that can be advertised. However, if DHCPv6 propagates the prefix to hosts, then attackers have another way to propagate bogus prefixes. This can waste hosts' resources. OLD: The suggested Sec value is only replied to the host when requested CGA is declined by the DHCPv6 server. For security reasons, networks should NOT enforce any CGA parameters. Otherwise, malicious attackers may use this enforcement to attack hosts. Networks may suggest certain CGA parameters, but host does not have to follow. However, if the hosts not follow, they may not be able to access part or full network services. NEW (not sure I got this all right): When propagating the Sec value from the DHCPv6 server to host, it is only returned if the DHCPv6 declines the requested-CGA. For security reasons, networks SHOULD NOT enforce any CGA parameters. Enforcing CGA parameters could allow malicious attackers to attack hosts by forcing them to perform computationally intensive operations. Networks can suggest the Sec value, but hosts need not heed the suggestion. However, if the hosts do not follow the suggestion, then DHCPv6 servers might deny network services. |
2011-12-01
|
07 | Sean Turner | [Ballot discuss] This is an updated position based on -07. 1) I share the concerns raised by others. 2) s1: Using CGA to protect DHCPv6 … [Ballot discuss] 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. |
2011-12-01
|
07 | Pete Resnick | [Ballot comment] I reluctantly ballot "No objection" to this document, but given the other DISCUSSes, I think it's not an issue. Essentially, I agree with … [Ballot comment] 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. |
2011-12-01
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-12-01
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-30
|
07 | Peter Saint-Andre | [Ballot comment] I concur with the DISCUSS position lodged by Jari Arkko, and share some of the concerns expressed by other IESG members. |
2011-11-30
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-29
|
07 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-28
|
07 | Stephen Farrell | [Ballot discuss] - I agree with the thrust of discusses from the previous IESG review. Its hard to see why this document is useful. If … [Ballot discuss] - I agree with the thrust of discusses from the previous IESG review. Its hard to see why this document is useful. If there are problems with e.g. DHCP server authentication that can be solved in better ways, then write about that. If there are networks that prefer some CGA parameters over others then write about that Trying to mix these things seems counter productive at best and is not explained in the document that I can see. - For the 1st problem (DHCPv6 server address checking) I don't see that this describes a problem with a CGA related solution. There may be some tailored solution for this problem that is tractable that looks a bit like CGA but the argument as presented is backwards, you're saying "DHCP server auth is hard, CGA exists, therefore describing how CGA might be used for DHCP server auth is an interesting problem statement." That really is backwards esp. in the absence of an actual solution. (If you did have a clever scheme I'd forgive the lack of problem-statement purity;-) - For the 2nd "problem," is there evidence that its really a problem? If so, why not quote that? - The "computation delegation" seems to depend on the 2nd problem actually being a problem. Even if it were, what's that got to do with DHCP? CGA may depend on the prefix but that same prefix is used for hosts that don't use DHCP at all. And the significant computations don't depend on the prefix so can be done offline prior to any DHCP exchanges so again I don't that a real problem exists here related to DHCP. In summary - where's the evidence there are real problems? And if there is, what's the compelling argument for handling them in one document? |
2011-11-28
|
07 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
2011-11-04
|
07 | Roni Even | Request for Last Call review by GENART Completed. Reviewer: Roni Even. |
2011-11-04
|
07 | Ralph Droms | Placed on agenda for telechat - 2011-12-01 |
2011-11-04
|
07 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-11-04
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-11-01
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2011-11-01
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2011-10-26
|
07 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2011-10-21
|
07 | Amy Vezza | Last call sent |
2011-10-21
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (DHCPv6 and CGA Interaction: Problem Statement) to Informational RFC The IESG has received a request from the CGA & SEND MaIntenance WG (csi) to consider the following document: - 'DHCPv6 and CGA Interaction: Problem Statement' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document analyzes the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs), and gives recommendations and reasons whether these possibilities should be developed as solutions or be declined in the future. This document itself does NOT define any concrete solutions. Note that this is a second IETF Last Call for this document. draft-ietf-csi-dhcpv6-cga-ps-07.txt addresses points raised during the first IESG review of the document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ No IPR declarations have been submitted directly on this I-D. |
2011-10-21
|
07 | Amy Vezza | Last Call text changed |
2011-10-20
|
07 | Ralph Droms | Last Call was requested |
2011-10-20
|
07 | Ralph Droms | State changed to Last Call Requested from IESG Evaluation::AD Followup. |
2011-10-20
|
07 | Ralph Droms | Last Call text changed |
2011-05-29
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-05-29
|
07 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-07.txt |
2010-10-21
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2010-10-21
|
07 | Sean Turner | [Ballot discuss] This is an updated position. I believe that using CGAs with DHCP will be harmful to the Internet because it defeats one of … [Ballot discuss] This is an updated position. I believe that using CGAs with DHCP will be harmful to the Internet because it defeats one of the two primary purpose for CGAs, namely privacy. 1) When doing an analysis it's okay to state that a particular solution can be done but shouldn't be done. I think DHCPv6 combined with CGA is one of those. I share Russ' concerns and I think there are a number of other issues with the draft: 2) Sec 2: States: The public key system associated with the CGA address provides message origin validation and integrity protection without the need for negotiation and transportation of key materials. There's two problems with this statement: 1) There is no public key system with CGAs. It's just one public key, the whole point was there's no PKI (aka public key system). 2) CGAs include the public key so there is a need to transport key material. 3) Sec 2: States: The current CGA specifications do not mandate which device generates a CGA address. I thought the CGA specification was pretty clear on this: it's the address holder [RFC3972], the sender [RFC3971], or the mobile node [RFC4866]. 4) Sec 2: States: In many cases, a CGA address is generated by the associated key pair owner, which normally is also the host that will use the CGA address Actually, isn't this done in all cases except for the case suggested by this document. 5) Sec 2: States: However, in a DHCPv6-managed network, hosts should use IPv6 global addresses only from a DHCPv6 server. This is confusing to me because I'd define a DHCPv6-managed network where a clients get their addresses from DHCPv6 servers. 6) Sec 2: The last two paragraphs seem to be explaining the rationale for co-existence. I can see that DHCP might support this, but like Russ indicated I don't see the justification for this change. 7) Sec 3: States: In the current CGA specifications there is a lack of procedures to enable central management of CGA generation." Umm, isn't this one of the main points of CGAs?! 8) Sec 3: States: Administrators should be able to configure parameters used to generate CGAs... I think this statement is only true if you've bought the DHCPv6-CGA combination. 9) Sec 4: The second paragraph states: The receiver can verify both the CGA and signature, then process the payload of the DHCPv6 message only if the validation is successful. A CGA option with an address ownership proof mechanism and a signature option with a corresponding verification mechanism may be introduced into DHCPv6 protocol. Absent of some other configuration data, the receiver isn't going to know anything other than the sender owns the address. 10) Sec 5: The second paragraph compares DCHP with CGA to DHCP, but says nothing DHCP with CGA as compared to just using CGAs. There's also the throw away part about ACLs that is unexplained. |
2010-10-21
|
07 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to Discuss from Abstain by Sean Turner |
2010-10-21
|
07 | Ron Bonica | [Ballot discuss] Support DISCUSS positions from security ADs |
2010-10-21
|
07 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to Discuss from Undefined by Ron Bonica |
2010-10-20
|
06 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-06.txt |
2010-10-20
|
07 | David Harrington | [Ballot comment] 1) This is a comment meant to educate the editors. The change log is not very useful as written, and since it will … [Ballot comment] 1) This is a comment meant to educate the editors. The change log is not very useful as written, and since it will be removed on publication, it would not be helpful to modify it now. Typically, a change log discusses the major technical changes that occur between revisions. This can help reviewers, such as the IESG, understand whether certain design discussions have taken place during the life of the document, and what design decisions were made. But the change log here only has information that exposes the timing of the revisions, e.g., after ietf73, and that is not useful. |
2010-10-20
|
07 | David Harrington | [Ballot discuss] This is a wordy discuss, with the goal of explaining the myriad of things I think would need to be discussed before I … [Ballot discuss] This is a wordy discuss, with the goal of explaining the myriad of things I think would need to be discussed before I could even consider approving this for publication. Ultimately, the discuss is about the lack of security considerations that 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 Tim and Russ. 1) The security considerations section basically says this document has not considered the security implications of the designs proposed here. Well, that's exactly why we have a security considerations section - to include the considerations of the security implications. This document includes multiple proposals for combining DHCPv6 and CGA; it might be better to write each one as a separate document, since the security implications of each of these proposals differs. The security considerations should discuss the threats associated with each proposal. Do we need to worry about man-in-the-middle attacks, and if so, how do we mitigate that threat? Do we need to worry about DoS attacks? Do we need to worry about integrity checking? replay? Do we need to worry about authentication? The document does discuss this by proposing an extenral authentication/authorization mechanism, but using an external certification mechanism to authenticate/authorize CGA generators is itself a proposal that would require its own security considerations. It might be possible to use a specific existing standard, such as IBE, but even that would need to consider security issues of combining the security assumptions of IBE and CGA and DHCPv6. And what about the overhead of having to support CGA plus an authentication/authorization mechanism? I think the real benefit of CGA is not needing an external CA; but if you need an external CA to authenticate/authorize the CGA generator, what have you gained? 2) I question whether disclosure of CGA parameters (apparently described in the document as privacy) is not problematic. If the information is available though the network management interface, what types of precautions must the network management interface provide, and what would be the effect of not providing those protections? Is there a cascading vulnerability issue - if somebody can access the parameters through a network management interface, can they use those parameters to spoof the DHCP server. to give themselves access to the network? What happens if they can change the DHCPv6 CGA parameters via the network management interface? Can they manipulate that to give themselves a back door to byoass the security of other protocols that depend on the CGA? |
2010-10-20
|
07 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded by David Harrington |
2010-10-20
|
07 | Jari Arkko | [Ballot discuss] This is a good document, even if the actual message is quite short and simple, and at times the draft struggles a bit … [Ballot discuss] 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. |
2010-10-20
|
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2010-10-20
|
07 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to Undefined from Abstain by Ron Bonica |
2010-10-20
|
07 | Ron Bonica | [Ballot Position Update] New position, Abstain, has been recorded by Ron Bonica |
2010-10-20
|
07 | Tim Polk | [Ballot comment] What is an "unauthorized public & private key pair"? What is a "certified public & private key pair"? [section 4] |
2010-10-20
|
07 | Tim Polk | [Ballot discuss] I am submitting these issues as a discuss position, but please note that I expect to move from Discuss to Abstain since I … [Ballot discuss] 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] |
2010-10-20
|
07 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2010-10-18
|
07 | Sean Turner | [Ballot comment] Updating with additional issues I raised in an email to Marcelo. I am abstaining from this document. I believe that using CGAs with … [Ballot comment] Updating with additional issues I raised in an email to Marcelo. I am abstaining from this document. I believe that using CGAs with DHCP will be harmful to the Internet because it defeats one of the two primary purpose for CGAs, namely privacy. Update follows: Marcelo, I am unlikely to change my position. When doing an analysis it's okay to state that a particular solution can be done but shouldn't be done. I think DHCPv6+CGA is one of those. I share Russ' concerns and I think there are a number of other issues with the draft: 1) Sec 2: States: The public key system associated with the CGA address provides message origin validation and integrity protection without the need for negotiation and transportation of key materials. There's two problems with this statement: 1) There is no public key system with CGAs. It's just one public key, the whole point was there's no PKI (aka public key system). 2) CGAs include the public key so there is a need to transport key material. 3) Sec 2: States: The current CGA specifications do not mandate which device generates a CGA address. I thought the CGA specification was pretty clear on this: it's the address holder [RFC3972], the sender [RFC3971], or the mobile node [RFC4866]. 4) Sec 2: States: In many cases, a CGA address is generated by the associated key pair owner, which normally is also the host that will use the CGA address Actually, isn't this done in all cases except for the case suggested by this document. 5) Sec 2: States: However, in a DHCPv6-managed network, hosts should use IPv6 global addresses only from a DHCPv6 server. This is confusing to me because I'd define a DHCPv6-managed network where a clients get their addresses from DHCPv6 servers. 6) Sec 2: The last two paragraphs seem to be explaining the rationale for co-existence. I can see that DHCP might support this, but like Russ indicated I don't see the justification for this change. 7) Sec 3: States: In the current CGA specifications there is a lack of procedures to enable central management of CGA generation." Umm, isn't this one of the main points of CGAs?! 8) Sec 3: States: Administrators should be able to configure parameters used to generate CGAs... I think this statement is only true if you've bought the DHCPv6-CGA combination. 9) Sec 4: The second paragraph states: The receiver can verify both the CGA and signature, then process the payload of the DHCPv6 message only if the validation is successful. A CGA option with an address ownership proof mechanism and a signature option with a corresponding verification mechanism may be introduced into DHCPv6 protocol. Absent of some other configuration data, the receiver isn't going to know anything other than the sender owns the address. 10) Sec 5: The second paragraph compares DCHP+CGA to DHCP, but says nothing DHCP+CGA as compared to just using CGAs. There's also the throw away part about ACLs that is unexplained. |
2010-10-15
|
07 | Sean Turner | [Ballot comment] I am abstaining from this document. I believe that using CGAs with DHCP will be harmful to the Internet because it defeats one … [Ballot comment] I am abstaining from this document. I believe that using CGAs with DHCP will be harmful to the Internet because it defeats one of the two primary purpose for CGAs, namely privacy. |
2010-10-15
|
07 | Sean Turner | [Ballot Position Update] New position, Abstain, has been recorded by Sean Turner |
2010-10-13
|
05 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-05.txt |
2010-10-10
|
07 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Steve Hanna. |
2010-10-03
|
07 | Ralph Droms | Telechat date has been changed to 2010-10-21 from 2010-10-07 by Ralph Droms |
2010-10-03
|
07 | Ralph Droms | State changed to IESG Evaluation from IESG Evaluation - Defer by Ralph Droms |
2010-10-03
|
07 | Russ Housley | [Ballot discuss] The direction suggested by this document will undermine the privacy features associated with host-generated CGAs. In general, CGAs are not used … [Ballot discuss] 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. |
2010-10-03
|
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2010-09-30
|
07 | Amanda Baber | IANA understands that there are no IANA actions required upon approval of this document. |
2010-09-25
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Steve Hanna |
2010-09-25
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Steve Hanna |
2010-09-22
|
07 | Ralph Droms | State changed to IESG Evaluation - Defer from In Last Call by Ralph Droms |
2010-09-22
|
07 | Cindy Morgan | State changed to In Last Call from Last Call Requested by Cindy Morgan |
2010-09-22
|
07 | Ralph Droms | Last Call was requested by Ralph Droms |
2010-09-22
|
07 | Ralph Droms | State changed to Last Call Requested from AD Evaluation by Ralph Droms |
2010-09-22
|
07 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2010-09-22
|
07 | Ralph Droms | Ballot has been issued by Ralph Droms |
2010-09-22
|
07 | Ralph Droms | Created "Approve" ballot |
2010-09-22
|
07 | (System) | Ballot writeup text was added |
2010-09-22
|
07 | (System) | Last call text was added |
2010-09-22
|
07 | (System) | Ballot approval text was added |
2010-09-13
|
07 | Ralph Droms | State changed to AD Evaluation from Publication Requested by Ralph Droms |
2010-09-10
|
07 | Amy Vezza | Document Shepherd Write-up for draft-ietf-csi-dhcpv6-cga-ps-04 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally … Document Shepherd Write-up for draft-ietf-csi-dhcpv6-cga-ps-04 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Marcelo Bagnulo who has reviewed this version of the document and believes that us ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been discussed and reviewed by the WG and a few external reviewers. We issued 1 WGLC and nobody objected the publication. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No special concerns or issues. The document is an informational document describing the problem and the solution space. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG was not very energetic on this document. The document describes possible applications of CGAs and DHCP interaction and when the WG was asked whether there was enough interest to work on solutions, the reply was silence. As such, the consensus is based on most of the WG being indifferent. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No conflicts. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. I have verified the ID nits and found no issues. No MIB Doctor, media type nor UR type reviews are needed for this document. The document intended status is informational. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informative. All normative references are in RFC state. The is no downward dependency, since this is an informational document. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document has a IANA considerations section, but there is no IANA action required. No protocol extensions are required No new registry is created. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does no contain any section written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes potential issues in the interaction between DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may have mutual benefits for each other, including using CGAs in DHCPv6 operations to enhance its security features and using DHCPv6 to provide the CGA generation function. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing special that worth noting. Not a controversial document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? The document is an informational problem statement. The WG expressed no interest in working in the solutions to the problem though. The document had through reviews, including reviews from Alberto Garcia Martinez, Tony Cheneau and their comments were addressed. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Marcelo Bagnulo Area Director: Ralph Droms |
2010-09-10
|
07 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2010-09-10
|
07 | Amy Vezza | [Note]: 'Document shepherd: Marcelo Bagnulo (marcelo@it.uc3m.es)' added by Amy Vezza |
2010-09-08
|
04 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-04.txt |
2010-06-23
|
03 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-03.txt |
2010-04-23
|
02 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-02.txt |
2009-12-16
|
01 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-01.txt |
2009-10-12
|
00 | (System) | New version available: draft-ietf-csi-dhcpv6-cga-ps-00.txt |