idnits 2.17.1 draft-ietf-csi-dhcpv6-cga-ps-06.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 21, 2010) is 4935 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 25, 2011 CNNIC 5 Tim Chown 6 University of Southampton 7 October 21, 2010 9 DHCPv6 and CGA Interaction: Problem Statement 11 draft-ietf-csi-dhcpv6-cga-ps-06.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 25, 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 As an informational document, this document aims to analyze the 57 possible interactions between CGAs and DHCPv6 from the functional 58 perspective. This document does NOT propose/define any concrete 59 solutions. Whether these possibilities are going to be defined as 60 solutions or standards in the future is out of scope. 62 Table of Contents 64 1. Introduction.................................................3 65 2. Coexistence of DHCPv6 and CGA................................3 66 3. What DHCPv6 can do for CGA...................................4 67 3.1. Configuring CGA-relevant parameters using DHCPv6........4 68 3.2. Computation Delegation of CGA generation using DHCPv6...5 69 4. What CGA can do for DHCPv6...................................6 70 5. Security Considerations......................................8 71 6. IANA Considerations..........................................8 72 7. Acknowledgements.............................................8 73 8. Change Log [RFC Editor please remove]........................8 74 9. References...................................................9 75 9.1. Normative References....................................9 76 Author's Addresses.............................................10 78 1. Introduction 80 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 81 can assign addresses statefully. Although there are other ways to 82 assign IPv6 addresses [RFC4862, RFC5739], DHCPv6 is still useful when 83 an administrator requires more control over address assignments to 84 hosts. DHCPv6 can also be used to distribute other network 85 configuration information. 87 Cryptographically Generated Addresses (CGAs) [RFC3972] are IPv6 88 addresses for which the interface identifiers are generated by 89 computing a cryptographic one-way hash function from a public key and 90 auxiliary parameters. Associated with public & private key pairs, 91 CGAs are used in protocols, such as SEND [RFC3971] or SHIM6 92 [RFC5533], to provide address validation and integrity protection in 93 message exchanging. 95 As an informational document, this document aims to analyze the 96 possible interactions between CGAs and DHCPv6 from the functional 97 perspective. This document does NOT propose/define any concrete 98 solution. Whether these possibilities are going to be defined as 99 solutions or standards in the future is out of scope. 101 This document describes potential issues in the interaction between 102 DHCPv6 and CGAs. Firstly, the scenario of using CGAs in DHCPv6 103 environments is discussed. Some operations are clarified for the 104 interaction of DHCPv6 servers and CGA-associated hosts. We then also 105 discuss how CGAs and DHCPv6 may have mutual benefits for each other, 106 including using CGAs in DHCPv6 operations to enhance its security 107 features and using DHCPv6 to provide the CGA generation function. 108 This document is designed to generate further discussion on the 109 specifics of if/how the ideas in the document could be realized. 111 2. Coexistence of DHCPv6 and CGA 113 CGAs can be used with IPv6 Stateless Address Configuration (SLAAC) 114 [RFC4862]. The CGA-associated public key, which is also transported 115 to the receiver, provides message origin validation and integrity 116 protection without the need for negotiation and transportation of key 117 materials. 119 CGAs were designed for SeND [RFC3971] and SeND is generally not used 120 in the same environment as a DHCP server. However, after CGA has been 121 defined, as an independent security property, many other CGA usages 122 have been proposed and defined, such as SHIM6 [RFC5533], Enhanced 123 Route Optimization for Mobile IPv6 [RFC4866], also using the CGA for 124 DHCP security purpose, analyzed in section 4 this document, etc. In 125 these scenarios, CGAs may be used in DHCPv6-managed networks. 127 In most cases, a CGA address is generated by the associated key pair 128 owner, which normally is also the host that will use the CGA address, 129 although the current CGA specifications do not consider or prohibit 130 generation delegation. However, in a DHCPv6-managed network, hosts 131 should use IPv6 global addresses only from DHCPv6 servers. This 132 difference of roles needs to be carefully considered if there is a 133 requirement to use CGAs in DHCPv6-managed environments. 135 The current DHCPv6 specification [RFC3315] has a mechanism that could 136 be used to allow a host to self-generate a CGA for use in a DHCPv6- 137 managed environment, i.e. the DHCPv6 server can grant the use of 138 host-generated CGA addresses on request from the client. 140 Specifically, a node can request that a DHCPv6 server grants the use 141 of a self-generated CGA by sending a DHCPv6 Request message. This 142 DHCPv6 Request message contains an IA option including the CGA 143 address. Depending on whether the CGA satisfies the CGA-related 144 configuration parameters of the network, the DHCPv6 server can then 145 send an acknowledgement to the node to either grant the use of the 146 CGA or to indicate that the node must generate a new CGA with the 147 correct CGA-related configuration parameters of the network. In the 148 meantime the DHCPv6 server may log the requested address/host 149 combination. 151 3. What DHCPv6 can do for CGA 153 3.1. Configuring CGA-relevant parameters using DHCPv6 155 In the current CGA specifications, it is not possible that network 156 management to influence the CGA generation. Administrators may want 157 to be able to configure parameters used to generate CGAs, for example 158 to indicate hosts to use higher Sec-value CGAs. DHCPv6 could be used 159 to assign subnet prefixes or other CGA-relevant parameters to CGA 160 address owners. In some scenarios, the administrator may further want 161 to enforce some parameters, in particular the necessary security- 162 related parameters such as the SEC value. 164 Depending on the scenario, the configuration information needed to 165 generate CGAs (including a SEC value, a subnet prefix, a modifier, a 166 public key, a Collision Count value and any Extension Fields) may be 167 provided by either hosts or DHCPv6 servers. A DHCPv6 server might 168 receive from hosts the configuration information customized by hosts, 169 generate CGAs by using configuration information provided by both 170 parties and deliver CGAs and their associated CGA Parameters data 171 structures to hosts. The details of such potential new methods need 172 to be defined clearly in the solution specifications. 174 When designing such solutions, the designer should thoroughly 175 consider the impact on DHCPv6 model and the security of CGA usage. In 176 order to be compatible with DHCPv6, the configuring procedure of CGA 177 parameters should be compatible with the current DHCPv6 definition. 178 When a DHCP6 server configures CGA parameters, integrity protection 179 may be needed to avoid attacks, such as downgrade attack. 181 3.2. Computation Delegation of CGA generation using DHCPv6 183 This document only analyzes the functional possibility of computation 184 delegation of CGA generation using DHCPv6. Whether CGA generation 185 could be delegated or whether DHCPv6 is the most suitable tool for 186 computation delegation of CGA generation are primary out of scope. 188 In the CGA generation procedure, the generation of the Modifier field 189 of a CGA address is computationally intensive. This operation can 190 lead to apparent slow performance and/or battery consumption problems 191 for end hosts with limited computing ability and/or restricted 192 battery power (e.g. mobile devices). As defined in [RFC3972], the 193 modifier is a 128 unsigned integer that is selected so that the 194 16*SEC leftmost bits of the second hash value, Hash2, are zero. The 195 modifier is used during CGA generation to implement the hash 196 extension and to enhance privacy by adding randomness to the CGA. The 197 higher the number of bits required being 0, the more secure a CGA is 198 against brute-force attacks. However, high number of bits also 199 results in additional computational cost for the generation process, 200 cost that could be deemed excessive. As an example, consider a Sec 201 value equals 2, requesting the leftmost 32 bits of a SHA-1 Hash2 to 202 be zero. For assuring this, a system has to generate in mean 2^32 203 different modifiers, and perform the Hash2 operation to check the 204 bits required to be 0. An estimation of the CPU power required to do 205 this can be obtained as following: openSSL can perform in an Intel 206 Core2-6300 on an Asus p5b-w motherboard close to 0.87 million of SHA- 207 1 operations on 16 byte blocks per second. Since the input data of 208 Hash2 operation is larger than 16 bytes, this value is an upper bound 209 for the number of hash operations that can be performed for 210 generating the modifier. Checking 2^32 different modifiers requires 211 around 5000 seconds. A practice experimental on a platform with an 212 Intel Duo2 (2.53GHz) workstation showed the results of average CGA 213 generating time as below: when SEC=0, it took 100us; SEC=1, 60ms; 214 SEC=2, 2000s (varies from 100~7000sec). The experiment was unable to 215 be performed for SEC=3 or higher SEC values. Theoretically 216 estimating, about 30000 hours are required to generate a SEC=3 CGA. 218 Sec was not designed as a way to burden current machines but to 219 enable higher cost searches when machines get faster. That is, if 220 generating a Sec>0 value is a big burden for our computers, host 221 should probably still use Sec=0. 223 A very low-power host might want to delegate its key and hash 224 generation to a more general purpose computer. 226 In such cases, a mechanism to delegate the computation of the 227 modifier would be desirable. It is possible that the whole CGA 228 generation procedure could be delegated to the DHCPv6 server. This 229 would be especially useful for large SEC values. 231 It may be possible to define a delegation operation that allows a 232 client to pass computations to a DHCPv6 server, by introducing new 233 DHCPv6 option(s). A node could thus initiate a DHCPv6 request to the 234 DHCPv6 server requesting the computation of the Modifier or the CGA. 235 The DHCPv6 server could then either compute the Modifier by itself, 236 or redirect the computation requirement to another server. Once the 237 DHCPv6 server generates (or obtains from the redirected computational 238 server) the Modifier or the CGA address, it can respond to the node 239 with the Modifier or the resulting address and the corresponding CGA 240 Parameters data structure. 242 Generating a key pair, which will be used to generate a CGA, also 243 requires a notable computation, though this may only be issues on a 244 very low-power host occasionally. Generation and distribution of a 245 key pair can also be done by a DHCPv6 server. Of course, when 246 designing these new functions, one should carefully consider the 247 impact on security. However, the security considerations of specific 248 solutions are out of scope of this document. 250 New DHCPv6 options may be defined to support the interactions that 251 are required when a DHCPv6 server generates a key pair for hosts. 253 4. What CGA can do for DHCPv6 255 DHCPv6 is vulnerable to various attacks, e.g. fake address attacks 256 where a 'rogue' DHCPv6 server responds with incorrect address 257 information. A malicious rogue DHCPv6 server can also provide 258 incorrect configuration to the client in order to divert the client 259 to communicate with malicious services, like DNS or NTP. It may also 260 mount a Denial of Service attack through mis-configuration of the 261 client that causes all network communication from the client to fail. 262 A rogue DHCPv6 server may also collect some critical information from 263 the client. Attackers may be able to gain unauthorized access to some 264 resources, such as network access. See Section 23 [RFC3315]. 266 In the basic DHCPv6 specifications, regular IPv6 addresses are used. 267 However, DHCPv6 servers, relay agents and clients could use host- 268 based CGAs as their own addresses. A DHCPv6 message (from either a 269 server, relay agent or client) with a CGA as source address can carry 270 the CGA Parameters data structure and a digital signature. The 271 receiver can verify both the CGA and signature, then process the 272 payload of the DHCPv6 message only if the validation is successful. A 273 CGA option with an address ownership proof mechanism and a signature 274 option with a corresponding verification mechanism may be introduced 275 into DHCPv6 protocol. With these two new options, the receiver of a 276 DHCPv6 message can verify the sender address of the DHCPv6 message, 277 which improves communication security of DHCPv6 messages. CGAs can be 278 used for all DHCPv6 messages/processes as long as CGAs are available 279 on the sender side. 281 Using CGAs in DHCPv6 protocol can efficiently improve the security of 282 DHCPv6. The address of a DHCPv6 message sender (which can be a DHCPv6 283 server, a reply agent or a client) can be verified by a receiver. 284 Also, the integrity of the sent data is provided if they are signed 285 with the private key associated to the public key used to generate 286 the CGA. The usage of CGA with pre-configured authorization, as 287 introduced in next paragraph, can efficiently avoid the 288 abovementioned attacks. It improves the communication security of 289 DHCPv6 interactions. The usage of CGAs can also avoid DHCPv6's 290 dependence on IPsec [RFC3315] in relay scenarios. This mechanism is 291 applicable in environments where physical security on the link is not 292 assured (such as over certain wireless infrastructures) or where 293 available security mechanisms are not sufficient, and attacks on 294 DHCPv6 are a concern. 296 A CGA generated from an unauthorized public & private key pair can 297 prove the source address ownership and provide data integrity 298 protection. Furthermore, a CGA generated from a certified public & 299 private key pair can also achieve authorization for DHCPv6 servers or 300 relays, or on another direction, user authorization. The public keys 301 may be pre-configured on both parties of communication or have a 302 third party authority available for users to retrieve public keys. 303 The public keys will be used for users to generate CGAs and verify 304 CGAs and signatures. The pre-configuration can also include 305 configuring more CGA parameters such as SEC value or more depending 306 on policies. The pre-configuration can even be the whole CGA and 307 related parameters, but in this case the address will be fixed. It 308 may increase the vulnerability to, e.g., brute force attacks. 310 5. Security Considerations 312 As Section 4 of this document has discussed, CGAs can provide 313 additional security features for DHCPv6. However, in defining 314 solutions using DHCPv6 to configure CGAs, as suggested in Section 3 315 of this document, careful consideration is required to evaluate 316 whether the new mechanism introduces new security vulnerabilities. 318 When DHCPv6 is used to manage CGAs, CGA relevant information is 319 stored in a central repository, DHCPv6 server. It does not increase 320 privacy risks. The CGA relevant information is only exposed to the 321 network management plane. The privacy risks are not higher than other 322 network managed entities, like normal IPv6 addresses managed by DHCP. 323 Of course, the privacy risk is higher than using CGA with SLAAC, in 324 which CGAs are fully host based. 326 Without other pre-configured security mechanism, like PKI, using 327 host-based CGA by DHCPv6 servers could not prevent attacks claiming 328 to be a DHCPv6 server. 330 This document does not contain a complete security analysis and any 331 further work in this area should include such an analysis. Nobody 332 should implement the techniques described in this document without 333 conducting that more thorough analysis. 335 6. IANA Considerations 337 There are no IANA considerations in this document. 339 7. Acknowledgements 341 Useful comments were made by Marcelo Bagnulo, Alberto Garcia, Ted 342 Lemon, Stephen Hanna, Russ Housley, Sean Turner, Tim Polk, Jari 343 Arkko, David Harrington and other members of the IETF CSI working 344 group. 346 8. Change Log [RFC Editor please remove] 348 draft-jiang-csi-dhcpv6-cga-ps-00, original version, 2008-10-27 350 draft-jiang-csi-dhcpv6-cga-ps-01, revised after comments at IETF 73, 351 2009-01-08 353 draft-jiang-csi-dhcpv6-cga-ps-02, revised after comments at CSI 354 mailing list, 2009-06-17 355 draft-jiang-csi-dhcpv6-cga-ps-03, revised after comments at CSI 356 mailing list, 2009-09-18 358 draft-ietf-csi-dhcpv6-cga-ps-00, revised after comments at CSI 359 mailing list and wg adoption call, 2009-10-12 361 draft-ietf-csi-dhcpv6-cga-ps-01, revised after comments at IETF 76, 362 2009-12-16 364 draft-ietf-csi-dhcpv6-cga-ps-02, revised after comments received in 365 CSI mail list, 2010-04-23 367 draft-ietf-csi-dhcpv6-cga-ps-03, revised after comments received in 368 CSI mail list, 2010-06-22 370 draft-ietf-csi-dhcpv6-cga-ps-04, revised after comments received in 371 CSI mail list, 2010-09-08 373 draft-ietf-csi-dhcpv6-cga-ps-05, revised after IESG comments 374 received, 2010-10-14 376 draft-ietf-csi-dhcpv6-cga-ps-06, revised after IESG comments 377 received, 2010-10-21 379 9. References 381 9.1. Normative References 383 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 384 M. Carney, "Dynamic Host Configure Protocol for IPv6", RFC 385 3315, July 2003. 387 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 388 Neighbor Discovery (SEND)", RFC 3971, March 2005. 390 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC 3972, 391 March 2005. 393 [RFC4862] S. Thomson and T. Narten, "IPv6 Stateless Address 394 Autoconfiguration", RFC 4862, September 2007. 396 [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route 397 Optimization for Mobile IPv6", RFC 4866, May 2007. 399 [RFC5533] M. Bagnulo and E. Nordmark, "Shim6: Level 3 Multihoming 400 Shim Protocol for IPv6", RFC 5533, June 2009. 402 [RFC5739] P. Eronen, J. Laganier, C. Madson, "IPv6 Configuration in 403 Internet Key Exchange Protocol Version 2 (IKEv2)", 404 RFC 5739, February 2010. 406 Author's Addresses 408 Sheng Jiang 409 Huawei Technologies Co., Ltd 410 KuiKe Building, No.9 Xinxi Rd., 411 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 412 P.R. China 413 Phone: 86-10-82836081 414 Email: shengjiang@huawei.com 416 Sean Shen 417 CNNIC 418 4, South 4th Street, Zhongguancun 419 Beijing 100190 420 P.R. China 421 Email: shenshuo@cnnic.cn 423 Tim Chown 424 University of Southampton 425 Highfield 426 Southampton, Hampshire SO17 1BJ 427 United Kingdom 428 Email: tjc@ecs.soton.ac.uk