idnits 2.17.1 draft-ietf-csi-dhcpv6-cga-ps-09.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 12, 2012) is 4428 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 March 12, 2012 7 Analysis of Possible DHCPv6 and CGA Interactions 9 draft-ietf-csi-dhcpv6-cga-ps-09.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on September 16, 2012. 28 Copyright Notice 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with 38 respect to this document. Code Components extracted from this 39 document must include Simplified BSD License text as described in 40 Section 4.e of the Trust Legal Provisions and are provided without 41 warranty as described in the Simplified BSD License. 43 Abstract 45 This document analyzes the possible interactions between DHCPv6 and 46 Cryptographically Generated Addresses (CGAs), and gives 47 recommendations on whether or not these interactions should be 48 developed as solutions. 50 Table of Contents 52 1. Introduction ................................................ 3 53 2. Coexistence of DHCPv6 and CGA ............................... 3 54 3. Configuring CGA-relevant parameters using DHCPv6 ............ 4 55 4. Using CGA to Protect DHCPv6 ................................. 5 56 5. Computation Delegation of CGA generation .................... 6 57 6. Conclusion .................................................. 7 58 7. Security Considerations ..................................... 8 59 8. IANA Considerations ......................................... 8 60 9. Acknowledgements ............................................ 9 61 10. Diff from last IESG review (2010-10) [RFC Editor please remove] 62 ....................................................... 9 63 11. References ................................................ 10 64 11.1. Normative References ................................. 10 65 Author's Addresses ............................................ 11 67 1. Introduction 69 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 70 can assign addresses statefully. Although there are other ways to 71 assign IPv6 addresses [RFC4862, RFC5739], DHCPv6 is also used when 72 network administrators require more control over address assignments 73 or management to hosts. DHCPv6 can also be used to distribute other 74 network configuration information from network to hosts. 76 Cryptographically Generated Addresses (CGAs) [RFC3972] are IPv6 77 addresses for which the interface identifiers are generated by 78 computing a cryptographic one-way hash function from a public key 79 and auxiliary parameters. Associated with public & private key pairs, 80 CGAs are used in protocols, such as SEND [RFC3971] or SHIM6 81 [RFC5533], to provide address validation and integrity protection in 82 message exchanging. 84 As an informational document, this document analyzes the possible 85 interactions between DHCPv6 and Cryptographically Generated 86 Addresses (CGAs), and gives recommendations and reasons whether 87 these possibilities should be developed as solutions or be declined 88 in the future. This document itself does NOT define any concrete 89 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 95 for 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. 132 This 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 138 the 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 151 several 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 161 Advertisement messages of neighbor discovery protocol. DHCPv6 may 162 provide another mechanism to propagate the prefix information to 163 the host. This may enable the CGA usage scenarios without ND 164 attendance. 166 - a 3-bit security parameter Sec. It is possible that networks 167 request hosts to use CGAs with high Sec value for secure access. 168 However, it is dangerous to allow network to enforce hosts to 169 generate new CGAs with high Sec value, particularly the 170 generation with high Sec value is extremely computational 171 consumption, as analyzed in Section 5. A reasonable compromise 172 could be the network gives suggested information for Sec value, 173 only when the access requests from host are declined for low Sec 174 value. 176 - a Modifier. This is generated during the CGA generation 177 procedure. Therefore, a mechanism to configure/suggest a value is 178 not analyzed. 180 - a Collision Count value. This is generated during the CGA 181 generation procedure. Therefore, a mechanism to configure/suggest 182 a value is not analyzed. 184 - any Extension Fields that could be used. So far, there is no 185 concrete use case for this parameter. If new Extension Fields are 186 defined in the future, whether they are suitable to network- 187 managed configuration should be carefully analyzed based on the 188 specific case. 190 4. Using CGA to Protect DHCPv6 192 DHCPv6 is vulnerable to various attacks, e.g. fake address attacks 193 where a "rogue" DHCPv6 server responds with incorrect address 194 information. A malicious rogue DHCPv6 server can also provide 195 incorrect configuration to the client in order to divert the client 196 to communicate with malicious services, like DNS or NTP. It may also 197 mount a Denial of Service attack through mis-configuration of the 198 client that causes all network communication from the client to fail. 199 A rogue DHCPv6 server may also collect some critical information 200 from the client. Attackers may be able to gain unauthorized access 201 to some resources, such as network access. See Section 23 [RFC3315]. 203 In the basic DHCPv6 specifications, regular IPv6 addresses are used. 204 However, DHCPv6 servers, relay agents and clients could use host- 205 based CGAs as their own addresses. A DHCPv6 message (from either a 206 server, a relay agent or a client) with a CGA as source address can 207 carry the CGA Parameters data structure and a digital signature. The 208 receiver can verify both the CGA and signature, then process the 209 payload of the DHCPv6 message only if the validation is successful. 210 A CGA option with an address ownership proof mechanism and a 211 signature option with a corresponding verification mechanism would 212 allow the receiver of a DHCPv6 message can verify the sender address 213 of the DHCPv6 message, which improves communication security of 214 DHCPv6 messages. CGAs can be used for all DHCPv6 messages/processes 215 as long as CGAs are available on the sender side. 217 Using CGAs in DHCPv6 protocol can efficiently improve the security 218 of DHCPv6. The address ownership of a DHCPv6 message sender (which 219 can be a DHCPv6 server, a reply agent or a client) can be verified 220 by a receiver. Also, the integrity of the sent data is provided if 221 they are signed with the private key associated to the public key 222 used to generate the CGA. It improves the communication security of 223 DHCPv6 interactions. The usage of CGAs combining with signature 224 verification can also avoid DHCPv6's dependence on IPsec [RFC3315] 225 in relay scenarios. This mechanism is applicable in environments 226 where physical security on the link is not assured (such as over 227 certain wireless infrastructures) or where available security 228 mechanisms are not sufficient, and attacks on DHCPv6 are a concern. 230 The usage of CGAs can prove the source address ownership and provide 231 data integrity protection. Furthermore, CGAs of DHCPv6 servers may 232 be pre-notified to hosts. Then, hosts can decline the DHCPv6 233 messages from other servers. But in this case the address will be 234 fixed. It may increase the vulnerability to, e.g., brute force 235 attacks against. The pre-notification operation also needs to be 236 protected, which is out of scope. 238 5. Computation Delegation of CGA generation 240 As analyzed in this section, CGA generation may be computationally 241 intensive when Sec value is set to be high. However, DHCPv6 servers 242 are normally not computationally powerful enough to also generate 243 CGAs for all of its hosts.. Particularly, a DHCPv6 server is 244 architecturally designed to serve thousands hosts simultaneously. 246 In the CGA generation procedure, the generation of the Modifier 247 field of a CGA address is computationally intensive. This operation 248 can lead to apparent slow performance and/or battery consumption 249 problems for end hosts with limited computing ability and/or 250 restricted battery power (e.g. mobile devices). As defined in 251 [RFC3972], the modifier is a 128 unsigned integer that is selected 252 so that the 16*SEC leftmost bits of the second hash value, Hash2, 253 are zero. The modifier is used during CGA generation to implement 254 the hash extension and to enhance privacy by adding randomness to 255 the CGA. The higher the number of bits required being 0, the more 256 secure a CGA is against brute-force attacks. However, high number of 257 bits also results in additional computational cost for the 258 generation process, cost that could be deemed excessive. As an 259 example, consider a Sec value equals 2, requesting the leftmost 32 260 bits of a SHA-1 Hash2 to be zero. For assuring this, a system has to 261 generate in mean 2^32 different modifiers, and perform the Hash2 262 operation to check the bits required to be 0. An estimation of the 263 CPU power required to do this can be obtained as following: openSSL 264 can perform in an Intel Core2-6300 on an Asus p5b-w motherboard 265 close to 0.87 million of SHA-1 operations on 16 byte blocks per 266 second. Since the input data of Hash2 operation is larger than 16 267 bytes, this value is an upper bound for the number of hash 268 operations that can be performed for generating the modifier. 269 Checking 2^32 different modifiers requires around 5000 seconds. A 270 practice experimental on a platform with an Intel Duo2 (2.53GHz) 271 workstation showed the results of average CGA generating time as 272 below: when SEC=0, it took 100us; SEC=1, 60ms; SEC=2, 2000s (varies 273 from 100~7000sec). The experiment was unable to be performed for 274 SEC=3 or higher SEC values. Theoretically 275 estimating, about 30000 hours are required to generate a SEC=3 CGA. 277 Generating a key pair, which will be used to generate a CGA, also 278 requires a notable computation, though this may only be issues on a 279 very low-power host occasionally. 281 A very low-power host might want to delegate its key and hash 282 generation to a more general purpose computer. In such cases, a 283 mechanism to delegate the computation of the modifier would be 284 desirable. This would be especially useful for large SEC values. 286 However, DHCPv6 servers are not suitable to serve such computational 287 delegation requests from thousands clients. Correspondently, the 288 security analysis of CGA generation delegation and key generation 289 delegation are out of scope. 291 6. Conclusion 293 This document analyzed the possible interactions between CGA and 294 DHCPv6. The analysis has determined that a few interactions are not 295 worth pursuing including: enforcing CGA Sec value, using DHCPv6 to 296 manage CGAs, using DHCPv6 to assign certificates or centrally 297 generated key pair, using DHCPv6 for delegating CGA generation or 298 key generation, etc. 300 This document suggests a few possible interactions be investigated: 302 - allowing DHCPv6 servers to decline requested-CGAs and reply 303 with Prefix or Sec values to generate an appropriate CGAs, 305 - using CGA addresses for interactions between DHCPv6 306 servers/relays and clients 308 7. Security Considerations 310 Allowing DHCPv6 servers to decline the requested-CGA and reply with 311 information to generate an appropriate CGA might actually increase 312 network access flexibility. This might also benefit the network 313 security too. 315 Prefix is information that can be advertised. However, if DHCPv6 316 propagates the prefix to hosts, then attackers have another way to 317 propagate bogus prefixes. This can waste hosts' resources. DHCPv6 318 snooping, DHCPv6 authentication and DHCPv6 server using CGAs can 319 help to prevent or discover bogus prefixes. 321 When propagating the Sec value from the DHCPv6 server to host, it is 322 only returned if the DHCPv6 declines the requested-CGA. For security 323 reasons, networks should not enforce any CGA parameters. Enforcing 324 CGA parameters could allow malicious attackers to attack hosts by 325 forcing them to perform computationally intensive operations. 326 Networks can suggest the Sec value, but hosts need not heed the 327 suggestion. However, if the hosts do not follow the suggestion, then 328 the network might deny network services, including access services. 330 Using CGA as source addresses of DHCPv6 servers, relays or, also in 331 DHCPv6 message exchanging provides the source address ownership 332 verification and data integrity protection. 334 IF a DHCPv6 server rejected a client CGA based on a certain Sec 335 value, it should not suggest a new Sec value either equal or lower 336 than that rejected Sec value. 338 Without other pre-configured security mechanism, like pre-notified 339 DHCPv6 server address, using host-based CGA by DHCPv6 servers could 340 not prevent attacks claiming to be a DHCPv6 server. Alternatively, 341 IPsec may be used, but it is a heavier security mechanism. 343 8. IANA Considerations 345 There are no IANA considerations in this document. 347 9. Acknowledgements 349 Useful comments were made by Marcelo Bagnulo, Alberto Garcia, Ted 350 Lemon, Stephen Hanna, Russ Housley, Sean Turner, Tim Polk, David 351 Harrington, Jari Arkko, Tim Chown, Pete Resnick and other members of 352 the IETF CSI working group. 354 10. Diff from last IESG review (2010-10) [RFC Editor please remove] 356 Added CGA-DHCP co-existing scenarios, as the second paragraph in 357 Section 2. 359 Added the need for a DHCPv6 address registration operation in 360 Section 2. 362 Rewrite the CGA parameters configuration section. Analyze the 363 requirements per CGA parameters. 365 Added statement that network should not enforce the CGA parameters, 366 but may suggest. 368 Removed misleading words that linked CGA with PKI. 370 Removed misleading words central managed CGA. 372 Removed the combination of CGA and an external 373 authentication/authorization, since it is conflict with primary CGA 374 concept. 376 Removed the possible operations that DHCPv6 server may assign 377 certificates or centrally generated key pair. 379 Added statement that CGA generation delegation is not suitable for 380 DHCPv6 servers. 382 Added a conclusion section so that the message from this document is 383 clearly summarized. 385 Rewrite the security consideration section. Only focus on proposed 386 operations. 388 11. References 390 11.1. Normative References 392 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 393 M. Carney, "Dynamic Host Configure Protocol for IPv6", RFC 394 3315, July 2003. 396 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 397 Neighbor Discovery (SEND)", RFC 3971, March 2005. 399 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC 3972, 400 March 2005. 402 [RFC4862] S. Thomson and T. Narten, "IPv6 Stateless Address 403 Autoconfiguration", RFC 4862, September 2007. 405 [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route 406 Optimization for Mobile IPv6", RFC 4866, May 2007. 408 [RFC5533] M. Bagnulo and E. Nordmark, "Shim6: Level 3 Multihoming 409 Shim Protocol for IPv6", RFC 5533, June 2009. 411 [RFC5739] P. Eronen, J. Laganier, C. Madson, "IPv6 Configuration in 412 Internet Key Exchange Protocol Version 2 (IKEv2)", 413 RFC 5739, February 2010. 415 Author's Addresses 417 Sheng Jiang 418 Huawei Technologies Co., Ltd 419 Q14, Huawei Campus 420 No.156 Beiqing Road 421 Hai-Dian District, Beijing 100095 422 P.R. China 423 Phone: 86-10-82882681 424 Email: jiangsheng@huawei.com 426 Sean Shen 427 CNNIC 428 4, South 4th Street, Zhongguancun 429 Beijing 100190 430 P.R. China 431 Email: shenshuo@cnnic.cn