idnits 2.17.1 draft-li-dhc-secure-dhcpv6-deployment-01.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 (October 19, 2015) is 3111 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 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-privacy-01 == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-08 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: April 21, 2016 Tsinghua University 6 October 19, 2015 8 Opportunistic Security for DHCPv6 9 draft-li-dhc-secure-dhcpv6-deployment-01 11 Abstract 13 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables 14 DHCPv6 servers to configure network parameters. To secure DHCPv6, 15 the authentication and encryption mechanisms are proposed to protect 16 the DHCPv6 privacy information. However, how to deploy the secure 17 DHCPv6 mechanisms for DHCPv6 is not specified. This draft analyses 18 the DHCPv6 threat model and recommend the opportunistic security 19 mechanism for DHCPv6 deployment. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. DHCPv6 threat model . . . . . . . . . . . . . . . . . . . . . 2 57 3. Secure DHCPv6 mechanisms deployment . . . . . . . . . . . . . 3 58 3.1. Secure DHCPv6 Mechanism Deployment Difficulties . . . . . 3 59 3.2. Opportunistic security for DHCP . . . . . . . . . . . . . 3 60 3.3. DHCPv6 authentication deployment . . . . . . . . . . . . 4 61 3.3.1. TOFU for DHCPv6 authentication deployment . . . . . . 4 62 3.3.2. PKI for DHCPv6 authentication deployment . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 5.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The Dynamic Host Configuration Protocol for IPv6 [RFC3315] enables 72 DHCPv6 servers to configure network parameters dynamically. Due to 73 the unsecured nature of DHCPv6, the various critical identifiers in 74 DHCPv6 are vulnerable to several types of attacks, such as pervasive 75 monitoring and spoofing attack. Currently, there have been some 76 proposed mechanisms to secure DHCPv6. Secure DHCPv6 77 [I-D.ietf-dhc-sedhcpv6] provides the authentication mechanism between 78 DHCPv6 client and server along with the DHCPv6 transaction. 79 [I-D.cui-dhc-dhcpv6-encryption] proposes the DHCPv6 encryption 80 mechanism between the DHCPv6 client and server. However, how to 81 deploy the proposed secure DHCPv6 mechanisms is still not specified. 83 This document analyses the DHCPv6 threat model and recommends the 84 opportunistic security mechanism for secure DHCPv6 mechanisms 85 deployment to support the incremental deployment. For the DHCPv6 86 authentication deployment, we analysis two deployment schemes: TOFU 87 and PKI, which are suitable for different DHCPv6 security 88 requirements. 90 2. DHCPv6 threat model 92 Most of the privacy considerations for DHCPv6 focus on the client 93 privacy protection. As the public service infrastructure, the 94 privacy protection of DHCPv6 server and relay agent is less 95 important. DHCPv6 privacy consideration 96 [I-D.ietf-dhc-dhcpv6-privacy] analyses the privacy problem for DHCPv6 97 client, listing the various DHCPv6 options containing the privacy 98 information and the possible attack to the DHCPv6 client. The attack 99 specific to a DHCPv6 client is the possibility of the "rogue" server, 100 which may provide the incorrect information to the client. In 101 addition, the client is also faced up with the pervasive monitoring 102 attack. Pervasive monitoring may gleans the privacy information 103 about the IPv6 host, which is used to find location information, 104 previously visited networks and so on. [RFC7258] claims that 105 pervasive monitoring should be mitigated in the design of IETF 106 protocols, where possible. 108 The attack specific to a DHCPv6 server is the possibility of the 109 invalid client masquerading as a valid client, which may cause the 110 consuming to address resources configured on a DHCPv6 server. 112 3. Secure DHCPv6 mechanisms deployment 114 3.1. Secure DHCPv6 Mechanism Deployment Difficulties 116 Because of the DHCPv6 property, secure DHCPv6 mechanisms deployment 117 has some specific difficulties. For the secure DHCPv6 mechanisms 118 deployment, the DHCPv6 server is always assumed to have connectivity 119 to authorized CA and verifies the client's certificate. The 120 difficulty for the deployment is that the client is difficult to 121 verify the server's identity without access to network. When the 122 client is pre-configured with the server authentication information, 123 such as one or multiple CA certificates that form the certification 124 path, the server's identity is verified through the pre-configured 125 server authentication information. When the client is not pre- 126 configured with the server authentication information, the client has 127 no capability to verify the server's identity. In the scenario where 128 the DHCPv6 client is mobile and connects to random networks, the 129 client cannot always get pre-configured with the authentication 130 information. 132 3.2. Opportunistic security for DHCP 134 There have been some proposed secure DHCPv6 mechanisms. Secure 135 DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication mechanism 136 between DHCPv6 client and server along with the DHCPv6 transaction. 137 [I-D.cui-dhc-dhcpv6-encryption] proposes the DHCPv6 encryption 138 mechanism between the DHCPv6 client and server. The use of secure 139 DHCPv6 protects DHCPv6 from active attack, such as spoofing attack. 140 The use of DHCPv6 encryption defends DHCPv6 against pervasive 141 monitoring and other passive attacks. 143 In order to achieve the maximum protection that is available, we 144 recommend the opportunistic security for DHCPv6. Opportunistic 145 security for DHCPv6 use encryption even when authentication is not 146 available. Based on the DHCPv6 security requirement and the client 147 capability, the incremental deployment is supported. When the client 148 is pre-configured the server configuration information, it has the 149 capability to authenticate the server. When the client has 150 capability to authenticate the server, the client is secure enabled. 151 The communication is authenticated and encrypted, which protects the 152 DHCPv6 transaction from passive and active attacks. When the client 153 has no capability to authenticate the server, but is informed of the 154 server's public key, the client is encrypted enabled. The 155 communication is then not authenticated but encrypted, which protects 156 the DHCPv6 transaction from passive attacks, such as pervasive 157 monitoring attack. If the client has no capability to authenticate 158 the server and does not know the server's public key, clear text is 159 used as the baseline communication security policy. 161 In the scenario where the tight security policy is required, such as 162 the enterprise networks, the authentication and encryption are both 163 required. Opportunistic security can coexist with the explicit and 164 never preempt the explicit security policies. For example, the 165 enterprise's explicit policy is that authenticated and encrypted 166 communication is required, which covers the default opportunistic 167 security policy. 169 In the scenario where the security policy is loss, the DHCPv6 server 170 is not pre-configured with the authentication information, such as 171 the trusted CA certificates. So the server authentication is 172 optional in order to not impede the following DHCPv6 communication. 173 After the public keys exchange, the non-authenticated encryption 174 communication is applied to avoid the passive attack. In this way, 175 the DHCPv6 message content is protected from the pervasive 176 monitoring. 178 3.3. DHCPv6 authentication deployment 180 According to the different DHCPv6 security requirement and client 181 pre-configured information, different schemes for DHCPv6 182 authentication deployment is used. we analysis two deployment 183 schemes: TOFU and PKI, which are suitable for different DHCPv6 184 security requirements. 186 3.3.1. TOFU for DHCPv6 authentication deployment 188 TOFU plays a role in the scenario where the DHCPv6 client is mobile 189 and connects to random networks. In such scenario, the secure policy 190 is loss and the DHCPv6 client is not previously establish the trusted 191 relationship between the DHCPv6 server and client. The TOFU model 192 assumes that an authenticated public key obtained on first contact is 193 good enough to secure future communication. In addition, for the 194 subsequent connections, if the received public key conflicts to the 195 cached key, the user may change the current cached kay without any 196 validation. 198 TOFU-based authentication has a clear improvement over completely 199 insecure protocols, and it is also low-cost and simple to deploy. 200 However, TOFU-based authentication make it difficult to distinguish 201 rouge DHCPv6 servers by accepting any key on the initial connection. 202 And it also has no protection against MitM (Man in the Middle) 203 attacks without the validation of the conflicted public key. 205 3.3.2. PKI for DHCPv6 authentication deployment 207 In the scenario where the tight security policy is required and the 208 client are stable terminal devices, the PKI model plays a role to 209 verify the certificate and perform the authentication. The client 210 validates the server's certificate locally according to the rule 211 defined in [RFC5280] through the pre-configured information. The 212 client is pre-configured with the trusted relationship between the 213 DHCPv6 client and server, or one or multiple CA certificates, which 214 form the certificate path. 216 The PKI model achieves the authentication of the certificate all the 217 time, which improves the security performance. However, without the 218 pre-configured information, the DHCPv6 communication will fail. And 219 it also brings the deployment difficulties. 221 4. Security Considerations 223 TBD 225 5. References 227 5.1. Normative References 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.cui-dhc-dhcpv6-encryption] 247 Cui, Y., Li, L., Wu, J., and Y. Lee, "Encryption Mechanism 248 for DHCPv6", draft-cui-dhc-dhcpv6-encryption-04 (work in 249 progress), October 2015. 251 [I-D.ietf-dhc-dhcpv6-privacy] 252 Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 253 considerations for DHCPv6", draft-ietf-dhc- 254 dhcpv6-privacy-01 (work in progress), August 2015. 256 [I-D.ietf-dhc-sedhcpv6] 257 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 258 DHCPv6", draft-ietf-dhc-sedhcpv6-08 (work in progress), 259 June 2015. 261 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 262 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 263 2014, . 265 Authors' Addresses 267 Lishan Li 268 Tsinghua University 269 Beijing 100084 270 P.R.China 272 Phone: +86-15201441862 273 Email: lilishan9248@126.com 275 Yong Cui 276 Tsinghua University 277 Beijing 100084 278 P.R.China 280 Phone: +86-10-6260-3059 281 Email: yong@csnet1.cs.tsinghua.edu.cn 282 Jianping Wu 283 Tsinghua University 284 Beijing 100084 285 P.R.China 287 Phone: +86-10-6278-5983 288 Email: jianping@cernet.edu.cn