Network Working Group I. van Beijnum Internet-Draft IMDEA Networks Expires: May 15, 2008 November 12, 2007 Interactions between CGA and DHCPv6 draft-van-beijnum-cga-dhcp-interaction-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Cryptographically Generated Addresses as defined for IPv6 Secure Neighbor Discovery are generated locally on the host using the CGA. However, it can be desireable for other systems to be involved in the generation and use of CGAs in a number of ways: offloading the heavy cryptography for generating or validating CGAs, proxy-generation of CGAs for hosts that don't support the CGA-related protocols themselves or registration of CGA addresses for the purposes of central address administration. When additional hosts are involved in aspects of CGA, it's necessary to discover these other hosts van Beijnum Expires May 15, 2008 [Page 1] Internet-Draft Interactions between CGA and DHCPv6 November 2007 and/or additional configuration items such as the Sec value. The DHCPv6 is a natural choice for doing this. This document provides an overview of the opportunities and issues in this area. 1. Dissemination of CGA parameters through DHCPv6 Under normal circumstances, CGAs [RFC 3972] require three pieces of information for their generation that may be subject to administrative configuration: the Sec value that determines the cryptographic strength of the hash in the interface identifier, the public key, and the subnet prefix. The Sec value looks like a good candidate for distribution using DHCPv6, but the problem with that would be bidding down attacks. Also, the point of a protocol like DHCP is to distribute settings that are relevant to the current network location. Now that CGAs have found uses beyond the local subnet in shim6 and MIPv6, it's not obvious that the value of the Sec parameter is something that should depend on the current location. Setting the Sec value administratively through a mechanism that isn't location-dependent could be a better option. Still, it may be advantageous to have a mechanism to push out a Sec value on the local network for SEND use if the bidding down problem can be solved. A possible solution here could be a CGA Sec option when DHCPv6 is deployed with authentication. The public key (or public/private key pair) is not an obvious candidate for inclusion in DHCPv6 configuration: either the host is in charge of its own security and CGA generation, in which case it should come up with its own keys, or it can't generate CGAs and it has no need for the keys. There doesn't seem to be useful middle ground here. Hosts will generally receive the subnet prefix through router advertisements. DHCPv6 is currently incapable of supplying just a prefix: it can only supply the entire address. It may be worth considering separating the subnet prefix bits from the interface identifier bits, and allow the host to come up with the subnet prefix and the server with the interface identifier, or the server with the subnet prefix and the host with the interface identifier. The latter would be useful in cases where a host generates CGAs but administrative control over the prefix bits is desired beyond what can be accomplished using stateless autoconfiguration. Discussion: how does a DHCPv6 server know which prefixes (and with which prefix lengths) are reachable on the subnet that a client van Beijnum Expires May 15, 2008 [Page 2] Internet-Draft Interactions between CGA and DHCPv6 November 2007 connects to? 2. Proxy generation of CGAs Shim6 uses HBA, an extension to CGA, to secure the binding between different addresses belonging to the same host. Proxy shim6 is a proposal to allow a middlebox to perform shim6 processing so that unmodified IPv6 hosts can enjoy shim6 benefits. For this, it's necessary that the HBAs are generated on a different system than the host holding the addresses in question. A similar situation may present itself with other CGA uses. Proxy generation of CGAs/HBAs can easily be done on a DHCPv6, which then assigns the resulting address(es) to the host in question. The DHCPv6 protocol is able to assign addresses to hosts, so this doesn't require a protocol modification. However, in this case no other information than the resulting address is communicated back to the host. 3. CGA proxying/offloading Various aspects of CGA processing can be rather resource intensive. The most obvious example of this is finding a hash with the requisite number of lower bits set to 0 when the Sec parameter is larger than 0. Another example is a denial of service attack when the host generates a challenge and a large number of responses comes back. The host then needs to perform cryptographic checks for all incoming packets. Another DoS vector would be a large number of incoming challenges. Since generating a hash is done with only public information, there are almost no security issues with offloading this processing to another host. (A very slight security risk is that the host doing the processing gets to delay the use of a CGA, potentially until such time that it is no longer secure.) So finding a CGA processing server would be useful. An option for this could be added to DHCPv6. However, DHCPv6 is a mechanism for configuration, not for service discovery. Proxy verification of incoming CGA-protected messages doesn't need configuration: a middlebox that monitors the configuration can perform the verification procedure and block all packets that fail verification. When the local host is challenged, it needs to perform a number of cryptographic operations. These could be offloaded to another system, but then there would have to be a secure channel towards that other system. Presumably, the relatively small gains aren't worth van Beijnum Expires May 15, 2008 [Page 3] Internet-Draft Interactions between CGA and DHCPv6 November 2007 the extra complexity. However, MCGAs could be useful here. The configuration and discovery requirements for that are best explored in an MCGA document. 4. Address registration The current DHCP model for IPv4 is that the DHCP server assigns addresses. Many operators of enterprise networks and similarly tightly administered networks have expressed the desire to hold on to this model when moving to IPv6, because they don't want to have hosts end up with essentially random IPv6 addresses. However, the notion that a server assigns an address is for the most part incompatible with CGA, although some exceptions are possible as per the previous discussion. A useful way to give network administrators most of what they want, while at the same time retaining compatibility with normal CGA operation would be for the host to generate one or more CGAs, and then register those with a DHCPv6 server. The current DHCPv6 protocol allows for a host to communicate a set of "preferred" addresses to the server. A host could generate CGA addresses and then ask a DHCPv6 server for address assignment, listing the CGA addresses in IA options. If the DHCPv6 server then grants the use of the requested addresses, the host is able to use the generated CGAs. In the meantime, the DHCPv6 server has had the opportunity to vet and log the address/host combination. 5. Certificate provisioning CGAs secure the relationship between a public/private key pair (certificate) and an address. To be useful in practice, it's necessary to know which certificates or certificate chains are trustworthy. DHCPv6 could be used to distribute this information, but that would require secure DHCPv6 operation, i.e., DHCPv6 authentication. The DHCPv6 authentication methods defined in RFC 3315 require a pre-shared key. Such a security mechanism is likely to be less secure than distributing certificates directly out-of- band, but it may be more convenient, especially is DHCPv6 authentication is used for other reasons to begin with. Because the security of pre-shared keys is limited anyway and the DHCPv6 option space is restricted, it could be useful to exchange just the fingerprints of certificates rather than the certificates in their entirety. van Beijnum Expires May 15, 2008 [Page 4] Internet-Draft Interactions between CGA and DHCPv6 November 2007 6. IANA considerations None. 7. Security considerations Security considerations are discussed throughout this document. Appendix A. Document and Author Information The latest version of this document will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the CGA-EXT mailinglist (https://www1.ietf.org/mailman/listinfo/cga-ext) or directly to the author. Author's Address Iljitsch van Beijnum IMDEA Networks Av. Universidad 30 Leganes, Madrid 28911 ES Phone: +34-91-6246245 Email: iljitsch@muada.com van Beijnum Expires May 15, 2008 [Page 5] Internet-Draft Interactions between CGA and DHCPv6 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). van Beijnum Expires May 15, 2008 [Page 6]