idnits 2.17.1 draft-reddy-add-enterprise-policy-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (2 March 2022) is 786 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7626' is defined on line 425, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-add-ddr-05 == Outdated reference: A later version (-16) exists of draft-ietf-add-dnr-05 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD T. Reddy 3 Internet-Draft Akamai 4 Intended status: Standards Track D. Wing 5 Expires: 3 September 2022 Citrix 6 K. Smith 7 Vodafone 8 2 March 2022 10 Network policy to use Network-designated DNS Resolvers 11 draft-reddy-add-enterprise-policy-01 13 Abstract 15 This document specifies a mechanism to inform endpoints about any 16 network policy mandating the use of network-designated DNS resolvers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 3 September 2022. 35 Copyright Notice 37 Copyright (c) 2022 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. PvD NetworkDNSOnly and ErrorNetworkDNSOnly Keys . . . . . . . 4 54 4. Scope of NetworkDNSOnly Key . . . . . . . . . . . . . . . . . 5 55 5. An Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 61 9.2. Informative References . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 64 1. Introduction 66 Historically, an endpoint would utilize network-designated DNS 67 servers upon joining a network (e.g., DHCP OFFER, IPv6 Router 68 Advertisement). While it has long been possible to configure 69 endpoints to ignore the network's suggestions and use a (public) DNS 70 server on the Internet, this was seldom used because some networks 71 block UDP/53 (in order to enforce their own DNS policies). Also, 72 there has been an increase in the availability of "public resolvers" 73 [RFC8499] which DNS clients may be pre-configured to use instead of 74 the default network resolver for a variety of reasons (e.g., offer a 75 good reachability, support an encrypted transport, provide a claimed 76 privacy policy, (lack of) filtering). With the advent of DoT and 77 DoH, such network blocking is more difficult. The network is unable 78 to express its policy to use network-designated resolvers to the 79 endpoints and the endpoint is unable to identify the reason why the 80 public DNS server is not reachable. 82 DNS resolvers not signaled by the network (e.g., DNS-over-TLS (DoT) 83 [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484]) will bypass enterprise- 84 specific policies, including security policies for endpoints (e.g., 85 laptops, printers, IoT devices). It is out of the scope of this memo 86 to characterize such policies nor assess whether they achieve the 87 claimed intent. 89 With the advent of DoT and DoH, the network is unable to express any 90 policy to the endpoints to explain why the network is blocking 91 alternative resolvers, and endpoints are unable to identify the 92 reason why their choice of public DNS resolver is not reachable. 93 Although network security services can be configured to block DoT 94 traffic by dropping outgoing packets to destination port number 853, 95 identifying DoH traffic is more challenging: network security 96 services may try to identify the well-known DoH resolvers by their 97 domain name and DoH traffic can be blocked by dropping outgoing 98 packets to these domains. However, DoH traffic can not be fully 99 identified without acting as a TLS proxy, with potenitally many 100 undesired consequences. 102 This results in incompatibilities with the privacy profiles discussed 103 in [RFC8310]: 105 * If an endpoint has enabled strict privacy profile (Section 5 of 106 [RFC8310]), the endpoint cannot resolve DNS names. 108 * If an endpoint has enabled opportunistic privacy profile 109 (Section 5 of [RFC8310]), the endpoint will either fallback to an 110 encrypted connection without authenticating the DNS server 111 signaled by the local network or fallback to clear text DNS, and 112 cannot exchange encrypted DNS messages. 114 The fallback adversely impacts security and privacy as internal 115 attacks are possible within Enterprise networks. For example, an 116 internal attacker can modify the DNS responses to re-direct a 117 client to malicious servers or pervasively monitor the DNS 118 traffic. 120 This document describes a mechanism for informing endpoints of 121 network policy related to network-designated DNS servers, such as 122 those DNS servers signaled using [I-D.ietf-add-dnr] and 123 [I-D.ietf-add-ddr]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119][RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 This document makes use of the terms defined in [RFC8499]. The terms 134 "Private DNS", "Global DNS" and "Split DNS" are defined in [RFC8499]. 136 'Encrypted DNS' refers to a DNS protocol that provides an encrypted 137 channel between a DNS client and server (e.g., DoT, DoH, or DoQ). 139 The term "enterprise network" in this document extends to a wide 140 variety of deployment scenarios. For example, an "enterprise" can be 141 a Small Office, Home Office, Corporation, Education facility. The 142 clients that connect to an enterprise network can securely 143 authenticate that network and the client is sure that it has 144 connected to the network it was expecting to. 146 3. PvD NetworkDNSOnly and ErrorNetworkDNSOnly Keys 148 Provisioning Domains (PvDs) are defined in [RFC7556] as sets of 149 network configuration information that clients can use to access 150 networks, including rules for DNS resolution and proxy configuration. 151 [RFC8801] defines a mechanism for discovering multiple Explicit PvDs 152 on a single network and their Additional Information by means of an 153 HTTP-over-TLS query using a URI derived from the PvD ID. This set of 154 additional configuration information is referred to as a Web 155 Provisioning Domain (Web PvD). 157 This document defines two PvD Key: 159 The NetworkDNSOnly PvD Key: which determines if network will block, 160 or attempt to block, DNS queries sent to DNS servers that were not 161 signaled by the network. This key has the value True or False 162 (case insensitive). 164 The ErrorNetworkDNSOnly PvD Key: which contains a extended DNS error 165 code as defined by [RFC8914]. This key is only present if 166 NetworkDNSOnly is True. 168 Where enterprise networks require clients to query the network- 169 designated DNS servers, it sets the PvD NetworkDNSOnly key to True, 170 otherwise sets NetworkDNSOnly to False. If NetworkDNSOnly is set to 171 True, it implies the network will block, or attempt to block, DNS 172 queries sent to DNS servers that were not signaled by the network. 173 If NetworkDNSOnly is True, the ErrorNetworkDNSOnly key MUST contain 174 either 15, 16 or 17 Extended DNS error codes as defined by [RFC8914]. 175 Note that the extended error code "Blocked" defined in Section 4.16 176 of [RFC8914] identifies indicates that access to domains is blocked 177 due to an policy by the operator of the DNS server, extended error 178 code "Censored" defined in Section 4.17 of [RFC8914] identifies 179 access to domains is blocked based on a requirement from an external 180 entity and the extended error code "Filtered" defined in Section 4.18 181 of [RFC8914] identifies access to domains is blocked based on the 182 request from the client to blacklist domains. 184 The ErrorNetworkDNSOnly key is useful when the client does not use 185 DNS resolution by the network-designated DNS server to acquire the IP 186 addresses of alternate DNS servers. For example, the client can be 187 pre-configured with both the domain name and IP addresses of the DNS 188 server not signaled by the network (Section 7.1 in [RFC8310]) or the 189 client can be pre-configured with the IP address of the resolver, and 190 it uses IP address in the certificate as identifier (see [RFC8738]). 191 Further, the ErrorNetworkDNSOnly key is useful when the network 192 security service fails to block access to non-network DNS server but 193 successfully filters traffic from the endpoint to IP addresses not 194 conveyed to the endpoint as part of DNS resolution by the network- 195 designated DNS server. 197 NetworkDNSOnly set to True is an internal security policy expression 198 by the operator of the network but is not a policy prescription to 199 the endpoints to disable its use of its other configured DNS servers; 200 that is, the endpoint can ignore NetworkDNSOnly set to True. If 201 joining an un-trusted network (e.g., coffeeshop, hotel, airport 202 network), a True value of NetworkDNSOnly MUST be ignored. The 203 mechanism the client uses to determine 'trusted network' to assist 204 the user MUST involve authenticated identity of the network (not 205 merely matching SSID in the case of WiFi), such as 802.1X or 206 confirming the network-designated encrypted resolver name is pre- 207 configured in the Operating System and TLS handshake with it 208 succeeds. For example, the client can determine "Open" (unencrypted) 209 wireless networks are untrusted networks, notify the user that using 210 a shared and public Pre-Shared Key (PSK) for wireless authentication 211 is a untrusted network. If the pre-shared-key is the same for all 212 clients that connect to the same WLAN, the shared key will be 213 available to all nodes, including attackers, so it is possible to 214 mount an active on-path attack (e.g., [Evil-Twin], [Krack], 215 [Dragonblood]). For example, coffee shops and air ports use PSK and 216 are unwilling to perform complex configuration on their networks. In 217 addition, customers are generally unwilling to do complicated 218 provisioning on their devices just to obtain free Wi-Fi. This type 219 of networks can be tagged as "untrusted networks" with minimal human 220 intervention. In such cases the endpoint MAY choose to use an 221 alternate network (e.g., cellular) to resolve the global domain 222 names. 224 4. Scope of NetworkDNSOnly Key 226 If a device is managed by an enterprise's IT department, the device 227 can be configured to use a specific encrypted DNS server. This 228 configuration may be manual or rely upon whatever deployed device 229 management tool in an enterprise network. For example, customizing 230 Firefox using Group Policy to use the Enterprise DoH server is 231 discussed in [Firefox-Policy] for Windows and MacOS, and setting 232 Chrome policies is discussed in [Chrome-Policy] and [Chrome-DoH]. 234 If mobile device management (MDM) (e.g., [MDM-Apple]) secures a 235 device, MDM can configure OS/browser with a specific encrypted DNS 236 server. If an endpoint is on-boarded, for example, using Over-The- 237 Air (OTA) enrollment [OTA] to provision the device with a certificate 238 and configuration profile, the configuration profile can include the 239 authentication domain name (ADN) of the encrypted DNS server. The 240 OS/Browser can use the configuration profile to use a specific 241 encrypted DNS server. In this case, MDM is not installed on the 242 device. 244 Provisioning IT-managed devices, BYOD devices with MDM or 245 configuration profile with network-designated DNS server is outside 246 the scope of this document. 248 Typically, Enterprise networks do not assume that all devices in 249 their network are managed by the IT team or MDM, especially in the 250 quite common BYOD scenario. The endpoint can use the discovered 251 network-designated DNS server to only access DNS names for which the 252 Enterprise network claims authority and use another public DNS server 253 for global domains or use the discovered network-designated DNS 254 server to access both private domains and global domains. 256 The scope of NetworkDNSOnly key is restricted to unmanaged BYOD 257 devices without a configuration profile on explicitly trusted 258 networks. In this use case, the user has authorized the client to 259 override local DNS settings for a specific network. It is similar to 260 the way users explicitly disable VPN connection in specific networks 261 and VPN connection is enabled by default in other networks for 262 privacy. The unmanaged BYOD devices use mutual authentication of the 263 client and the enterprise network. The client is typically 264 authenticated with their user credentials (e.g., username and 265 password). The network is typically authenticated with a certificate 266 (e.g., PEAP-MSCHAPv2 [PEAP]) or a mutually-authenticated key exchange 267 which is well-defended from offline attacks (e.g., EAP-pwd [RFC8146], 268 EAP-PSK [RFC4764]). Importantly, WPA-PSK and WPA2-PSK are not well- 269 defended from offline attacks and MUST NOT be used in conjunction 270 with NetworkDNSOnly set to True. 272 Note: Many users have privacy and personal data sovereignty concerns 273 with employers installing MDM on their personal devices; they are 274 concerned that admin can glean personal information and could 275 control how they use their devices. When users do not install MDM 276 on their devices, IT admins do not get visibility into the 277 security posture of those devices. To overcome this problem, a 278 host agent can cryptographically attest the security status 279 associated with device, such as minimum pass code length, 280 biometric login enabled, OS version etc. This approach is fast 281 gaining traction especially with the advent of closed OS like 282 Windows 10 in S mode [win10s] or Chromebook [Chromebook], where 283 applications are sandboxed (e.g., ransomware attack is not 284 possible) and applications can only be installed via the OS store. 286 5. An Example 288 The following example shows how the JSON keys defined in this 289 document can be used: 291 { 292 "identifier": "cafe.example.com.", 293 "expires": "2020-05-23T06:00:00Z", 294 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 295 "NetworkDNSOnly": True, 296 "ErrorNetworkDNSOnly": 15 297 } 299 The JSON keys "identifier", "expires", and "prefixes" are defined in 300 [RFC8801]. 302 6. Security Considerations 304 The content of NetworkDNSOnly and ErrorSplitDNSBlocked may be passed 305 to another (DNS) program for processing. As with any network input, 306 the content SHOULD be considered untrusted and handled accordingly. 307 The security considerations discussed in Section 3 and Section 4 need 308 to be considered to restrict the scope of NetworkDNSOnly and 309 ErrorSplitDNSBlocked PvD Keys to explicitly trusted networks. The 310 NetworkDNSOnly and ErrorSplitDNSBlocked PvD Keys assigned by an 311 anonymous or unknown network (e.g., coffee shops) MUST be ignored by 312 the client. 314 7. IANA Considerations 316 IANA is requested to add NetworkDNSOnly and ErrorSplitDNSBlocked PvD 317 Keys to the Additional Information PvD Keys registry 318 (https://www.iana.org/assignments/pvds/pvds.xhtml). 320 8. Acknowledgements 322 Thanks to Mohamed Boucadair, Jim Reid, Ben Schwartz, Tommy Pauly, 323 Paul Vixie, Ben Schwartz, and Vinny Parla for the discussion and 324 comments. 326 9. References 327 9.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 335 and P. Hoffman, "Specification for DNS over Transport 336 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 337 2016, . 339 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 340 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 341 May 2017, . 343 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 344 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 345 . 347 [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. 348 Shao, "Discovering Provisioning Domain Names and Data", 349 RFC 8801, DOI 10.17487/RFC8801, July 2020, 350 . 352 9.2. Informative References 354 [Chrome-DoH] 355 The Unicode Consortium, "Chrome DNS over HTTPS (aka DoH)", 356 . 358 [Chrome-Policy] 359 The Unicode Consortium, "Chrome policies for users or 360 browsers", . 363 [Chromebook] 364 Microsoft, "Chromebook security", 365 . 368 [Dragonblood] 369 The Unicode Consortium, "Dragonblood: Analyzing the 370 Dragonfly Handshake of WPA3 and EAP-pwd", 371 . 373 [Evil-Twin] 374 The Unicode Consortium, "Evil twin (wireless networks)", 375 . 378 [Firefox-Policy] 379 "Policy templates for Firefox", 380 . 383 [I-D.ietf-add-ddr] 384 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 385 Jensen, "Discovery of Designated Resolvers", Work in 386 Progress, Internet-Draft, draft-ietf-add-ddr-05, 31 387 January 2022, . 390 [I-D.ietf-add-dnr] 391 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 392 Jensen, "DHCP and Router Advertisement Options for the 393 Discovery of Network-designated Resolvers (DNR)", Work in 394 Progress, Internet-Draft, draft-ietf-add-dnr-05, 13 395 December 2021, . 398 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 399 2017, . 401 [MDM-Apple] 402 Apple, "Mobile Device Management", 403 . 406 [OTA] Apple, "Over-the-Air Profile Delivery Concepts", . 411 [PEAP] Microsoft, "[MS-PEAP]: Protected Extensible Authentication 412 Protocol (PEAP)", . 416 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 417 Pre-Shared Key Extensible Authentication Protocol (EAP) 418 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 419 . 421 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 422 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 423 . 425 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 426 DOI 10.17487/RFC7626, August 2015, 427 . 429 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 430 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 431 . 433 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 434 for DNS over TLS and DNS over DTLS", RFC 8310, 435 DOI 10.17487/RFC8310, March 2018, 436 . 438 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 439 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 440 January 2019, . 442 [RFC8738] Shoemaker, R.B., "Automated Certificate Management 443 Environment (ACME) IP Identifier Validation Extension", 444 RFC 8738, DOI 10.17487/RFC8738, February 2020, 445 . 447 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 448 Lawrence, "Extended DNS Errors", RFC 8914, 449 DOI 10.17487/RFC8914, October 2020, 450 . 452 [win10s] Microsoft, "Windows 10 in S mode", 453 . 455 Authors' Addresses 457 Tirumaleswar Reddy 458 Akamai 459 Embassy Golf Link Business Park 460 Bangalore 560071 461 Karnataka 462 India 463 Email: kondtir@gmail.com 464 Dan Wing 465 Citrix Systems, Inc. 466 4988 Great America Pkwy 467 Santa Clara, CA 95054 468 United States of America 469 Email: danwing@gmail.com 471 Kevin Smith 472 Vodafone Group 473 One Kingdom Street 474 London 475 United Kingdom 476 Email: kevin.smith@vodafone.com