idnits 2.17.00 (12 Aug 2021) /tmp/idnits29859/draft-li-dhc-secure-dhcpv6-deployment-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2016) is 2260 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7435' is defined on line 240, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-10 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-dhc-dhcpv6-privacy has been published as RFC 7824 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group L. Li 3 Internet-Draft Y. Cui 4 Intended status: Informational J. Wu 5 Expires: September 7, 2016 Tsinghua University 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 March 6, 2016 10 secure DHCPv6 deployment 11 draft-li-dhc-secure-dhcpv6-deployment-03 13 Abstract 15 Secure DHCPv6 provides authentication and encryption mechanisms for 16 DHCPv6. This draft analyses DHCPv6 threat model and provides 17 guideline for secure DHCPv6 deployment. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 7, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. DHCPv6 Threat Model . . . . . . . . . . . . . . . . . . . . . 2 55 3. Secure DHCPv6 Mechanism Deployment . . . . . . . . . . . . . 3 56 3.1. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . 3 57 3.2. Secure DHCPv6 Deployment Difficulties . . . . . . . . . . 4 58 3.3. Roaming Client with Loose Security Policy . . . . . . . . 4 59 3.4. Static Client with Strict Security Policy . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 5.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The Dynamic Host Configuration Protocol for IPv6 [RFC3315] enables 69 DHCPv6 servers to configure network parameters dynamically. Due to 70 the unsecured nature of DHCPv6, the various critical identifiers in 71 DHCPv6 are vulnerable to several types of attacks. Secure DHCPv6 72 [I-D.ietf-dhc-sedhcpv6] provides authentication and encryption 73 mechanisms for DHCPv6. 75 This document analyses DHCPv6 threat model and provides some 76 guideline for secure DHCPv6 deployment. For secure DHCPv6 77 deployment, we mainly consider two different scenarios: roaming 78 client with loose security policy and static client with strict 79 security policy. 81 2. DHCPv6 Threat Model 83 DHCPv6 privacy consideration [I-D.ietf-dhc-dhcpv6-privacy] analyses 84 the privacy problem for DHCPv6, listing the various DHCPv6 options 85 containing the privacy information and the possible attacks to 86 DHCPv6. 88 Most of the privacy considerations for DHCPv6 focus on the client 89 privacy protection. As the public service infrastructures, the 90 privacy protection of the DHCPv6 server and relay agent is less 91 important. 93 The attack specific to a DHCPv6 client is the possibility of the 94 injection attack, MitM attack, spoofing attack. Because of the above 95 attacks, the client may be configured with the incorrect 96 configuration information, such as invalid IPv6 address. In 97 addition, the client is also faced up with passive attacks, such as 98 pervasive monitoring. Pervasive monitoring may glean the privacy 99 information of the IPv6 host, which is used to find location 100 information, previously visited networks and so on. [RFC7258] claims 101 that pervasive monitoring should be mitigated in the design of IETF 102 protocols, where possible. 104 For the static clients, such as the devices in enterprise network, 105 they are always assumed to connect to exactly one network. The 106 static client can be easily pre-configured with the certificates of 107 the local DHCPv6 servers. According to the pre-configured 108 information, the static client can detect the spoofing attack. The 109 typical attack is MitM attack. An intruder connects to the network 110 and uses DHCP spoofing to install itself as a MitM. Because of the 111 MitM attack, the client's privacy information may be modified or 112 gleaned by the MitM. For the roaming clients, the typical attack is 113 spoofing attack. Because of the rogue server which masquerades as 114 valid server, the client is configured with the incorrect 115 configuration information. 117 The attack specific to a DHCPv6 server is the possibility of "denial 118 of service" (Dos) attack. Invalid clients may masquerade as valid 119 clients to request IPv6 addresses continually. The attack may cause 120 the exhaustion of valid IPv6 addresses, CPU and network bandwidth. 121 In addition, it also causes problem for the maintenance and 122 management of the large tables on the DHCPv6 servers. 124 3. Secure DHCPv6 Mechanism Deployment 126 3.1. Secure DHCPv6 Overview 128 Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication and 129 encryption mechanisms for DHCPv6. The Information-request and Reply 130 messages are exchanged to achieve DHCPv6 server authentication. Then 131 the DHCPv6 client authentication is achieved through the first 132 encrypted DHCPv6 message sent from the client to the server, which 133 contains the client's certificate information. Once the mutual 134 authentication, the subsequent DHCPv6 messages are all encrypted with 135 the recipient's public key. 137 DHCPv6 server authentication protects the DHCPv6 client from 138 injection attack, spoofing attack, and MitM attack. DHCPv6 client 139 authentication protects the DHCPv6 server from Dos attack. DHCPv6 140 encryption protects DHCPv6 from passive attack, such as pervasive 141 monitoring. 143 3.2. Secure DHCPv6 Deployment Difficulties 145 Because of DHCPv6's specific property, the deployment of Secure 146 DHCPv6 mechanism is faced with some specific difficulties. The 147 DHCPv6 server is always assumed to be pre-configured with the trusted 148 clients' certificates or the trusted CAs' certificates to verify the 149 clients' identity. The difficulty of Secure DHCPv6 deployment is 150 that it is hard for the client to verify the server's identity 151 without access to the network. According to the client's capability 152 and security requirement, different schemes for secure DHCPv6 153 deployment are applied. 155 3.3. Roaming Client with Loose Security Policy 157 In the scenario where the DHCPv6 clients are roaming and have loose 158 security requirement, opportunistic security plays a role. 159 Opportunistic security provides DHCPv6 encryption even when the 160 mutual authentication is not available. Based on the roaming 161 client's capability, the DHCPv6 configuration process is either 162 authenticated and encrypted, or non-authenticated and encrypted. 164 If the client is pre-configured with the trusted servers' 165 certificates or the trusted CAs' certificates, it has the capability 166 to achieve server authentication. If the client is pre-configured 167 with its own CA-signed certificate, it sends the CA-signed 168 certificate to the DHCPv6 server for client authentication. When the 169 client has been pre-configured with these certificate information, 170 the DHCPv6 configuration process is authenticated and encrypted, 171 which protects the DHCPv6 transaction from passive and active 172 attacks. 174 If the client is not pre-configured with these certificate 175 information, the communication is non-authenticated and encrypted. 176 Non-authenticated and encrypted communication is better than 177 cleartext, which defends against pervasive monitoring and other 178 passive attacks. Although the client is not capable of verifying the 179 server's identity, the client can obtain the server's public key 180 through the server's certificate. For the client authentication, the 181 client can send the self-signed certificate to the server if the 182 client is not configured with the CA-signed certificate. For the 183 DHCPv6 encryption, after the mutual public key communication process, 184 the DHCPv6 message is encrypted with the recipient's public key. 186 3.4. Static Client with Strict Security Policy 188 In the scenario where the DHCPv6 clients are static and have strict 189 security requirement, the PKI plays a role. Then the default 190 security policy is that DHCPv6 configuration communication must be 191 authenticated and encrypted. The static clients, such as the desktop 192 in enterprise network, are pre-configured with the trusted servers' 193 certificates or the trusted CAs' certificates which form the 194 certificate path. Through the pre-configured information, the client 195 has the capability to achieve server authentication locally according 196 to the rule defined in [RFC5280]. For client authentication, the 197 client sends the CA-signed certificate to the server for client 198 authentication. For DHCPv6 encryption, the DHCPv6 message is 199 encrypted with the recipient's public key contained in the 200 certificate. 202 In some scenarios, the roaming client may also have strict security 203 requirement, such as the byod in enterprise network. Because of the 204 strict security policy, the DHCPv6 configuration process is 205 authenticated and encrypted. Although the roaming client is not pre- 206 configured with the certificates information, the trusted server's 207 certificate and its own certificate can be obtained out of band, such 208 as by scanning a QR code. Through the obtained certificate 209 information, the DHCPv6 client and the DHCPv6 server can achieve the 210 mutual authentication. And then the subsequent DHCPv6 messages are 211 encrypted with the recipient's public key. 213 4. Security Considerations 215 Opportunistic encryption is used for secure DHCPv6 deployment in the 216 scenario where the security policy is loose. Downgrade attacks 217 cannot be avoided if nodes can accept the un-authenticated and 218 encrypted DHCPv6 configuration. 220 5. References 222 5.1. Normative References 224 [I-D.ietf-dhc-sedhcpv6] 225 Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. 226 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-10 (work 227 in progress), December 2015. 229 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 230 C., and M. Carney, "Dynamic Host Configuration Protocol 231 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 232 2003, . 234 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 235 Housley, R., and W. Polk, "Internet X.509 Public Key 236 Infrastructure Certificate and Certificate Revocation List 237 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 238 . 240 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 241 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 242 December 2014, . 244 5.2. Informative References 246 [I-D.ietf-dhc-dhcpv6-privacy] 247 Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 248 considerations for DHCPv6", draft-ietf-dhc- 249 dhcpv6-privacy-05 (work in progress), February 2016. 251 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 252 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 253 2014, . 255 Authors' Addresses 257 Lishan Li 258 Tsinghua University 259 Beijing 100084 260 P.R.China 262 Phone: +86-15201441862 263 Email: lilishan48@gmail.com 265 Yong Cui 266 Tsinghua University 267 Beijing 100084 268 P.R.China 270 Phone: +86-10-6260-3059 271 Email: yong@csnet1.cs.tsinghua.edu.cn 273 Jianping Wu 274 Tsinghua University 275 Beijing 100084 276 P.R.China 278 Phone: +86-10-6278-5983 279 Email: jianping@cernet.edu.cn 280 Sheng Jiang 281 Huawei Technologies Co., Ltd 282 Q14, Huawei Campus, No.156 Beiqing Road 283 Hai-Dian District, Beijing, 100095 284 CN 286 Email: jiangsheng@huawei.com