idnits 2.17.1 draft-ietf-csi-dhcpv6-cga-ps-03.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 (June 23, 2010) is 5056 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: January 03, 2011 CNNIC 5 Tim Chown 6 University of Southampton 7 June 23, 2010 9 DHCPv6 and CGA Interaction: Problem Statement 11 draft-ietf-csi-dhcpv6-cga-ps-03.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 January 03, 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...................................5 62 5. Security Considerations......................................6 63 6. IANA Considerations.........................................7 64 7. Solution Requests...........................................7 65 8. Acknowledgements............................................7 66 9. Change Log [RFC Editor please remove]........................7 67 10. References.................................................8 68 10.1. Normative References...................................8 69 Author's Addresses.............................................9 71 1. Introduction 73 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 74 can assign addresses statefully. Although there are other ways to 75 assign IPv6 addresses [RFC4862, RFC5739], DHCPv6 is still useful when 76 an administrator requires more control over address assignments to 77 hosts. DHCPv6 can also be used to distribute other network 78 configuration information. 80 Cryptographically Generated Addresses (CGAs) [RFC3972] are IPv6 81 addresses for which the interface identifiers are generated by 82 computing a cryptographic one-way hash function from a public key and 83 auxiliary parameters. Associated with public & private key pairs, 84 CGAs are used in protocols, such as SEND [RFC3971] or SHIM6 85 [RFC5533], to provide address validation and integrity protection in 86 message exchanging. 88 This document describes potential issues in the interaction between 89 DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the 90 scenario of using CGAs in DHCPv6 environments is discussed. Some 91 operations are clarified for the interaction of DHCPv6 servers and 92 CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may 93 have mutual benefits for each other, including using CGAs in DHCPv6 94 operations to enhance its security features and using DHCPv6 to 95 provide the CGA generation function. This document is designed to 96 generate further discussion on the specifics of if/how the ideas in 97 the document could be realized. 99 2. Coexistence of DHCPv6 and CGA 101 CGAs can be used with IPv6 Stateless Address Configuration [RFC4862]. 102 The public key system associated with the CGA address provides 103 message origin validation and integrity protection without the need 104 for negotiation and transportation of key materials. 106 The current CGA specifications do not mandate which device generates 107 a CGA address. In many cases, a CGA address is generated by the 108 associated key pair owner, which normally is also the host that will 109 use the CGA address. However, in a DHCPv6-managed network, hosts 110 should use IPv6 global addresses only from a DHCPv6 server. This 111 difference of roles needs to be carefully considered if there is a 112 requirement to use CGAs in DHCPv6-managed environments. 114 The current DHCPv6 specification [RFC3315] has a mechanism that could 115 be used to allow a host to self-generate a CGA for use in a DHCPv6- 116 managed environment, i.e. the DHCPv6 server can grant the use of 117 host-generated CGA addresses on request from the client. 119 Specifically, a node can request that a DHCPv6 server grants the use 120 of a self-generated CGA by sending a DHCPv6 Request message. This 121 DHCPv6 Request message contains an IA option including the CGA 122 address. Depending on whether the CGA satisfies the CGA-related 123 configuration parameters of the network, the DHCPv6 server can then 124 send an acknowledgement to the node to either grant the use of the 125 CGA or to indicate that the node must generate a new CGA with the 126 correct CGA-related configuration parameters of the network. In the 127 meantime the DHCPv6 server may log the requested address/host 128 combination. 130 3. What DHCPv6 can do for CGA 132 In the current CGA specifications there is a lack of procedures to 133 enable central management of CGA generation. Administrators should be 134 able to configure parameters used to generate CGAs. DHCPv6 could be 135 used to assign subnet prefixes or certificates to CGA address owners. 136 In some scenarios, the administrator may further want to enforce some 137 parameters, in particular the necessary security-related parameters 138 such as the SEC value. 140 In the CGA generation procedure, the generation of the Modifier field 141 of a CGA address is computationally intensive. This operation can 142 lead to apparent slow performance and/or battery consumption problems 143 for end hosts with limited computing ability and/or restricted 144 battery power (e.g. mobile devices). In such cases, a mechanism to 145 delegate the computation of the modifier would be desirable. It is 146 possible that the whole CGA generation procedure could be delegated 147 to the DHCPv6 server. This would be especially useful for large SEC 148 values. 150 Generating a key pair, which will be used to generate a CGA, also 151 requires a notable computation. Generation and distribution of a key 152 pair can also be done by a DHCPv6 server. Of course, when designing 153 these new functions, one should carefully consider the impact on 154 security. However, the security considerations of specific solutions 155 are out of scope of this document. 157 New DHCPv6 options could be defined to carry management parameters 158 from a DHCPv6 server to the client that wishes to use a CGA. A new 159 DHCPv6 prefix assignment option could be defined to propagate a 160 subnet prefix. More DHCPv6 options may be defined to propagate 161 additional CGA-relevant configuration information, such as the SEC 162 value, certificate information, SEND proxy information, etc. 164 It may be possible to define a delegation operation that allows a 165 client to pass computations to a DHCPv6 server, by introducing new 166 DHCPv6 option(s). A node could thus initiate a DHCPv6 request to the 167 DHCPv6 server requesting the computation of the Modifier or the CGA. 168 The DHCPv6 server could then either compute the Modifier by itself, 169 or redirect the computation requirement to another server. Once the 170 DHCPv6 server generates (or obtains from the redirected computational 171 server) the Modifier or the CGA address, it can respond to the node 172 with the Modifier or the resulting address and the corresponding CGA 173 Parameters data structure. 175 Depending on the scenario, the configuration information needed to 176 generate CGAs (including a SEC value, a subnet prefix, a modifier, a 177 public key, a Collision Count value and any Extension Fields) may be 178 provided by either hosts or DHCPv6 servers. A DHCPv6 server might 179 receive from hosts the configuration information customized by hosts, 180 generate CGAs by using configuration information provided by both 181 parties and deliver CGAs and their associated CGA Parameters data 182 structures to hosts. The details of such potential new methods need 183 to be defined clearly in the solution specifications. 185 New DHCPv6 options may be defined to support the interactions that 186 are required when a DHCPv6 server generates a key pair for hosts. 188 When designing such solutions, the designer should thoroughly 189 consider the impact on DHCPv6 model and the security of CGA usage. In 190 order to be compatible with DHCPv6, the configuring procedure of CGA 191 parameters should be compatible with the current DHCPv6 definition. 192 When a DHCP6 server configures CGA parameters, integrity protection 193 may be needed to avoid attacks, such as downgrade attack. 195 4. What CGA can do for DHCPv6 197 DHCPv6 is vulnerable to various attacks, e.g. fake address attacks 198 where a 'rogue' DHCPv6 server responds with incorrect address 199 information. A malicious rogue DHCPv6 server can also provide 200 incorrect configuration to the client in order to divert the client 201 to communicate with malicious services, like DNS or NTP. It may also 202 mount a Denial of Service attack through mis-configuration of the 203 client that causes all network communication from the client to fail. 204 A rogue DHCPv6 server may also collect some critical information from 205 the client. Attackers may be able to gain unauthorized access to some 206 resources, such as network access. See Section 23 [RFC3315]. 208 In the basic DHCPv6 specifications, regular IPv6 addresses are used. 209 However, DHCPv6 servers, relay agents and clients could use CGAs as 210 their own addresses. A DHCPv6 message (from either a server, relay 211 agent or client) with a CGA as source address can carry the CGA 212 Parameters data structure and a digital signature. The receiver can 213 verify both the CGA and signature, then process the payload of the 214 DHCPv6 message only if the validation is successful. A CGA option 215 with an address ownership proof mechanism and a signature option with 216 a corresponding verification mechanism may be introduced into DHCPv6 217 protocol. With these two new options, the receiver of a DHCPv6 218 message can verify the sender address of the DHCPv6 message, which 219 improves communication security of DHCPv6 messages. CGAs can be used 220 for all DHCPv6 messages/processes as long as CGAs are available on 221 the sender side. 223 Using CGAs in DHCPv6 protocol can efficiently improve the security of 224 DHCPv6. The address of a DHCPv6 message sender (which can be a DHCPv6 225 server, a reply agent or a client) can be verified by a receiver. 226 Also, the integrity of the sent data is provided if they are signed 227 with the private key associated to the public key used to generate 228 the CGA. The usage of CGA with pre-configured authorization, as 229 introduced in next paragraph, can efficiently avoid the 230 abovementioned attacks. It improves the communication security of 231 DHCPv6 interactions. The usage of CGAs can also avoid DHCPv6's 232 dependence on IPsec [RFC3315] in relay scenarios. This mechanism is 233 applicable in environments where physical security on the link is not 234 assured (such as over certain wireless infrastructures) or where 235 available security mechanisms are not sufficient, and attacks on 236 DHCPv6 are a concern. 238 A CGA generated from an unauthorized public & private key pair can 239 prove the source address ownership and provide data integrity 240 protection. Furthermore, a CGA generated from a certificated public & 241 private key pair can also achieve authorization for DHCPv6 servers or 242 relays, or on another direction, user authorization. The public keys 243 may be pre-configured on both parties of communication or have a 244 third party authority available for users to retrieve public keys. 245 The public keys will be used for users to generate CGAs and verify 246 CGAs and signatures. The pre-configuration can also include 247 configuring more CGA parameters such as SEC value or more depend on 248 policies. The pre-configuration can even be the whole CGA and related 249 parameters, but in this case the address will be fixed. It may 250 increase the vulnerability to, e.g., brute force attacks. 252 5. Security Considerations 254 As Section 4 of this document has discussed, CGAs can provide 255 additional security features for DHCPv6. However, in defining 256 solutions using DHCPv6 to configure CGAs, as suggested in Section 3 257 of this document, careful consideration is required to evaluate 258 whether the new mechanism introduces new security vulnerabilities. 260 When DHCPv6 is used to manage CGAs, CGA relevant information is 261 stored in a central repository, DHCPv6 server. It does not increase 262 privacy risks. The CGA relevant information is only exposed to the 263 network management plane. The privacy risks are not higher than other 264 network managed entities, like normal IPv6 addresses managed by DHCP, 265 or addresses logged by ACL. 267 6. IANA Considerations 269 There are no IANA considerations in this document. 271 7. Solution Requests 273 As discussed in this document, CGAs and DHCPv6 can provide additional 274 services or security features for each other. Solutions that define 275 the details of such interactions should be investigated to determine 276 how viable they are. 278 8. Acknowledgements 280 Useful comments were made by Marcelo Bagnulo and Alberto Garcia, 281 UC3M, Spain and other members of the IETF CSI working group. 283 9. Change Log [RFC Editor please remove] 285 draft-jiang-csi-dhacpv6-cga-ps-00, original version, 2008-10-27 287 draft-jiang-csi-dhacpv6-cga-ps-01, revised after comments at IETF 73, 288 2009-01-08 290 draft-jiang-csi-dhacpv6-cga-ps-02, revised after comments at CSI 291 mailing list, 2009-06-17 293 draft-jiang-csi-dhacpv6-cga-ps-03, revised after comments at CSI 294 mailing list, 2009-09-18 296 draft-ietf-csi-dhacpv6-cga-ps-00, revised after comments at CSI 297 mailing list and wg adoption call, 2009-10-12 299 draft-ietf-csi-dhacpv6-cga-ps-01, revised after comments at IETF 76, 300 2009-12-16 302 draft-ietf-csi-dhacpv6-cga-ps-02, revised after comments received in 303 CSI mail list, 2010-04-23 304 draft-ietf-csi-dhacpv6-cga-ps-03, revised after comments received in 305 CSI mail list, 2010-06-22 307 10. References 309 10.1. Normative References 311 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 312 M. Carney, "Dynamic Host Configure Protocol for IPv6", RFC 313 3315, July 2003. 315 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 316 Neighbor Discovery (SEND)", RFC 3971, March 2005. 318 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC 3972, 319 March 2005. 321 [RFC4862] S. Thomson and T. Narten, "IPv6 Stateless Address 322 Autoconfiguration", RFC 4862, September 2007. 324 [RFC5533] M. Bagnulo and E. Nordmark, "Shim6: Level 3 Multihoming 325 Shim Protocol for IPv6", RFC 5533, June 2009. 327 [RFC5739] P. Eronen, J. Laganier, C. Madson, "IPv6 Configuration in 328 Internet Key Exchange Protocol Version 2 (IKEv2)", 329 RFC 5739, February 2010. 331 Author's Addresses 333 Sheng Jiang 334 Huawei Technologies Co., Ltd 335 KuiKe Building, No.9 Xinxi Rd., 336 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 337 P.R. China 338 Phone: 86-10-82836081 339 Email: shengjiang@huawei.com 341 Sean Shen 342 CNNIC 343 4, South 4th Street, Zhongguancun 344 Beijing 100190 345 P.R. China 346 Email: shenshuo@cnnic.cn 348 Tim Chown 349 University of Southampton 350 Highfield 351 Southampton, Hampshire SO17 1BJ 352 United Kingdom 353 Email: tjc@ecs.soton.ac.uk