idnits 2.17.1 draft-ietf-csi-dhcpv6-cga-ps-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2010) is 4915 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sheng Jiang 2 Internet Draft Huawei Technologies Co., Ltd 3 Intended status: Informational Sean Shen 4 Expires: April 17, 2011 CNNIC 5 Tim Chown 6 University of Southampton 7 October 14, 2010 9 DHCPv6 and CGA Interaction: Problem Statement 11 draft-ietf-csi-dhcpv6-cga-ps-05.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF). Note that other groups may also distribute working 20 documents as Internet-Drafts. The list of current Internet-Drafts is 21 at http://datatracker.ietf.org/drafts/current/. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 This Internet-Draft will expire on April 17, 2011. 30 Copyright Notice 32 Copyright (c) 2010 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the Simplified BSD License. 45 Abstract 47 This document describes potential issues in the interaction between 48 DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the 49 scenario of using CGAs in DHCPv6 environments is discussed. Some 50 operations are clarified for the interaction of DHCPv6 servers and 51 CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may 52 have mutual benefits for each other, including using CGAs in DHCPv6 53 operations to enhance its security features and using DHCPv6 to 54 provide the CGA generation function. 56 Table of Contents 58 1. Introduction.................................................3 59 2. Coexistence of DHCPv6 and CGA................................3 60 3. What DHCPv6 can do for CGA...................................4 61 4. What CGA can do for DHCPv6...................................6 62 5. Security Considerations......................................7 63 6. IANA Considerations..........................................8 64 7. Acknowledgements.............................................8 65 8. Change Log [RFC Editor please remove]........................8 66 9. References...................................................9 67 9.1. Normative References....................................9 68 Author's Addresses.............................................10 70 1. Introduction 72 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 73 can assign addresses statefully. Although there are other ways to 74 assign IPv6 addresses [RFC4862, RFC5739], DHCPv6 is still useful when 75 an administrator requires more control over address assignments to 76 hosts. DHCPv6 can also be used to distribute other network 77 configuration information. 79 Cryptographically Generated Addresses (CGAs) [RFC3972] are IPv6 80 addresses for which the interface identifiers are generated by 81 computing a cryptographic one-way hash function from a public key and 82 auxiliary parameters. Associated with public & private key pairs, 83 CGAs are used in protocols, such as SEND [RFC3971] or SHIM6 84 [RFC5533], to provide address validation and integrity protection in 85 message exchanging. 87 As an informational document, this document aims to analyze the 88 possible interactions between CGAs and DHCPv6. Whether these 89 possibilities are going to be defined as solutions or standards in 90 the future, it is out of scope. 92 This document describes potential issues in the interaction between 93 DHCPv6 and CGAs. Firstly, the scenario of using CGAs in DHCPv6 94 environments is discussed. Some operations are clarified for the 95 interaction of DHCPv6 servers and CGA-associated hosts. We then also 96 discuss how CGAs and DHCPv6 may have mutual benefits for each other, 97 including using CGAs in DHCPv6 operations to enhance its security 98 features and using DHCPv6 to provide the CGA generation function. 99 This document is designed to generate further discussion on the 100 specifics of if/how the ideas in the document could be realized. 102 2. Coexistence of DHCPv6 and CGA 104 CGAs can be used with IPv6 Stateless Address Configuration [RFC4862]. 105 The public key system associated with the CGA address provides 106 message origin validation and integrity protection without the need 107 for negotiation and transportation of key materials. 109 CGAs were designed for SeND [RFC3971] and SeND is generally not used 110 in the same environment as a DHCP server. However, after CGA has been 111 defined, as an independent security property, many other CGA usages 112 have been proposed and defined, such as SHIM6 [RFC5533], Enhanced 113 Route Optimization for Mobile IPv6 [RFC4866], also using the CGA for 114 DHCP security purpose, analyzed in section 4 this document, etc. In 115 these scenarios, CGAs may be used in DHCPv6-managed networks. 117 The current CGA specifications do not mandate which device generates 118 a CGA address. In many cases, a CGA address is generated by the 119 associated key pair owner, which normally is also the host that will 120 use the CGA address. However, in a DHCPv6-managed network, hosts 121 should use IPv6 global addresses only from a DHCPv6 server. This 122 difference of roles needs to be carefully considered if there is a 123 requirement to use CGAs in DHCPv6-managed environments. 125 The current DHCPv6 specification [RFC3315] has a mechanism that could 126 be used to allow a host to self-generate a CGA for use in a DHCPv6- 127 managed environment, i.e. the DHCPv6 server can grant the use of 128 host-generated CGA addresses on request from the client. 130 Specifically, a node can request that a DHCPv6 server grants the use 131 of a self-generated CGA by sending a DHCPv6 Request message. This 132 DHCPv6 Request message contains an IA option including the CGA 133 address. Depending on whether the CGA satisfies the CGA-related 134 configuration parameters of the network, the DHCPv6 server can then 135 send an acknowledgement to the node to either grant the use of the 136 CGA or to indicate that the node must generate a new CGA with the 137 correct CGA-related configuration parameters of the network. In the 138 meantime the DHCPv6 server may log the requested address/host 139 combination. 141 3. What DHCPv6 can do for CGA 143 In the current CGA specifications there is a lack of procedures to 144 enable central management of CGA generation. Administrators should be 145 able to configure parameters used to generate CGAs. DHCPv6 could be 146 used to assign subnet prefixes or other CGA-relevant parameters to 147 CGA address owners. In some scenarios, the administrator may further 148 want to enforce some parameters, in particular the necessary 149 security-related parameters such as the SEC value. 151 In the CGA generation procedure, the generation of the Modifier field 152 of a CGA address is computationally intensive. This operation can 153 lead to apparent slow performance and/or battery consumption problems 154 for end hosts with limited computing ability and/or restricted 155 battery power (e.g. mobile devices). As defined in [RFC3972], the 156 modifier is a 128 unsigned integer that is selected so that the 157 16*SEC leftmost bits of the second hash value, Hash2, are zero. The 158 modifier is used during CGA generation to implement the hash 159 extension and to enhance privacy by adding randomness to the CGA. The 160 higher the number of bits required being 0, the more secure a CGA is 161 against brute-force attacks. However, high number of bits also 162 results in additional computational cost for the generation process, 163 cost that could be deemed excessive. As an example, consider a Sec 164 value equals 2, requesting the leftmost 32 bits of a SHA-1 Hash2 to 165 be zero. For assuring this, a system has to generate in mean 2^32 166 different modifiers, and perform the Hash2 operation to check the 167 bits required to be 0. An estimation of the CPU power required to do 168 this can be obtained as following: openSSL can perform in an Intel 169 Core2-6300 on an Asus p5b-w motherboard close to 0.87 million of SHA- 170 1 operations on 16 byte blocks per second. Since the input data of 171 Hash2 operation is larger than 16 bytes, this value is an upper bound 172 for the number of hash operations that can be performed for 173 generating the modifier. Checking 2^32 different modifiers requires 174 around 5000 seconds. A practice experimental on a platform with an 175 Intel Duo2 (2.53GHz) workstation showed the results of average CGA 176 generating time as below: when SEC=0, it took 100us; SEC=1, 60ms; 177 SEC=2, 2000s (varies from 100~7000sec). The experiment was unable to 178 be performed for SEC=3 or higher SEC values. Theoretically 179 estimating, about 30000 hours are required to generate a SEC=3 CGA. 181 In such cases, a mechanism to delegate the computation of the 182 modifier would be desirable. It is possible that the whole CGA 183 generation procedure could be delegated to the DHCPv6 server. This 184 would be especially useful for large SEC values. 186 Generating a key pair, which will be used to generate a CGA, also 187 requires a notable computation. Generation and distribution of a key 188 pair can also be done by a DHCPv6 server. Of course, when designing 189 these new functions, one should carefully consider the impact on 190 security. However, the security considerations of specific solutions 191 are out of scope of this document. 193 New DHCPv6 options could be defined to carry management parameters 194 from a DHCPv6 server to the client that wishes to use a CGA. A new 195 DHCPv6 prefix assignment option could be defined to propagate a 196 subnet prefix. More DHCPv6 options may be defined to propagate 197 additional CGA-relevant configuration information, such as the SEC 198 value, SEND proxy information, etc. 200 It may be possible to define a delegation operation that allows a 201 client to pass computations to a DHCPv6 server, by introducing new 202 DHCPv6 option(s). A node could thus initiate a DHCPv6 request to the 203 DHCPv6 server requesting the computation of the Modifier or the CGA. 204 The DHCPv6 server could then either compute the Modifier by itself, 205 or redirect the computation requirement to another server. Once the 206 DHCPv6 server generates (or obtains from the redirected computational 207 server) the Modifier or the CGA address, it can respond to the node 208 with the Modifier or the resulting address and the corresponding CGA 209 Parameters data structure. 211 Depending on the scenario, the configuration information needed to 212 generate CGAs (including a SEC value, a subnet prefix, a modifier, a 213 public key, a Collision Count value and any Extension Fields) may be 214 provided by either hosts or DHCPv6 servers. A DHCPv6 server might 215 receive from hosts the configuration information customized by hosts, 216 generate CGAs by using configuration information provided by both 217 parties and deliver CGAs and their associated CGA Parameters data 218 structures to hosts. The details of such potential new methods need 219 to be defined clearly in the solution specifications. 221 New DHCPv6 options may be defined to support the interactions that 222 are required when a DHCPv6 server generates a key pair for hosts. 224 When designing such solutions, the designer should thoroughly 225 consider the impact on DHCPv6 model and the security of CGA usage. In 226 order to be compatible with DHCPv6, the configuring procedure of CGA 227 parameters should be compatible with the current DHCPv6 definition. 228 When a DHCP6 server configures CGA parameters, integrity protection 229 may be needed to avoid attacks, such as downgrade attack. 231 4. What CGA can do for DHCPv6 233 DHCPv6 is vulnerable to various attacks, e.g. fake address attacks 234 where a 'rogue' DHCPv6 server responds with incorrect address 235 information. A malicious rogue DHCPv6 server can also provide 236 incorrect configuration to the client in order to divert the client 237 to communicate with malicious services, like DNS or NTP. It may also 238 mount a Denial of Service attack through mis-configuration of the 239 client that causes all network communication from the client to fail. 240 A rogue DHCPv6 server may also collect some critical information from 241 the client. Attackers may be able to gain unauthorized access to some 242 resources, such as network access. See Section 23 [RFC3315]. 244 In the basic DHCPv6 specifications, regular IPv6 addresses are used. 245 However, DHCPv6 servers, relay agents and clients could use CGAs as 246 their own addresses. A DHCPv6 message (from either a server, relay 247 agent or client) with a CGA as source address can carry the CGA 248 Parameters data structure and a digital signature. The receiver can 249 verify both the CGA and signature, then process the payload of the 250 DHCPv6 message only if the validation is successful. A CGA option 251 with an address ownership proof mechanism and a signature option with 252 a corresponding verification mechanism may be introduced into DHCPv6 253 protocol. With these two new options, the receiver of a DHCPv6 254 message can verify the sender address of the DHCPv6 message, which 255 improves communication security of DHCPv6 messages. CGAs can be used 256 for all DHCPv6 messages/processes as long as CGAs are available on 257 the sender side. 259 Using CGAs in DHCPv6 protocol can efficiently improve the security of 260 DHCPv6. The address of a DHCPv6 message sender (which can be a DHCPv6 261 server, a reply agent or a client) can be verified by a receiver. 262 Also, the integrity of the sent data is provided if they are signed 263 with the private key associated to the public key used to generate 264 the CGA. The usage of CGA with pre-configured authorization, as 265 introduced in next paragraph, can efficiently avoid the 266 abovementioned attacks. It improves the communication security of 267 DHCPv6 interactions. The usage of CGAs can also avoid DHCPv6's 268 dependence on IPsec [RFC3315] in relay scenarios. This mechanism is 269 applicable in environments where physical security on the link is not 270 assured (such as over certain wireless infrastructures) or where 271 available security mechanisms are not sufficient, and attacks on 272 DHCPv6 are a concern. 274 A CGA generated from an unauthorized public & private key pair can 275 prove the source address ownership and provide data integrity 276 protection. Furthermore, a CGA generated from a certified public & 277 private key pair can also achieve authorization for DHCPv6 servers or 278 relays, or on another direction, user authorization. The public keys 279 may be pre-configured on both parties of communication or have a 280 third party authority available for users to retrieve public keys. 281 The public keys will be used for users to generate CGAs and verify 282 CGAs and signatures. The pre-configuration can also include 283 configuring more CGA parameters such as SEC value or more depending 284 on policies. The pre-configuration can even be the whole CGA and 285 related parameters, but in this case the address will be fixed. It 286 may increase the vulnerability to, e.g., brute force attacks. 288 5. Security Considerations 290 As Section 4 of this document has discussed, CGAs can provide 291 additional security features for DHCPv6. However, in defining 292 solutions using DHCPv6 to configure CGAs, as suggested in Section 3 293 of this document, careful consideration is required to evaluate 294 whether the new mechanism introduces new security vulnerabilities. 296 When DHCPv6 is used to manage CGAs, CGA relevant information is 297 stored in a central repository, DHCPv6 server. It does not increase 298 privacy risks. The CGA relevant information is only exposed to the 299 network management plane. The privacy risks are not higher than other 300 network managed entities, like normal IPv6 addresses managed by DHCP, 301 or addresses logged by ACL. 303 This document does not contain a complete security analysis and any 304 further work in this area should include such an analysis. Nobody 305 should implement the techniques described in this document without 306 conducting that more thorough analysis. 308 6. IANA Considerations 310 There are no IANA considerations in this document. 312 7. Acknowledgements 314 Useful comments were made by Marcelo Bagnulo, Alberto Garcia, Ted 315 Lemon, Stephen Hanna, Russ Housley and other members of the IETF CSI 316 working group. 318 8. Change Log [RFC Editor please remove] 320 draft-jiang-csi-dhcpv6-cga-ps-00, original version, 2008-10-27 322 draft-jiang-csi-dhcpv6-cga-ps-01, revised after comments at IETF 73, 323 2009-01-08 325 draft-jiang-csi-dhcpv6-cga-ps-02, revised after comments at CSI 326 mailing list, 2009-06-17 328 draft-jiang-csi-dhcpv6-cga-ps-03, revised after comments at CSI 329 mailing list, 2009-09-18 331 draft-ietf-csi-dhcpv6-cga-ps-00, revised after comments at CSI 332 mailing list and wg adoption call, 2009-10-12 334 draft-ietf-csi-dhcpv6-cga-ps-01, revised after comments at IETF 76, 335 2009-12-16 337 draft-ietf-csi-dhcpv6-cga-ps-02, revised after comments received in 338 CSI mail list, 2010-04-23 340 draft-ietf-csi-dhcpv6-cga-ps-03, revised after comments received in 341 CSI mail list, 2010-06-22 343 draft-ietf-csi-dhcpv6-cga-ps-04, revised after comments received in 344 CSI mail list, 2010-09-08 346 draft-ietf-csi-dhcpv6-cga-ps-05, revised after IESG comments 347 received, 2010-10-17 349 9. References 351 9.1. Normative References 353 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 354 M. Carney, "Dynamic Host Configure Protocol for IPv6", RFC 355 3315, July 2003. 357 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 358 Neighbor Discovery (SEND)", RFC 3971, March 2005. 360 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC 3972, 361 March 2005. 363 [RFC4862] S. Thomson and T. Narten, "IPv6 Stateless Address 364 Autoconfiguration", RFC 4862, September 2007. 366 [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route 367 Optimization for Mobile IPv6", RFC 4866, May 2007. 369 [RFC5533] M. Bagnulo and E. Nordmark, "Shim6: Level 3 Multihoming 370 Shim Protocol for IPv6", RFC 5533, June 2009. 372 [RFC5739] P. Eronen, J. Laganier, C. Madson, "IPv6 Configuration in 373 Internet Key Exchange Protocol Version 2 (IKEv2)", 374 RFC 5739, February 2010. 376 Author's Addresses 378 Sheng Jiang 379 Huawei Technologies Co., Ltd 380 KuiKe Building, No.9 Xinxi Rd., 381 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 382 P.R. China 383 Phone: 86-10-82836081 384 Email: shengjiang@huawei.com 386 Sean Shen 387 CNNIC 388 4, South 4th Street, Zhongguancun 389 Beijing 100190 390 P.R. China 391 Email: shenshuo@cnnic.cn 393 Tim Chown 394 University of Southampton 395 Highfield 396 Southampton, Hampshire SO17 1BJ 397 United Kingdom 398 Email: tjc@ecs.soton.ac.uk