Network Working Group Sheng Jiang Internet Draft Huawei Technologies Co., Ltd Intended status: Informational Sean Shen Expires: November 30, 2011 CNNIC Tim Chown University of Southampton May 30, 2011 DHCPv6 and CGA Interaction: Problem Statement draft-ietf-csi-dhcpv6-cga-ps-07.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 30, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jiang, et al. Expires November 30, 2011 [Page 1] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 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. Table of Contents 1. Introduction ................................................ 3 2. Coexistence of DHCPv6 and CGA ............................... 3 3. Configuring CGA-relevant parameters using DHCPv6 ............ 4 4. Using CGA to Protect DHCPv6 ................................. 5 5. Computation Delegation of CGA generation .................... 6 6. Conclusion .................................................. 7 7. Security Considerations ..................................... 8 8. IANA Considerations ......................................... 8 9. Acknowledgements ............................................ 8 10. Diff from last IESG review(2010-10)[RFC Editor please remove]9 11. References ................................................. 9 11.1. Normative References .................................. 9 Author's Addresses ............................................ 10 Jiang, et al. Expires November 30, 2011 [Page 2] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 1. Introduction The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can assign addresses statefully. Although there are other ways to assign IPv6 addresses [RFC4862, RFC5739], DHCPv6 is also used when network administrators require more control over address assignments or management to hosts. DHCPv6 can also be used to distribute other network configuration information from network to hosts. Cryptographically Generated Addresses (CGAs) [RFC3972] are IPv6 addresses for which the interface identifiers are generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. Associated with public & private key pairs, CGAs are used in protocols, such as SEND [RFC3971] or SHIM6 [RFC5533], to provide address validation and integrity protection in message exchanging. As an informational document, 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. Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Then, configuring CGA-relevant parameters using DHCPv6 is also discussed per parameters. Using CGA to protect DHCPv6 is recommended though the concrete protocol is not defined in this document. Although CGA generation delegation is considered not suitable for DHCPv6, it is also analyzed. Security considerations for proposed interactions are examined. 2. Coexistence of DHCPv6 and CGA CGAs were designed for SeND [RFC3971]. The CGA-associated public key, which is also transported to the receiver, provides message origin validation and integrity protection without the need for negotiation and transportation of key materials. SeND is generally not used in the same environment as a DHCP server. 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], also using the CGA for DHCPv6 security purpose, analyzed in section 4 this document, etc. In these scenarios, CGAs may be used in DHCPv6-managed networks. Jiang, et al. Expires November 30, 2011 [Page 3] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 A CGA address is generated by a host that owns the associated key pair. 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. Although the current DHCPv6 specification [RFC3315] has a mechanism that allow a host to request the assignment of a self-generated address from DHCPv6 servers, "DHCPv6 says nothing about details of temporary addresses like lifetimes, how clients use temporary addresses, rules for generating successive temporary addresses, etc." (quoted from Section 12 [RFC3315]. 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. Specifically, a node can request that a DHCPv6 server grants the use of a self-generated CGA by sending a DHCPv6 Request message. This DHCPv6 Request message contains an IA option including the CGA address. Depending on whether the CGA satisfies the CGA-related configuration parameters of the network, the DHCPv6 server can then send an acknowledgement to the node to either grant the use of the CGA or to indicate that the node must generate a new CGA with a suggested CGA-related configuration parameters of the network. In the meantime the DHCPv6 server may log the requested address/host combination, which completes CGA registration operation. 3. Configuring CGA-relevant parameters using DHCPv6 In the current CGA specifications, it is not possible that network management to influence the CGA generation. Administrators may want to be able to configure or suggest parameters used to generate CGAs. For example, if a network only accepts the network access requests from hosts that use CGAs with Sec value 1 or higher for security reasons, this information should be able to propagate to hosts. Hosts may generate such CGA in order to get access or use network services. The CGA associated Parameters used to generate a CGA includes several parameters [RFC3972]: - a Public Key. The key pair is generated by CGA owner. For security reasons, the key pair, more specifically the private key, should not be transported through networks. Central managed/generated key is conflict with primary CGA concept. Jiang, et al. Expires November 30, 2011 [Page 4] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 Therefore, there are no requirements for network to configure/suggest it. - a Prefix. The prefix can be obtained though Router Advertisement messages of neighbor discovery protocol. DHCPv6 may provide another mechanism to propagate the prefix information to the host. This may enable the CGA usage scenarios without ND attendance. - a 3-bit security parameter Sec. It is possible that networks request hosts to use CGAs with high Sec value for secure access. However, it is dangerous to allow network to enforce hosts to generate new CGAs with high Sec value, particularly the generation with high Sec value is extremely computational consumption, as analyzed in Section 5. A reasonable compromise could be the network gives suggested information for Sec value, only when the access requests from host are declined for low Sec value. - a Modifier. This is generated during the CGA generation procedure. Therefore, there are no requirements for network to configure/suggest it. - a Collision Count value. This is generated during the CGA generation procedure. Therefore, there are no requirements for network to configure/suggest it. - any Extension Fields that could be used. So far, there is no concrete use case for this parameter. If new Extension Fields are defined in the future, whether they are suitable to network- managed configuration should be carefully analyzed based on the specific case. 4. Using CGA to Protect DHCPv6 DHCPv6 is vulnerable to various attacks, e.g. fake address attacks where a "rogue" DHCPv6 server responds with incorrect address information. A malicious rogue DHCPv6 server can also provide incorrect configuration to the client in order to divert the client to communicate with malicious services, like DNS or NTP. It may also mount a Denial of Service attack through mis-configuration of the client that causes all network communication from the client to fail. A rogue DHCPv6 server may also collect some critical information from the client. Attackers may be able to gain unauthorized access to some resources, such as network access. See Section 23 [RFC3315]. In the basic DHCPv6 specifications, regular IPv6 addresses are used. However, DHCPv6 servers, relay agents and clients could use host- based CGAs as their own addresses. A DHCPv6 message (from either a Jiang, et al. Expires November 30, 2011 [Page 5] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 server, relay agent or client) with a CGA as source address can carry the CGA Parameters data structure and a digital signature. 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. With these two new options, the receiver of a DHCPv6 message can verify the sender address of the DHCPv6 message, which improves communication security of DHCPv6 messages. CGAs can be used for all DHCPv6 messages/processes as long as CGAs are available on the sender side. Using CGAs in DHCPv6 protocol can efficiently improve the security of DHCPv6. The address ownership of a DHCPv6 message sender (which can be a DHCPv6 server, a reply agent or a client) can be verified by a receiver. Also, the integrity of the sent data is provided if they are signed with the private key associated to the public key used to generate the CGA. It improves the communication security of DHCPv6 interactions. The usage of CGAs can also avoid DHCPv6's dependence on IPsec [RFC3315] in relay scenarios. This mechanism is applicable in environments where physical security on the link is not assured (such as over certain wireless infrastructures) or where available security mechanisms are not sufficient, and attacks on DHCPv6 are a concern. The usage of CGAs can prove the source address ownership and provide data integrity protection. Furthermore, CGAs of DHCPv6 servers may be pre-notified to hosts. Then, hosts may decline the DHCPv6 messages from other servers, which may be fake servers. But in this case the address will be fixed. It may increase the vulnerability to, e.g., brute force attacks. The pre-notification operation also needs to be protected, which is out of scope. 5. Computation Delegation of CGA generation As analyzed in this section, CGA generation may be computationally intensive when Sec value is set to be high. However, DHCPv6 servers are normally not computationally powerful to take such heavy burden, too. Particularly, a DHCPv6 server is architecturally designed to serve thousands hosts simultaneously. In the CGA generation procedure, the generation of the Modifier field of a CGA address is computationally intensive. This operation can lead to apparent slow performance and/or battery consumption problems for end hosts with limited computing ability and/or restricted battery power (e.g. mobile devices). As defined in [RFC3972], the modifier is a 128 unsigned integer that is selected so that the 16*SEC leftmost bits of the second hash value, Hash2, are zero. The Jiang, et al. Expires November 30, 2011 [Page 6] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 modifier is used during CGA generation to implement the hash extension and to enhance privacy by adding randomness to the CGA. The higher the number of bits required being 0, the more secure a CGA is against brute-force attacks. However, high number of bits also results in additional computational cost for the generation process, cost that could be deemed excessive. As an example, consider a Sec value equals 2, requesting the leftmost 32 bits of a SHA-1 Hash2 to be zero. For assuring this, a system has to generate in mean 2^32 different modifiers, and perform the Hash2 operation to check the bits required to be 0. An estimation of the CPU power required to do this can be obtained as following: openSSL can perform in an Intel Core2-6300 on an Asus p5b-w motherboard close to 0.87 million of SHA- 1 operations on 16 byte blocks per second. Since the input data of Hash2 operation is larger than 16 bytes, this value is an upper bound for the number of hash operations that can be performed for generating the modifier. Checking 2^32 different modifiers requires around 5000 seconds. A practice experimental on a platform with an Intel Duo2 (2.53GHz) workstation showed the results of average CGA generating time as below: when SEC=0, it took 100us; SEC=1, 60ms; SEC=2, 2000s (varies from 100~7000sec). The experiment was unable to be performed for SEC=3 or higher SEC values. Theoretically estimating, about 30000 hours are required to generate a SEC=3 CGA. Generating a key pair, which will be used to generate a CGA, also requires a notable computation, though this may only be issues on a very low-power host occasionally. A very low-power host might want to delegate its key and hash generation to a more general purpose computer. In such cases, a mechanism to delegate the computation of the modifier would be desirable. This would be especially useful for large SEC values. However, DHCPv6 servers are suitable to serve such computational delegation requests from thousands clients. Correspondently, the security analysis of CGA generation delegation and key generation delegation are out of scope. 6. Conclusion This document analyzed the possible interactions between CGA and DHCPv6. A few interactions has been declined by the analysis, including enforcing CGA Sec value, using DHCPv6 to manage CGAs, using DHCPv6 to assign certificates or centrally generated key pair, using DHCPv6 for delegating CGA generation or key generation, etc. This document suggests a few possible interactions may be defined in the future: Jiang, et al. Expires November 30, 2011 [Page 7] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 - 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. 7. Security Considerations 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. 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. DHCPv6 snooping, DHCPv6 authentication and DHCPv6 server using CGAs can help to prevent or discover bogus prefixes. 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. Using CGA as source addresses of DHCPv6 servers, relays or, also in DHCPv6 message exchanging provides the source address ownership verification and data integrity protection. 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. 8. IANA Considerations There are no IANA considerations in this document. 9. Acknowledgements Useful comments were made by Marcelo Bagnulo, Alberto Garcia, Ted Lemon, Stephen Hanna, Russ Housley, Sean Turner, Tim Polk, Jari Jiang, et al. Expires November 30, 2011 [Page 8] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 Arkko, David Harrington and other members of the IETF CSI working group. 10. Diff from last IESG review (2010-10) [RFC Editor please remove] Added CGA-DHCP co-existing scenarios, as the second paragraph in Section 2. Added the need for a DHCPv6 address registration operation in Section 2. Rewrite the CGA parameters configuration section. Analyze the requirements per CGA parameters. Added statement that network should not enforce the CGA parameters, but may suggest. Removed misleading words that linked CGA with PKI. Removed misleading words central managed CGA. Removed the combination of CGA and an external authentication/authorization, since it is conflict with primary CGA concept. Removed the possible operations that DHCPv6 server may assign certificates or centrally generated key pair. Added statement that CGA generation delegation is not suitable for DHCPv6 servers. Added a conclusion section so that the message from this document is clearly summarized. Rewrite the security consideration section. Only focus on proposed operations. 11. References 11.1. Normative References [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, "Dynamic Host Configure Protocol for IPv6", RFC 3315, July 2003. [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Jiang, et al. Expires November 30, 2011 [Page 9] Internet-Draft draft-ietf-csi-dhcpv6-cga-ps-07.txt May 2011 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC 3972, March 2005. [RFC4862] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC5533] M. Bagnulo and E. Nordmark, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [RFC5739] P. Eronen, J. Laganier, C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, February 2010. Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82882681 Email: jiangsheng@huawei.com Sean Shen CNNIC 4, South 4th Street, Zhongguancun Beijing 100190 P.R. China Email: shenshuo@cnnic.cn Tim Chown University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom Email: tjc@ecs.soton.ac.uk Jiang, et al. Expires November 30, 2011 [Page 10]