idnits 2.17.1 draft-ietf-csi-dhcpv6-cga-ps-08.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 (March 8, 2012) is 4431 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: September 16, 2012 CNNIC 5 Tim Chown 6 University of Southampton 7 March 8, 2012 9 Analysis of Possible DHCPv6 and CGA Interactions 11 draft-ietf-csi-dhcpv6-cga-ps-08.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 September 16, 2012. 30 Copyright Notice 32 Copyright (c) 2012 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 analyzes the possible interactions between DHCPv6 and 48 Cryptographically Generated Addresses (CGAs), and gives 49 recommendations on whether or not these interactions should be 50 developed as solutions. 52 Table of Contents 54 1. Introduction ................................................ 3 55 2. Coexistence of DHCPv6 and CGA ............................... 3 56 3. Configuring CGA-relevant parameters using DHCPv6 ............ 4 57 4. Using CGA to Protect DHCPv6 ................................. 5 58 5. Computation Delegation of CGA generation .................... 6 59 6. Conclusion .................................................. 7 60 7. Security Considerations ..................................... 8 61 8. IANA Considerations ......................................... 8 62 9. Acknowledgements ............................................ 8 63 10. Diff from last IESG review (2010-10) [RFC Editor please remove]9 64 11. References ................................................. 9 65 11.1. Normative References .................................. 9 66 Author's Addresses ............................................ 10 68 1. Introduction 70 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 71 can assign addresses statefully. Although there are other ways to 72 assign IPv6 addresses [RFC4862, RFC5739], DHCPv6 is also used when 73 network administrators require more control over address assignments 74 or management to hosts. DHCPv6 can also be used to distribute other 75 network configuration information from network to hosts. 77 Cryptographically Generated Addresses (CGAs) [RFC3972] are IPv6 78 addresses for which the interface identifiers are generated by 79 computing a cryptographic one-way hash function from a public key and 80 auxiliary parameters. Associated with public & private key pairs, 81 CGAs are used in protocols, such as SEND [RFC3971] or SHIM6 82 [RFC5533], to provide address validation and integrity protection in 83 message exchanging. 85 As an informational document, this document analyzes the possible 86 interactions between DHCPv6 and Cryptographically Generated Addresses 87 (CGAs), and gives recommendations and reasons whether these 88 possibilities should be developed as solutions or be declined in the 89 future. This document itself does NOT define any concrete solutions. 91 Firstly, the scenario of using CGAs in DHCPv6 environments is 92 discussed. Then, configuring CGA-relevant parameters using DHCPv6 is 93 discussed. Although CGA generation delegation is considered not 94 suitable for DHCPv6, it is also analyzed. Security considerations for 95 proposed interactions are examined. 97 2. Coexistence of DHCPv6 and CGA 99 CGAs were designed for SeND [RFC3971]. The CGA-associated public key, 100 which is also transported to the receiver, provides message origin 101 validation and integrity protection without the need for negotiation 102 and transportation of key materials. SeND is generally not used in 103 the same environment as a DHCP server. 105 However, after CGA has been defined, as an independent security 106 property, many other CGA usages have been proposed and defined, such 107 as SHIM6 [RFC5533], Enhanced Route Optimization for Mobile IPv6 108 [RFC4866], etc. In these scenarios, CGAs may be used in DHCPv6- 109 managed networks. 111 A CGA address is generated by a host that owns the associated key 112 pair. However, hosts in DHCPv6-managed network get their addresses 113 from DHCPv6 servers. For a DHCPv6-managed network, CGA owners could 114 be declined network access. 116 Although the current DHCPv6 specification [RFC3315] has a mechanism 117 that allow a host to request the assignment of a self-generated 118 address from DHCPv6 servers, "DHCPv6 says nothing about details of 119 temporary addresses like lifetimes, how clients use temporary 120 addresses, rules for generating successive temporary addresses, etc." 121 (quoted from Section 12 [RFC3315]. There is no existing operation to 122 allow DHCPv6 servers to decline the host-requested address and to 123 reply with information to generate a new address. 125 New DHCPv6 options could be defined to allow DHCPv6 servers to 126 decline requested-CGAs, to inform the host about why the address has 127 been declined, and to give information needed to construct an 128 acceptable CGA. 130 Specifically, a node could request that a DHCPv6 server grants the 131 use 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 a 137 suggested CGA-related configuration parameters of the network. In the 138 meantime the DHCPv6 server may log the requested address/host 139 combination, which completes CGA registration operation. 141 3. Configuring CGA-relevant parameters using DHCPv6 143 In the current CGA specifications, it is not possible for network 144 management to influence the CGA generation. Administrators may want 145 to be able to configure or suggest parameters used to generate CGAs. 146 For example, if a network only accepts the network access requests 147 from hosts that use CGAs with Sec value 1 or higher for security 148 reasons, this information should be able to propagate to hosts. 150 The CGA associated Parameters used to generate a CGA includes several 151 parameters [RFC3972]: 153 - a Public Key. The key pair is generated by CGA owner. For 154 security reasons, the key pair, more specifically the private key, 155 should not be transported through networks. Centrally 156 managed/generated key is conflict with primary CGA concept. 157 Therefore, a mechanism to configure/suggest a value is not 158 analyzed. 160 - a Prefix. The prefix can be obtained though Router Advertisement 161 messages of neighbor discovery protocol. DHCPv6 may provide 162 another mechanism to propagate the prefix information to the host. 163 This may enable the CGA usage scenarios without ND attendance. 165 - a 3-bit security parameter Sec. It is possible that networks 166 request hosts to use CGAs with high Sec value for secure access. 167 However, it is dangerous to allow network to enforce hosts to 168 generate new CGAs with high Sec value, particularly the generation 169 with high Sec value is extremely computational consumption, as 170 analyzed in Section 5. A reasonable compromise could be the 171 network gives suggested information for Sec value, only when the 172 access requests from host are declined for low Sec value. 174 - a Modifier. This is generated during the CGA generation 175 procedure. Therefore, a mechanism to configure/suggest a value is 176 not analyzed. 178 - a Collision Count value. This is generated during the CGA 179 generation procedure. Therefore, a mechanism to configure/suggest 180 a value is not analyzed. 182 - any Extension Fields that could be used. So far, there is no 183 concrete use case for this parameter. If new Extension Fields are 184 defined in the future, whether they are suitable to network- 185 managed configuration should be carefully analyzed based on the 186 specific case. 188 4. Using CGA to Protect DHCPv6 190 DHCPv6 is vulnerable to various attacks, e.g. fake address attacks 191 where a "rogue" DHCPv6 server responds with incorrect address 192 information. A malicious rogue DHCPv6 server can also provide 193 incorrect configuration to the client in order to divert the client 194 to communicate with malicious services, like DNS or NTP. It may also 195 mount a Denial of Service attack through mis-configuration of the 196 client that causes all network communication from the client to fail. 197 A rogue DHCPv6 server may also collect some critical information from 198 the client. Attackers may be able to gain unauthorized access to some 199 resources, such as network access. See Section 23 [RFC3315]. 201 In the basic DHCPv6 specifications, regular IPv6 addresses are used. 202 However, DHCPv6 servers, relay agents and clients could use host- 203 based CGAs as their own addresses. A DHCPv6 message (from either a 204 server, a relay agent or a client) with a CGA as source address can 205 carry the CGA Parameters data structure and a digital signature. The 206 receiver can verify both the CGA and signature, then process the 207 payload of the DHCPv6 message only if the validation is successful. A 208 CGA option with an address ownership proof mechanism and a signature 209 option with a corresponding verification mechanism would allow the 210 receiver of a DHCPv6 message can verify the sender address of the 211 DHCPv6 message, which improves communication security of DHCPv6 212 messages. CGAs can be used for all DHCPv6 messages/processes as long 213 as CGAs are available on the sender side. 215 Using CGAs in DHCPv6 protocol can efficiently improve the security of 216 DHCPv6. The address ownership of a DHCPv6 message sender (which can 217 be a DHCPv6 server, a reply agent or a client) can be verified by a 218 receiver. Also, the integrity of the sent data is provided if they 219 are signed with the private key associated to the public key used to 220 generate the CGA. It improves the communication security of DHCPv6 221 interactions. The usage of CGAs combining with signature verification 222 can also avoid DHCPv6's dependence on IPsec [RFC3315] in relay 223 scenarios. This mechanism is applicable in environments where 224 physical security on the link is not assured (such as over certain 225 wireless infrastructures) or where available security mechanisms are 226 not sufficient, and attacks on DHCPv6 are a concern. 228 The usage of CGAs can prove the source address ownership and provide 229 data integrity protection. Furthermore, CGAs of DHCPv6 servers may be 230 pre-notified to hosts. Then, hosts can decline the DHCPv6 messages 231 from other servers. But in this case the address will be fixed. It 232 may increase the vulnerability to, e.g., brute force attacks against. 233 The pre-notification operation also needs to be protected, which is 234 out of scope. 236 5. Computation Delegation of CGA generation 238 As analyzed in this section, CGA generation may be computationally 239 intensive when Sec value is set to be high. However, DHCPv6 servers 240 are normally not computationally powerful enough to also generate 241 CGAs for all of its hosts.. Particularly, a DHCPv6 server is 242 architecturally designed to serve thousands hosts simultaneously. 244 In the CGA generation procedure, the generation of the Modifier field 245 of a CGA address is computationally intensive. This operation can 246 lead to apparent slow performance and/or battery consumption problems 247 for end hosts with limited computing ability and/or restricted 248 battery power (e.g. mobile devices). As defined in [RFC3972], the 249 modifier is a 128 unsigned integer that is selected so that the 250 16*SEC leftmost bits of the second hash value, Hash2, are zero. The 251 modifier is used during CGA generation to implement the hash 252 extension and to enhance privacy by adding randomness to the CGA. The 253 higher the number of bits required being 0, the more secure a CGA is 254 against brute-force attacks. However, high number of bits also 255 results in additional computational cost for the generation process, 256 cost that could be deemed excessive. As an example, consider a Sec 257 value equals 2, requesting the leftmost 32 bits of a SHA-1 Hash2 to 258 be zero. For assuring this, a system has to generate in mean 2^32 259 different modifiers, and perform the Hash2 operation to check the 260 bits required to be 0. An estimation of the CPU power required to do 261 this can be obtained as following: openSSL can perform in an Intel 262 Core2-6300 on an Asus p5b-w motherboard close to 0.87 million of SHA- 263 1 operations on 16 byte blocks per second. Since the input data of 264 Hash2 operation is larger than 16 bytes, this value is an upper bound 265 for the number of hash operations that can be performed for 266 generating the modifier. Checking 2^32 different modifiers requires 267 around 5000 seconds. A practice experimental on a platform with an 268 Intel Duo2 (2.53GHz) workstation showed the results of average CGA 269 generating time as below: when SEC=0, it took 100us; SEC=1, 60ms; 270 SEC=2, 2000s (varies from 100~7000sec). The experiment was unable to 271 be performed for SEC=3 or higher SEC values. Theoretically 272 estimating, about 30000 hours are required to generate a SEC=3 CGA. 274 Generating a key pair, which will be used to generate a CGA, also 275 requires a notable computation, though this may only be issues on a 276 very low-power host occasionally. 278 A very low-power host might want to delegate its key and hash 279 generation to a more general purpose computer. In such cases, a 280 mechanism to delegate the computation of the modifier would be 281 desirable. This would be especially useful for large SEC values. 283 However, DHCPv6 servers are not suitable to serve such computational 284 delegation requests from thousands clients. Correspondently, the 285 security analysis of CGA generation delegation and key generation 286 delegation are out of scope. 288 6. Conclusion 290 This document analyzed the possible interactions between CGA and 291 DHCPv6. The analysis has determined that a few interactions are not 292 worth pursuing including: enforcing CGA Sec value, using DHCPv6 to 293 manage CGAs, using DHCPv6 to assign certificates or centrally 294 generated key pair, using DHCPv6 for delegating CGA generation or key 295 generation, etc. 297 This document suggests a few possible interactions be investigated: 299 - allowing DHCPv6 servers to decline requested-CGAs and reply with 300 Prefix or Sec values to generate an appropriate CGAs, 301 - using CGA addresses for interactions between DHCPv6 302 servers/relays and clients 304 7. Security Considerations 306 Allowing DHCPv6 servers to decline the requested-CGA and reply with 307 information to generate an appropriate CGA might actually increase 308 network access flexibility. This might also benefit the network 309 security too. 311 Prefix is information that can be advertised. However, if DHCPv6 312 propagates the prefix to hosts, then attackers have another way to 313 propagate bogus prefixes. This can waste hosts' resources. DHCPv6 314 snooping, DHCPv6 authentication and DHCPv6 server using CGAs can help 315 to prevent or discover bogus prefixes. 317 When propagating the Sec value from the DHCPv6 server to host, it is 318 only returned if the DHCPv6 declines the requested-CGA. For security 319 reasons, networks should not enforce any CGA parameters. Enforcing 320 CGA parameters could allow malicious attackers to attack hosts by 321 forcing them to perform computationally intensive operations. 322 Networks can suggest the Sec value, but hosts need not heed the 323 suggestion. However, if the hosts do not follow the suggestion, then 324 the network might deny network services, including access services. 326 Using CGA as source addresses of DHCPv6 servers, relays or, also in 327 DHCPv6 message exchanging provides the source address ownership 328 verification and data integrity protection. 330 IF a DHCPv6 server rejected a client CGA based on a certain Sec 331 value, it should not suggest a new Sec value either equal or lower 332 than that rejected Sec value. 334 Without other pre-configured security mechanism, like pre-notified 335 DHCPv6 server address, using host-based CGA by DHCPv6 servers could 336 not prevent attacks claiming to be a DHCPv6 server. Alternatively, 337 IPsec may be used, but it is a heavier security mechanism. 339 8. IANA Considerations 341 There are no IANA considerations in this document. 343 9. Acknowledgements 345 Useful comments were made by Marcelo Bagnulo, Alberto Garcia, Ted 346 Lemon, Stephen Hanna, Russ Housley, Sean Turner, Tim Polk, David 347 Harrington, Jari Arkko and other members of the IETF CSI working 348 group. 350 10. Diff from last IESG review (2010-10) [RFC Editor please remove] 352 Added CGA-DHCP co-existing scenarios, as the second paragraph in 353 Section 2. 355 Added the need for a DHCPv6 address registration operation in Section 356 2. 358 Rewrite the CGA parameters configuration section. Analyze the 359 requirements per CGA parameters. 361 Added statement that network should not enforce the CGA parameters, 362 but may suggest. 364 Removed misleading words that linked CGA with PKI. 366 Removed misleading words central managed CGA. 368 Removed the combination of CGA and an external 369 authentication/authorization, since it is conflict with primary CGA 370 concept. 372 Removed the possible operations that DHCPv6 server may assign 373 certificates or centrally generated key pair. 375 Added statement that CGA generation delegation is not suitable for 376 DHCPv6 servers. 378 Added a conclusion section so that the message from this document is 379 clearly summarized. 381 Rewrite the security consideration section. Only focus on proposed 382 operations. 384 11. References 386 11.1. Normative References 388 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 389 M. Carney, "Dynamic Host Configure Protocol for IPv6", RFC 390 3315, July 2003. 392 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 393 Neighbor Discovery (SEND)", RFC 3971, March 2005. 395 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC 3972, 396 March 2005. 398 [RFC4862] S. Thomson and T. Narten, "IPv6 Stateless Address 399 Autoconfiguration", RFC 4862, September 2007. 401 [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route 402 Optimization for Mobile IPv6", RFC 4866, May 2007. 404 [RFC5533] M. Bagnulo and E. Nordmark, "Shim6: Level 3 Multihoming 405 Shim Protocol for IPv6", RFC 5533, June 2009. 407 [RFC5739] P. Eronen, J. Laganier, C. Madson, "IPv6 Configuration in 408 Internet Key Exchange Protocol Version 2 (IKEv2)", 409 RFC 5739, February 2010. 411 Author's Addresses 413 Sheng Jiang 414 Huawei Technologies Co., Ltd 415 Q14, Huawei Campus 416 No.156 Beiqing Road 417 Hai-Dian District, Beijing 100095 418 P.R. China 419 Phone: 86-10-82882681 420 Email: jiangsheng@huawei.com 422 Sean Shen 423 CNNIC 424 4, South 4th Street, Zhongguancun 425 Beijing 100190 426 P.R. China 427 Email: shenshuo@cnnic.cn 429 Tim Chown 430 University of Southampton 431 Highfield 432 Southampton, Hampshire SO17 1BJ 433 United Kingdom 434 Email: tjc@ecs.soton.ac.uk