Network Working Group Sheng Jiang Internet Draft Sam(Zhongqi) Xia Expires: December 2007 Huawei Technologies Co., Ltd Alberto Garcia-Martinez UC3M July 1st, 2007 Requirements for configuring Cryptographically Generated Addresses (CGA) and overview on RA and DHCPv6-based solutions draft-jiang-sendcgaext-cga-config-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. This document may only be posted in an Internet-Draft. 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 December 31, 2007. Abstract This document analyzes the requirements for the configuration Cryptographically Generated Addresses (CGA, [CGA]) and Multi-key CGAs [MCGA]. The applicability of Router Advertisement and DHCPv6 for this configuration is also discussed. Jiang, et al. Expires December 31, 2007 [Page 1] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Requirements..................................................3 3.1. Configuration of the parameters required for the generation of CGA........................................................3 3.2. CGA validation and registration..........................5 3.3. Configuration the parameters required for the generation of MCGAs.........................................................5 4. Solution overview.............................................5 4.1. Node requests CGA-related configuration parameters to the DHCP server...................................................7 4.2. Node requests to the DHCPv6 server the computation of the Modifier......................................................7 4.3. Node requests DHCPv6 server to validate the CGA..........7 4.4. Node informs the server about the CGA being configured...7 4.5. Node sends MCGA-specific information to the DHCPv6 server7 5. Security Considerations.......................................8 5.1. Threat Analysis of the Configuration Requirements........8 5.1.1. Threats faced by the end hosts......................8 5.1.2. Threats faced by the configuration servers..........9 5.2. Threat Analysis of the Solutions Proposed...............10 5.2.1. Router Advertisement with SEND support.............10 5.2.2. Router Advertisement without SEND support..........10 5.2.3. DHCPv6.............................................11 6. IANA Considerations..........................................11 7. Conclusions..................................................11 8. Acknowledgments..............................................11 9. References...................................................12 9.1. Normative References....................................12 9.2. Informative References..................................12 Author's Addresses..............................................13 Intellectual Property Statement.................................13 Disclaimer of Validity..........................................13 Copyright Statement.............................................14 Acknowledgment..................................................14 1. Introduction Cryptographically Generated Addresses [CGA] provide means to verify the ownership of IPv6 addresses without requiring any security infrastructure such as a certification authority. As an extension to enable SEND [SEND] proxy support multi-key CGAs [MCGA] have been Jiang, et al. Expires December 31, 2007 [Page 2] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 introduced The use of both types of addresses has been proposed for allowing identity verification in different protocols, such as SEND [SEND], MIPv6 [OMIP] or SHIM6 [SHIM6-proto]. In the current specifications there is a lack of procedures to enable proper management of CGA generation, in particular, in the configuration of the parameters that define the security properties of the addresses. Additionally, there is a lack of tools for informing the hosts about the availability of SEND proxies, and exchanging the required information with the proxies. Finally, there are no means to delegate the computation of the Modifier, a CPU intensive operation, to faster or non battery-dependant resources. This draft analyses the configuration requirements raised by CGA and MCGA generation. Additionally, the applicability of Router Advertisement and DHCPv6 for performing this configuration is discussed. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. Requirements The CGA specifications [CGA, MCGA] define the procedure to generate a CGA. However, these procedures do not allow the enforcement of a given configuration to a group of hosts, nor address the interactions between end hosts and proxies required for proxy configuration. It does also not consider the delegation of CPU-intensive operations to other nodes. In this section, we analyze the scenarios in which these operations are required. 3.1. Configuration of the parameters required for the generation of CGA The CGA associated Parameters used to generate a CGA includes several parameters [RFC 3972]: - a Public Key, - a Prefix Subnet, - a Modifier that is selected so that the result of a hash to comply with the requirements introduced by the value of a security parameter Sec in order to provide protection against brute-force attacks, Jiang, et al. Expires December 31, 2007 [Page 3] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 - a Collision Count value, increased each time the address generated results in a collision in the subnet considered, - any Extension Fields that could be used. Additionally, it should be noted that the hash algorithm to be used in the generation of the CGA is also defined by the Sec value [MHash]. Currently, there are convenient mechanisms for allowing an administrator to configure the subnet prefix for a host. Other parameters used for generating the CGA could also benefit from the possibility of being configured by the administrator. For instance, the administrator can determine, according to the type of infrastructure and the security needs, the Sec value that should be used by the hosts to generate the CGA. When appropriate, the Extension Fields could also be mandated by the administrator. Upon reception of this information, the end hosts SHOULD generate addresses compliant with the received parameters. If the parameters change, the end hosts SHOULD generate new addresses compliant with the parameters propagated. An important case to consider is the large computational consumption of the generation of the Modifier field. The Modifier is a 128 unsigned integer that is selected so that the Hash2 operation defined in RFC 3972 results in the required number of leftmost 0 bits. 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 in certain environments, such as mobile terminals with low computing power. As an example, consider a Sec value equals 2, requesting the leftmost 32 bits of an 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. The high number of required operations can represent a problem for end hosts (i.e. mobile devices) with much lower computing power than considered in the example, and/or with Jiang, et al. Expires December 31, 2007 [Page 4] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 restrictions in battery resources. For these cases, a mechanism for delegating the computation of the modifier should be provided. 3.2. CGA validation and registration As described in RFC 3972, a modifier is designed to be reused when only prefixes change. However, when a mobile node moves from a network to another, not only the prefix changes, but also other CGA relevant parameters may change. Therefore, any pre-generated CGA should be validated by the networking management plate. A node that has generated a CGA could register the resulting address so that a central administration could manage this information. The node could be requested to perform this registration. 3.3. Configuration the parameters required for the generation of MCGAs Multi-Key Cryptographically Generated Addresses (MCGAs) enable secure address proxying while preserving location privacy. First of all, end hosts should be notified that their SEND validation could be proxied, and therefore that they should generate MCGA addresses. In order to do generate the MCGA, and in addition to the Sec parameter and Extension Fields required for CGA bootstrapping, the node must know the node's own public key and the public key(s) from its proxy(s), which are certified router public keys. RFC 3971 describe a mechanism that allows the node to obtain the public keys of the router(s), although other protocols could be used for this purpose. Additionally, the proxy(s) should be notified the new MCGA and its associated CGA Parameters Data Structure, so that the proxy could securely proxy the MCGA by signing the message with its own private key. Consequently, a mechanism for making proxy(s) aware of the keys used by each end host should be provided. Upon reception of this information, the end hosts SHOULD generate MCGAs compliant with the received parameters. If the parameters change, the end hosts SHOULD generate new MCGAs compliant with the parameters propagated. 4. Solution overview Among the mechanisms in which configuration parameters could be pushed to the end hosts and/or CGA related information sent back to a central administration, we discuss two mechanisms: the stateless Jiang, et al. Expires December 31, 2007 [Page 5] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 address configuration mechanism based in Router Advertisement, and the stateful configuration mechanism based in DCHPv6. On one hand, Router Advertisement could be extended with an option that could convey parameters related with CGA configuration, such as the value of the Sec or the values of future Extension Fields, etc. In this way, a router could distribute these parameters to all the hosts of the subnet through Router Advertisement, in the same message in which prefix information is conveyed. On the other hand, DHCPv6 can be extended to - propagate to the end hosts the values of the basic parameters required to configure CGAs, - request the node to propagate to the server the resulting CGA address, - obtain from the end host CGA information to update any database with the addresses being used , - inform the end hosts about the convenience for generating MCGA, - obtain from the end hosts the MCGA information required to configure the proxy(s), - receive requests for generating a Modifier according to a given security configuration, and returning the result to the end host. Finally, both Router Advertisement and DCHPv6 could be combined in the following cases: - When the node is requested by Router Advertisement to register the resulting CGA, DHCPv6 could be used to inform the DHCPv6 server about the resulting address, - When MCGA address are generated, Router Advertisement could be used to propagate the basic CGA parameters, and a notification that the end host should generate MCGA, and use DHCPv6 to inform the DHCPv6 server about the public key material used for MCGA generation, - When the node solicits the computation of the Modifier, after receiving a Router Advertisement with the Sec parameters and Extension Fields, it can issue the request through a DHCPv6 exchange. Jiang, et al. Expires December 31, 2007 [Page 6] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 We next describe in more detail the interactions foresee for DHCPv6. 4.1. Node requests CGA-related configuration parameters to the DHCP server A node requests the relevant CGA configuration information needed to the DHCPv6 server. The server responds with the configuration information for the node. If registration of the resulting address is required, the server can include such requirement in the message sent. If SEND proxies are available, the server informs the node that an MCGA should be generated. The public keys for the routers, along with their certificates, could be included in the response. After received the configuration information, the node generates a CGA (or a MCGA) based on its public key and the configuration information. 4.2. Node requests to the DHCPv6 server the computation of the Modifier A node requests the computation of the Modifier for a certain security configuration to the DHCPv6 server. The node includes the values selected for the CGA associated parameters, such as its public key, the value of the Sec parameter, etc. The server either computes the Modifier value, or redirects the computation to other node using a mechanism that is out of the scope of this draft. Once the server obtains the modifier, it computes the CGA or MCGA according to the process described in RFC 3972, and it responds to the node with the resulting address and the CGA Parameters Data Structure. 4.3. Node requests DHCPv6 server to validate the CGA A node requests DHCPv6 server to validate a pre-generated CGA. According to whether the CGA matches the CGA-related configuration parameters of the network, the DHCPv6 server sends an acknowledgement to the node, validates the CGA or indicate the node to generate a new CGA with the CGA-related configuration parameters of the network. 4.4. Node informs the server about the CGA being configured A node informs the DHCPv6 server about the CGA address that has been generated. The DHCPv6 server sends an acknowledgement to the node. 4.5. Node sends MCGA-specific information to the DHCPv6 server A node that has generated its MCGA informs the DHCPv6 server about the the MCGA and its associated CGA Parameters Data Structure. The DHCPv6 server sends an acknowledgement to the node. The server or the Jiang, et al. Expires December 31, 2007 [Page 7] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 node also needs to notify this information to the routers acting as SEND proxies, in a way that is out of the scope of this document. 5. Security Considerations 5.1. Threat Analysis of the Configuration Requirements 5.1.1. Threats faced by the end hosts We first discuss the threats that the clients may face as a result of the operations described in this document. Regarding to the configuration of the Sec parameter, the main risk is that a malicious node could propagate a Sec value providing less protection than intended by the network administrator, facilitating a brute force attack against the hash, or the selection of the weakest hash algorithm available for CGA definition. Even in the worst case, if the hash algorithm cannot be inverted, the expected number of iterations required for a brute force attack is O(2^59) in order to find a CGA Parameters Data Structure that matches with a given node. The propagation of different Sec values could force the nodes to generate different addresses, possibly requiring the generation of a new modifier, etc. The end host SHOULD store the addresses that were generated in the past according to different Sec values. The short number of different Sec values, 8, limits the ability to exploit Sec variation as a DOS attack. The disclosure of the Sec value to any party does not represent any threat. The analysis of the threats for the configuration of CGA Extension Fields should be performed in a case-by-case basis. Regarding to the propagation of MCGA-related information, an attacker could generate a key pair, and propagate the public key to the end host, so the MCGA generated were associated with the public key of the attacker, In this way, the attacker would be able to impersonate the end host for all the protocols for which MCGA were used, such as SEND. Note that the privacy features included in the MCGA design prevents correspondent nodes from realizing that the end host identity has been stolen. In addition, an attacker could propagate different public keys at a high frequency, forcing the end host to generate new MCGAs, resulting if repeated in a DOS attack. Jiang, et al. Expires December 31, 2007 [Page 8] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 The disclosure of the public keys of the proxy(s) used to build the MCGA does not represent any threat. Now we consider the threats involved in the delivery of the information used to build a MCGA to a SEND proxy. In this case, an attacker could generate fake information in order to exhaust the resources at the proxy. While computing resources are not compromised, since the only check required at the proxy is that its own certified key is included, the state associated to the proxy operation could be exhausted, or proxy operation slowed down. The disclosure of the public keys of an end host used to build the MCGA does not represent any threat. Finally, we consider the delegation of the Modifier computation. The configuration at a given end host of a Modifier not compliant with the Sec requirement could break any identity validation performed at other hosts could prevent any communication. However, this event can be easily detected at the end host by a performing the Hash2 computation and certifying that results in the required number of 0 bits. If it were impossible to obtain a valid Modifier, the end host would be forced to compute by itself the modifier, falling back to the current standard procedure. It is worth to note that the proposed operations do not exchange private keys. An operation requiring such exchange would be the generation of a CGA/MCGA in a different location than the final end host to which it is assigned. The benefits do not outweigh the risks. On one hand, the gain would be small, since a CGA-enabled host is expected to dynamically sign and validate signatures, and the cost of generating a key pair is not much higher. On the other hand, there are significant risks, associated to the fact that the compromise of the node generating the keys results in the compromise of the identities of many other systems, and the need for assuring private communications among the parties involved (possibly requiring cryptographic tools, key distribution, etc.) 5.1.2. Threats faced by the configuration servers In general, the threats that the configuration servers may face are related with DOS. An attacker could generate CGA registration requests in order to exhaust the server resources (or to impact on any other operation that depend on the registration of the CGAs). The considerations for MCGAs are similar, although in this case the impact is extended to proxies. Jiang, et al. Expires December 31, 2007 [Page 9] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 However, the most dangerous attack is bound to malicious requests to compute the Modifier, since the CPU cost for the server can be high, especially considering that the attacker could select a Sec value requiring the highest number of computations for the server. 5.2. Threat Analysis of the Solutions Proposed Now we discuss the security implications of the use of Router Advertisement and DHCPv6 for performing the proposed operations. To analyze the different scenarios regarding to security in which they can be applied, it is worth to note that the use of CGAs and MCGAs is not bound to SEND enabled networks, since they could be used for identity protection in other protocols such as MIPv6 or SHIM6. Therefore, we can consider different scenarios regarding to security: Router Advertisement with SEND support, Router Advertisement without SEND support, and DHCPv6. For Router Advertisement solutions, only parameter propagation and SEND proxy public key distribution are to be considered. 5.2.1. Router Advertisement with SEND support Since the integrity of the RA messages and the identity of their sender are protected by the SEND protocol, protection against malicious nodes generating inappropriate values for the Sec parameter or the Extension Fields is provided. The same protection is provided for the distribution of the public keys of the proxies required for MCGA generation. 5.2.2. Router Advertisement without SEND support In this case there is no protection against the generation of different Sec values, so an attacker could force the generation of CGA with the lowest protection allowed by the standard. It could also force the generation of up to 8 CGA addresses in the end host, wasting resources from the end host. Another attack is related with the association of the public key of an attacker to the MCGA of the end host. DOS attacks based on the request of multiple MCGAs could be issued, although in this case a rate limit set in the client could mitigate the impact. However, it should be noted that an attacker being able to generate Router Advertisements could also perform Man-In-The-Middle or DOS attacks, by registering itself as a default router for the subnet. Jiang, et al. Expires December 31, 2007 [Page 10] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 5.2.3. DHCPv6 All the configuration operations proposed in this document are initiated by the end host. From the point of view of the end host, the difficulty of generating fake responses that were accepted by the requesting node with the same transaction-id at the precise time is outstanding. However, attacks can be generated by nodes placed in path between the requesting end host and the DHCPv6 server. In particular, non-SEND enabled subnets are more prone to this type of attacks, although SEND does not provide full protection against MITM attacks. In this case, the Sec parameter could be forced to be the lowest secure, the node could be forced to compute up to 8 CGA addresses, or to compute MCGAs associated with the attacker. The mechanism based on DHCPv6 is also vulnerable to DOS attacks to the server, such as registration of large number of CGA, or request for Modifier computation. 6. IANA Considerations This document defines only the interaction models that involve the Router Advertisement and the DHCP protocol in the CGA generation procedure. The actual DHCP and Router Advertisement extensions are defined in other documents. 7. Conclusions This document analyses the requirements for the configuration Cryptographically Generated Addresses (CGA) and Multi-key CGAs. A central administration could configure some parameters such as Sec or Extension Fields to be used by the end hosts in CGA generation. The central administration could notify the availability of CGA proxies, requesting the generation of MCGAs, and propagating the keying material required for MCGAs, and obtaining the end host specific material resulting from this address generation. The computation of the Modifier could also be delegated by an end host to a more appropriate system. The tools discussed for this performing these interactions are Router Advertisement and the DHCP protocol. 8. Acknowledgments The authors would like to thank Marcelo Bagnulo Braun for been involved in the early requirement identification. Jiang, et al. Expires December 31, 2007 [Page 11] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 9. References 9.1. Normative References [AutoC] S. Thomson, "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998. [CGA] T. Aura, "Cryptographically Generated Address", RFC3972, March 2005. [DHCP] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6", RFC3315, July 2003. [IPv6Alloc] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC3177. September 2001. [MCGA] J. Kempf, "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Address", draft-kempf-mobopts- ringsig-ndproxy-02 (work in progress), March 2006. [MHash] M. Bagnulo, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) ", draft- bagnulo-multiple-hash-cga-03 (work in progress), March 2007. [SEND] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor Discovery (SEND) ", RFC 3971, March 2005. 9.2. Informative References [DHCP-MIP6] H. Jang, "DHCP Option for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-03 (work in progress), May 2007. [OMIP] J. Arkko, C. Vogt, W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC4866, May 2007. [SHIM6-proto] E. Nordmark, M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-08.txt (work in progress), May 2007. Jiang, et al. Expires December 31, 2007 [Page 12] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 Author's Addresses Sheng Jiang Huawei Technologies QuiKe Bld., No.6 Rd, Xinxi St., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China 100085 Phone: 86-10-82836774 Email: shengjiang@huawei.com Intellectual Property Statement 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. Disclaimer of Validity 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. Jiang, et al. Expires December 31, 2007 [Page 13] Internet-Draft draft-jiang-sendcgaext-config-00.txt July 2007 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jiang, et al. Expires December 31, 2007 [Page 14]