idnits 2.17.1 draft-jiang-csi-dhcpv6-cga-ps-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 18, 2009) is 5331 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: March 16, 2010 CNNIC 5 Tim Chown 6 University of Southampton 7 September 18, 2009 9 DHCPv6 and CGA Interaction: Problem Statement 11 draft-jiang-csi-dhcpv6-cga-ps-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on March 16, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document describes potential issues in the interaction between 49 DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the 50 scenario of using CGAs in DHCPv6 environments is discussed. Some 51 operations are clarified for the interaction of DHCPv6 servers and 52 CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may 53 have mutual benefits for each other, including using CGAs in DHCPv6 54 operations to enhance its security features and using DHCPv6 to 55 provide the CGA generation function. 57 Table of Contents 59 1. Introduction.................................................3 60 2. Coexistence of DHCPv6 and CGA................................3 61 3. What DHCPv6 can do for CGA...................................4 62 4. What CGA can do for DHCPv6...................................5 63 5. Security Considerations......................................6 64 6. IANA Considerations..........................................6 65 7. Solution Requests............................................6 66 8. Acknowledgements.............................................6 67 9. Change Log...................................................6 68 10. References..................................................6 69 10.1. Normative References...................................6 70 10.2. Informative References.................................7 71 Author's Addresses..............................................8 73 1. Introduction 75 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 76 can assign addresses statefully. Although there are other ways to 77 assign IPv6 addresses [RFC4862, RFC4339], DHCPv6 is still useful when 78 an administrator requires more control over address assignments to 79 hosts. DHCPv6 can also be used to distribute other network configure 80 information. 82 Cryptographically Generated Addresses (CGAs) [RFC3972] are IPv6 83 addresses for which the interface identifiers are generated by 84 computing a cryptographic one-way hash function from a public key and 85 auxiliary parameters. By using the associated public & private keys 86 as described by SEcure Neighbor Discovery (SEND) [RFC3971], CGAs can 87 protect the Neighbor Discovery Protocol (NDP) [RFC4861], i.e. they 88 can provide address validation and integrity protection for NDP 89 messages. 91 This document describes potential issues in the interaction between 92 DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the 93 scenario of using CGAs in DHCPv6 environments is discussed. Some 94 operations are clarified for the interaction of DHCPv6 servers and 95 CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may 96 have mutual benefits for each other, including using CGAs in DHCPv6 97 operations to enhance its security features and using DHCPv6 to 98 provide the CGA generation function. 100 2. Coexistence of DHCPv6 and CGA 102 CGAs can be used with IPv6 Stateless Address Configuration [RFC4862]. 103 The public key system associated with the CGA address provides 104 message origin validation and integrity protection without the need 105 for negotiation and transportation of key materials. 107 The current CGA specifications do not mandate which device generates 108 a CGA address. In many cases, a CGA address is generated by the 109 associated key pair owner, which normally is also the host that will 110 use the CGA address. However, in a DHCPv6-managed network, hosts 111 should obtain IPv6 addresses only from a DHCPv6 server. This 112 difference of roles needs to be carefully considered if there is a 113 requirement to use CGAs in DHCPv6-managed environments. 115 The current DHCPv6 specification [RFC3315] has a mechanism that could 116 be used to allow a host to self-generate a CGA for use in a DHCPv6- 117 managed environment, i.e. the DHCPv6 server can grant the use of 118 host-generated CGA addresses on request from the client. 120 Specifically, a node can request that a DHCPv6 server grants the use 121 of a self-generated CGA by sending a DHCPv6 Request message. This 122 DHCPv6 Request message contains an IA option including the CGA 123 address. Depending on whether the CGA matches the CGA-related 124 configuration parameters of the network, the DHCPv6 server can then 125 send an acknowledgement to the node to either grant the use of the 126 CGA or to indicate that the node must generate a new CGA with the 127 correct CGA-related configuration parameters of the network. In the 128 meantime the DHCPv6 server may log the requested address/host 129 combination. 131 3. What DHCPv6 can do for CGA 133 In the current CGA specifications there is a lack of procedures to 134 enable central management of CGA generation. Administrators should be 135 able to configure parameters used to generate CGAs. DHCPv6 could be 136 used to assign subnet prefixes or certificates to CGA address owners. 137 In some scenarios, the administrator may further want to enforce some 138 parameters, in particular the necessary security-related parameters 139 such as the SEC value. 141 In the CGA generation procedure, the generation of the Modifier field 142 of a CGA address is computationally intensive. This operation can 143 lead to apparent slow performance and/or battery consumption problems 144 for end hosts with limited computing ability and/or restricted 145 battery power (e.g. mobile devices). In such cases, a mechanism to 146 delegate the computation of the modifier would be desirable. It is 147 possible that the whole CGA generation procedure could be delegated 148 to the DHCPv6 server. This would be especially useful for large SEC 149 values. 151 Generating a key pair, which will be used to generate a CGA, also 152 requires a notable computation. Generation and distribution of a key 153 pair can also be done by DHCPv6 server. Of course, when designing 154 these new functions, one should carefully consider the impact on 155 security. However, the security considerations of specific solutions 156 are out of scope of this document. 158 New DHCPv6 options could be defined to carry management parameters 159 from a DHCPv6 server to the client that wishes to use a CGA. A new 160 DHCPv6 prefix assignment option could be defined to propagate a 161 subnet prefix. More DHCPv6 options may be defined to propagate 162 additional CGA-relevant configuration information, such as the SEC 163 value, certificate information, SEND proxy information, etc. 165 It may be possible to define a delegation operation that allows a 166 client to pass computations to a DHCPv6 server, by introducing new 167 DHCPv6 option(s). A node could thus initiate a DHCPv6 request to the 168 DHCPv6 server requesting the computation of the Modifier or the CGA. 169 The DHCPv6 server could then either compute the Modifier by itself, 170 or redirect the computation requirement to another server. Once the 171 DHCPv6 server generates (or obtains from the redirected computational 172 server) the Modifier or the CGA address, it can respond to the node 173 with the Modifier or the resulting address and the corresponding CGA 174 Parameters data structure. 176 Depending on the scenario, the information needed to generate CGAs 177 (including a SEC value, a subnet prefix, a modifier, a public key, a 178 Collision Count value and any Extension Fields) may be provided by 179 either hosts or DHCPv6 servers. A DHCPv6 server might receive from 180 hosts the information customized by hosts, generate CGAs by using 181 information provided by both parties and distribute CGAs and their 182 associated CGA Parameters data structures to hosts. The details of 183 such potential new methods need to be defined clearly in the solution 184 specifications. 186 New DHCPv6 options may be defined to support the interactions that 187 are required when a DHCPv6 server generates a key pair for hosts. 189 4. What CGA can do for DHCPv6 191 DHCPv6 is vulnerable to various attacks, e.g. fake address attacks 192 where a 'rogue' DHCPv6 server responds with incorrect address 193 information. A malicious rogue DHCPv6 server can also provide 194 incorrect configuration to the client in order to divert the client 195 to communicate with malicious services, like DNS or NTP. It may also 196 mount a Denial of Service attack through mis-configuration of the 197 client that causes all network communication from the client to fail. 198 A rogue DHCPv6 server may also collect some critical information from 199 the client. Attackers may be able to gain unauthorized access to some 200 resources, such as network access. See Section 23 [RFC3315]. 202 In the basic DHCPv6 specifications, regular IPv6 addresses are used. 203 However, DHCPv6 servers, relay agents and clients could use CGAs as 204 their own addresses. A DHCPv6 message (from either a server, relay 205 agent or client) with a CGA as source address, can carry the CGA 206 Parameters data structure and a digital signature. The receiver can 207 verify both the CGA and signature, then process the payload of the 208 DHCPv6 message only if the validation is successful. In this way 209 DHCPv6 messages can be protected. This mechanism can efficiently 210 improve the security of DHCPv6, because the address of a DHCP message 211 sender (which can be a DHCP server, a reply agent or a client) can be 212 verified by a receiver. It improves the communication security of 213 DHCPv6 interactions. This mechanism is applicable in environments 214 where physical security on the link is not assured (such as over 215 certain wireless infrastructures) or where available security 216 mechanisms are not sufficient, and attacks on DHCPv6 are a concern. 218 5. Security Considerations 220 As Section 5 of this document has discussed, CGAs can provide 221 additional security features for DHCPv6. However, in defining 222 solutions using DHCPv6 to configure CGAs, as suggested in Section 4 223 of this document, careful consideration is required to evaluate 224 whether the new mechanism introduces new security vulnerabilities. 226 6. IANA Considerations 228 There are no IANA considerations in this document. 230 7. Solution Requests 232 As discussed in this document, CGAs and DHCPv6 can provide additional 233 services or security features for each other. Solutions that define 234 the details of such interactions should be investigated to determine 235 how viable they are. 237 8. Acknowledgements 239 Useful comments were made by Marcelo Bagnulo, UC3M, Spain and other 240 members of the IETF CSI working group. 242 9. Change Log [RFC Editor please remove] 244 draft-jiang-csi-dhacpv6-cga-ps-00, original version, 2008-10-27 246 draft-jiang-csi-dhacpv6-cga-ps-01, revised after comments at IETF 73, 247 2009-01-08 249 draft-jiang-csi-dhacpv6-cga-ps-02, revised after comments at CSI 250 mailing list, 2009-06-17 252 draft-jiang-csi-dhacpv6-cga-ps-03, revised after comments at CSI 253 mailing list, 2009-09-18 255 10. References 257 10.1. Normative References 259 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 260 IPv6", RFC 3315, July 2003. 262 [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 263 Discovery (SEND) ", RFC 3971, March 2005. 265 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC 3972, 266 March 2005. 268 [RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor 269 Discovery for IP version 6 (IPv6)", RFC 4861, September 270 2007. 272 [RFC4862] S. Thomson, T. Narten, "IPv6 Stateless Address 273 Autoconfiguration", RFC 4862, September 2007. 275 10.2. Informative References 277 [RFC4339] J. Jeong, Ed., "IPv6 Host Configuration of DNS Server 278 Information Approaches", RFC 4339, February 2006. 280 Author's Addresses 282 Sheng Jiang 283 Huawei Technologies Co., Ltd 284 KuiKe Building, No.9 Xinxi Rd., 285 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 286 P.R. China 287 Phone: 86-10-82836081 288 Email: shengjiang@huawei.com 290 Sean Shen 291 CNNIC 292 4, South 4th Street, Zhongguancun 293 Beijing 100190 294 P.R. China 295 Email: shenshuo@cnnic.cn 297 Tim Chown 298 University of Southampton 299 Highfield 300 Southampton, Hampshire SO17 1BJ 301 United Kingdom 302 Email: tjc@ecs.soton.ac.uk