idnits 2.17.1 draft-reddy-add-enterprise-00.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, 2020) is 1374 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-reddy-add-iot-byod-bootstrap-00 == Outdated reference: A later version (-04) exists of draft-arkko-farrell-arch-model-t-03 == Outdated reference: A later version (-12) exists of draft-btw-add-home-06 == Outdated reference: A later version (-04) exists of draft-btw-add-ipsecme-ike-00 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-terminology-ter-01 == Outdated reference: A later version (-02) exists of draft-ietf-dprive-phase2-requirements-01 == Outdated reference: A later version (-09) exists of draft-reddy-add-server-policy-selection-03 -- 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 (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD T. Reddy 3 Internet-Draft McAfee 4 Intended status: Informational D. Wing 5 Expires: December 25, 2020 Citrix 6 June 23, 2020 8 DNS-over-HTTPS and DNS-over-TLS Server Deployment Considerations for 9 Enterprise Networks 10 draft-reddy-add-enterprise-00 12 Abstract 14 This document discusses DoH/DoT deployment considerations for 15 Enterprise networks. It particularly sketches the required steps to 16 use DNS-over-TLS (DoT) and/or DNS-over-HTTPS (DoH) server provided by 17 the Enterprise network. 19 One of the goals of the document is to assess to what extent existing 20 tools can be used to provide such service. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 25, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. IT-owned devices . . . . . . . . . . . . . . . . . . . . . . 4 59 4. IoT Devices . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. BYOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Roaming Enterprise Users . . . . . . . . . . . . . . . . . . 7 62 6.1. VPN tunnel . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.2. Client Authentication . . . . . . . . . . . . . . . . . . 7 64 7. Upstream Encryption . . . . . . . . . . . . . . . . . . . . . 8 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 11.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 [RFC7626] discusses DNS privacy considerations in both "on the wire" 76 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 77 [RFC7626]) contexts. In recent years there has also been an increase 78 in the availability of "public resolvers" [RFC8499] which DNS clients 79 may be pre-configured to use instead of the default network resolver 80 for a variety of reasons (e.g., offer a good reachability, support an 81 encrypted transport, provide a strong privacy policy, (lack of) 82 filtering). 84 If public (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484] servers 85 are used instead of using local DNS servers, it can adversely impact 86 Enterprise network-based security. Various network security services 87 are provided by Enterprise networks to protect endpoints (e.g., 88 laptops, printers, IoT devices), and to enforce enterprise policies. 89 These policies may be necessary to protect employees, customers, or 90 citizens. They are not the subject of this memo. 92 Enterprise DNS servers in place for these purpose act on DNS requests 93 originating from endpoints. However, if an endpoint uses public DoT 94 or DoH servers, the desired enterprise protection and enforcement can 95 be bypassed. 97 In order to act on DNS requests from endpoints, network security 98 services can block DoT traffic by dropping outgoing packets to 99 destination port 853. Identifying DoH traffic is far more 100 challenging than DoT traffic. Network security services may try to 101 identify the well-known DoH resolvers by their domain name, and DNS- 102 over-HTTPS traffic can be blocked by dropping outgoing packets to 103 these domains. However, DoH traffic can not be fully identified 104 without acting as a TLS proxy. 106 If a network security service blocks access to the public DoH/DoT 107 server, there are incompatibilities with the privacy profiles 108 discussed in [RFC8310]: 110 o If an endpoint has enabled strict privacy profile (Section 5 of 111 [RFC8310]), the endpoint cannot resolve DNS names. 113 o If an endpoint has enabled opportunistic privacy profile 114 (Section 5 of [RFC8310]), the endpoint will either fallback to an 115 encrypted connection without authenticating the DNS server 116 provided by the local network or fallback to clear text DNS, and 117 cannot exchange encrypted DNS messages. The fallback adversely 118 impacts security and privacy as internal attacks are possible in 119 Enterprise networks. For example, an internal attacker can modify 120 the DNS responses to re-direct the client to malicious servers or 121 pervasively monitor the DNS traffic. The reader may refer to 122 Section 3.2.1 of [I-D.arkko-farrell-arch-model-t] for a discussion 123 on the need for more awareness about attacks from within closed 124 domains. 126 To overcome the above threats, this document specifies mechanisms to 127 configure endpoints to use Enterprise provided DoT and DoH servers, 128 and bootstrap IoT devices and unmanaged endpoints to discover and 129 authenticate the DoT and DoH servers provided by the Enterprise 130 network. 132 A common usage pattern for an IoT device is for it to "call home" to 133 a service that resides on the public Internet, where that service is 134 referenced through a domain name (A or AAAA record). As discussed in 135 Manufacturer Usage Description Specification [RFC8520], because these 136 devices tend to require access to very few sites, all other access 137 should be considered suspect. However, if the query is not 138 accessible for inspection, it becomes quite difficult for the 139 infrastructure to suspect anything. 141 This document focuses on DoH/DoT deployment considerations for 142 Enterprise networks, DoH/DoT sever discovery and deployment 143 considerations for home networks are discussed in [I-D.btw-add-home]. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119][RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 This document makes use of the terms defined in [RFC8499] and 154 [I-D.ietf-dnsop-terminology-ter]. 156 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 158 3. IT-owned devices 160 If a device is managed by an enterprise's IT department, the device 161 can be configured to use Enterprise-provided DoH/DoT servers. This 162 configuration might be manual or rely upon whatever deployed device 163 management tool in an Enterprise. For example, customizing Firefox 164 using Group Policy to use the Enterprise DoH server is discussed in 165 [Firefox-Policy] for Windows and MacOS, and setting Chrome policies 166 is discussed in [Chrome-Policy] and [Chrome-DoH]. 168 4. IoT Devices 170 The solution described in this document is aimed in general at non- 171 constrained IoT devices (i.e., class 2+ [RFC7228]) operating on a 172 Enterprise network without a device management tool and require 173 agentless or standardized approaches. The basis for trust, 174 therefore, is quite different from that of a laptop, tablet, or smart 175 phone. The following bootstrapping mechanisms can be used to 176 securely provision IoT devices to use Enterprise provided DoT and DoH 177 servers: 179 o IoT devices supporting Bootstrapping Remote Secure Key 180 Infrastructures (BRSKI) discussed in 181 [I-D.ietf-anima-bootstrapping-keyinfra] can be bootstrapped with 182 the Enterprise-provided DoH/DoT servers using the mechanism 183 discussed in Section 5 of [I-D.reddy-add-iot-byod-bootstrap]. 185 o [RFC8572] defines a bootstrapping strategy for enabling devices to 186 securely obtain the required configuration information with no 187 installer input. DHCP/RA [I-D.btw-add-home] can be used to 188 discover the DoH/DoT information. If the insecurely discovered 189 DoH/DoT information is not pre-configured in the IoT device, the 190 client can validate the Policy Assertion Token signature 191 (Section 7 [I-D.reddy-add-server-policy-selection]) using the 192 owner certificate (Section 3.2 of [RFC8572]). 194 o When IoT devices connect to a network via EAP methods such as 195 Tunnel Extensible Authentication Protocol (TEAP) [RFC7170], it 196 would be possible to extend these methods to return additional 197 configuration elements as part of completion of the authentication 198 transaction. One simple approach would be after successful 199 completion of the EAP method in Phase 2 for a TEAP server to 200 return a new TLV that indicates the local DoH/DoT information. 202 o Not all of IoT devices support 802.1x supplicant and need an 203 alternate mechanism to connect to the Enterprise network. To 204 address this limitation, unique pre-shared keys are created for 205 each IoT device and WPA-PSK is used [PSK]. In other words, WPA- 206 PSK is used with unique pre-shared keys for different IoT devices 207 to deal security issues. 209 * The IoT device needs to be provisioned with a Pre-Shared Key 210 (PSK) for mutual authentication. The PSK is only known to the 211 IoT device and the WPA server. In this case, the bootstrapping 212 mechanism discussed in Section 4 of 213 [I-D.reddy-add-iot-byod-bootstrap] may be used to securely 214 bootstrap IoT device with the authentication domain name (ADN) 215 and DNS server certificate of the local network's DoH/ DoT 216 server. It uses password-based authenticated key exchange 217 (PAKE) scheme to authenticate the EST server and fetch the DoH/ 218 DoT server certificate. Note that provisioning massive number 219 of IoT devices with PSK is not a scalable onboarding mechanism 220 but will work in Small Office/Home Office (SOHO) and Small/ 221 Medium Enterprise (SME). 223 o If Device Provisioning Protocol (DPP) [dpp] is used, the 224 configurator can securely configure IoT devices with the local 225 DoH/DoT server by extending the content of the configuration 226 elements provided by the configurator. Because DPP can provide a 227 private shared key for use with WPA-PSK, it can be combined with 228 the above methods. 230 o The OMA LWM2M specification [oma] defines an architecture where a 231 new device (LWM2M client) contacts a Bootstrap-server which is 232 responsible for "provisioning" essential bootstrap information. 233 The current standard defines the following four bootstrapping 234 modes (1) Factory Bootstrap (2) Bootstrap from Smartcard (3) 235 Client Initiated Bootstrap (4) Server Initiated Bootstrap. The 236 bootstrap information can be extended to include the local DoH/DoT 237 server details. 239 o The Open Connectivitiy Foundation [ocf] defines the onboarding 240 process before a device is operational. Once the onboarding tool 241 and the new device have authenticated and established secure 242 communication, the onboarding tool can provision the IoT device 243 with the local DoH/DoT server. 245 This document does not discuss opportunistic or leap-of-faith 246 bootstrapping methods, they are susceptible to security issues (e.g., 247 IoT device can be configured with the attacker's DoH/DoT server or 248 disable the use of DoH/DoT). 250 5. BYOD 252 The following mechanisms can be used to bootstrap BYOD (bring your 253 own device) with the DoH/DoT server used by the Enterprise network: 255 o If mobile device management (MDM) [MDM-Apple] is used to secure 256 BYOD, MDM can be used to configure OS/browser with the Enterprise 257 provided DoH/DoT server. 259 o If an endpoint is on-boarded, for example, using Over-The-Air 260 (OTA) enrollment [OTA] to provision the device with a certificate 261 and configuration profile, the configuration profile can include 262 the authentication domain name (ADN) of the DoH/DoT server. The 263 OS/Browser can use the configuration profile to use the Enterprise 264 provided DoH/DoT server. In this case, MDM is not installed on 265 the device. 267 o If an endpoint uses the credentials (username and password) 268 provided by the IT admin to mutually authenticate to the 269 Enterprise WiFi Access Point (e.g., PEAP-MSCHAPv2 [PEAP], EAP-pwd 270 [RFC8146], EAP-PSK [RFC4764]), the boostrapping mechanism 271 discussed in Section 4 of [I-D.reddy-add-iot-byod-bootstrap] can 272 be used to securely bootstrap the endpoint with the ADN and DNS 273 server certificate of the local network's DoH/DoT server. 275 The DNS client uses PAKE scheme to authenticate the EST server 276 using the credentials to authenticate to the network. In this 277 case, the endpoint is neither provisioned with a configuration 278 profile or MDM is installed on the device. Many users have 279 privacy and personal data sovereignty concerns with employers 280 installing MDM on their personal devices; they are concerned that 281 admin can glean personal information and could control how they 282 use their devices. Yet when users do not install MDM on their 283 devices, IT admins do not get visibility into the security posture 284 of those devices. 286 To overcome this problem, a host agent can cryptographically 287 attest the security status associated with device, such as minimum 288 passcode length, biometric login enabled, OS version etc. This 289 approach is fast gaining traction especially with the advent of 290 closed OS like Windows 10 in S mode [win10s] or Chromebook 291 [Chromebook], where applications are sandboxed (e.g., ransomware 292 attack is not possbile) and applications can only be installed via 293 the OS store. 295 When attached to the enterprise network yet needing to use the 296 enterprise's DoH server only to access the internal-only DNS names, 297 the client device can learn about domains for which the local 298 network's resolver is authoritative via dnsZones key defined in 299 Section 4.3 of [I-D.ietf-intarea-provisioning-domains] (as other DoH/ 300 DoT servers will be unaware of the internal-only DNS names). 302 6. Roaming Enterprise Users 304 6.1. VPN tunnel 306 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 307 user connects to the Enterprise network through an VPN tunnel (e.g., 308 IPsec, SSL, Wireguard). The split-tunnel Virtual Private Network 309 (VPN) configuration allows the endpoint to access hosts that reside 310 in the Enterprise network [RFC8598] using that tunnel; other traffic 311 not destined to the Enterprise does not traverse the tunnel. In 312 contrast, a non-split- tunnel VPN configuration causes all traffic to 313 traverse the tunnel into the enterprise. 315 When the VPN tunnel is IPsec, The DoH/DoT server hosted by the 316 Enterprise network can be securely discovered by the endpoint using 317 the INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute Type 318 defined in [I-D.btw-add-ipsecme-ike]. For split-tunnel VPN 319 configurations, the endpoint uses the Enterprise-provided DoT/DoH 320 server to resolve internal-only domain names. For non-split-tunnel 321 VPN configurations, the endpoint uses the Enterprise-provided DoT/DoH 322 server to resolve both internal and external domain names. 324 Other VPN tunnel types have similar configuration capabilities, not 325 detailed here. 327 6.2. Client Authentication 329 When not on the local enterprise network (e.g., at home or coffee 330 shop) yet needing to access the enterprise DoH/DoT server but not 331 through a tunnel, roaming users can use client authentication to 332 access the Enterprise provided DoH/DoT server. For example, Firefox 333 DoH setting accepts user credentials [Firefox-TRR] to authenticate 334 the client to access the DoH server. The exact client authentication 335 mechanism to authenticate to the DoH/DoT server is outside the scope 336 of this specification. 338 7. Upstream Encryption 340 If the Enterprise network is using the local DoH/DoT server 341 configured as a Forwarding DNS server [RFC8499] relying on the 342 upstream resolver (e.g., at an ISP) to perform recursive DNS lookups, 343 DNS messages exchanged between the local DoH/DoT server and recursive 344 resolver MUST be encrypted. If the Enterprise network is using the 345 local DoH/DoT server configured as a recursive DNS server, DNS 346 messages exchanges between the recursive resolver and authoritative 347 servers SHOULD be encrypted to conform to the requirements discussed 348 in [I-D.ietf-dprive-phase2-requirements]. 350 8. Security Considerations 352 Security and privacy considerations in 353 [I-D.reddy-add-iot-byod-bootstrap] need to be taken into 354 consideration. 356 The mechanism defined in [I-D.reddy-add-server-policy-selection] can 357 be used by the DNS server to communicate its privacy statement URL 358 and filtering policy to a DNS client. This communication is 359 cryptographically signed to attest to its authenticity. 361 The DNS client can validate the signatory (i.e., cryptographically 362 attested by the Organization hosting the DoH/DoT server) and the user 363 can review human-readable privacy policy information of the DNS 364 server and assess whether the DNS server performs DNS-based content 365 filtering. 367 If the discovered DoH/DoT server does not meet the privacy preserving 368 data policy and filtering requirements of the user, the user can 369 instruct the DNS client to take appropriate actions. For example, 370 the action can be to use the local DNS server only to access 371 internal-only DNS names and use another DNS server (adhering with 372 his/her expectations) for public domains. 374 9. IANA Considerations 376 This document has no actions for IANA. 378 10. Acknowledgements 380 Thanks to Mohamed Boucadair, Sandeep Rao, Vinny Parla, Nancy Cam- 381 Winget and Eliot Lear for the discussion and comments. 383 11. References 385 11.1. Normative References 387 [I-D.reddy-add-iot-byod-bootstrap] 388 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 389 "A Bootstrapping Procedure to Discover and Authenticate 390 DNS-over-TLS and DNS-over-HTTPS Servers for IoT and BYOD 391 Devices", draft-reddy-add-iot-byod-bootstrap-00 (work in 392 progress), May 2020. 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 400 and P. Hoffman, "Specification for DNS over Transport 401 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 402 2016, . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 409 for DNS over TLS and DNS over DTLS", RFC 8310, 410 DOI 10.17487/RFC8310, March 2018, 411 . 413 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 414 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 415 . 417 11.2. Informative References 419 [Chrome-DoH] 420 The Unicode Consortium, "Chrome DNS over HTTPS (aka DoH)", 421 . 423 [Chrome-Policy] 424 The Unicode Consortium, "Chrome policies for users or 425 browsers", . 428 [Chromebook] 429 Microsoft, "Chromebook security", 430 . 433 [dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol 434 (DPP)", Wi-Fi Alliance , 2018, . 438 [Firefox-Policy] 439 "Policy templates for Firefox", 440 . 443 [Firefox-TRR] 444 "Trusted Recursive Resolver", 445 . 447 [I-D.arkko-farrell-arch-model-t] 448 Arkko, J. and S. Farrell, "Challenges and Changes in the 449 Internet Threat Model", draft-arkko-farrell-arch-model- 450 t-03 (work in progress), March 2020. 452 [I-D.btw-add-home] 453 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, 454 "Encrypted DNS Discovery and Deployment Considerations for 455 Home Networks", draft-btw-add-home-06 (work in progress), 456 May 2020. 458 [I-D.btw-add-ipsecme-ike] 459 Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov, 460 "Internet Key Exchange Protocol Version 2 (IKEv2) 461 Configuration for Encrypted DNS", draft-btw-add-ipsecme- 462 ike-00 (work in progress), April 2020. 464 [I-D.ietf-anima-bootstrapping-keyinfra] 465 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 466 and K. Watsen, "Bootstrapping Remote Secure Key 467 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 468 keyinfra-41 (work in progress), April 2020. 470 [I-D.ietf-dnsop-terminology-ter] 471 Hoffman, P., "Terminology for DNS Transports and 472 Location", draft-ietf-dnsop-terminology-ter-01 (work in 473 progress), February 2020. 475 [I-D.ietf-dprive-phase2-requirements] 476 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 477 Privacy Requirements for Exchanges between Recursive 478 Resolvers and Authoritative Servers", draft-ietf-dprive- 479 phase2-requirements-01 (work in progress), June 2020. 481 [I-D.ietf-intarea-provisioning-domains] 482 Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 483 Shao, "Discovering Provisioning Domain Names and Data", 484 draft-ietf-intarea-provisioning-domains-11 (work in 485 progress), January 2020. 487 [I-D.reddy-add-server-policy-selection] 488 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 489 "DNS Server Selection: DNS Server Information with 490 Assertion Token", draft-reddy-add-server-policy- 491 selection-03 (work in progress), June 2020. 493 [MDM-Apple] 494 Apple, "Mobile Device Management", 495 . 498 [ocf] Open Connectivity Foundation, "OCF Security 499 Specification", Open Connectivitiy Foundation , June 2017, 500 . 503 [oma] Open Mobile Alliance, "Lightweight Machine to Machine 504 Technical Specification: Core", Open Mobile Alliance , 505 June 2019, 506 . 510 [OTA] Apple, "Over-the-Air Profile Delivery Concepts", . 515 [PEAP] Microsoft, "[MS-PEAP]: Protected Extensible Authentication 516 Protocol (PEAP)", . 520 [PSK] Cisco, "Identity PSK Feature Deployment Guide", 521 . 525 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 526 Pre-Shared Key Extensible Authentication Protocol (EAP) 527 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 528 . 530 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 531 "Tunnel Extensible Authentication Protocol (TEAP) Version 532 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 533 . 535 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 536 Constrained-Node Networks", RFC 7228, 537 DOI 10.17487/RFC7228, May 2014, 538 . 540 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 541 Kivinen, "Internet Key Exchange Protocol Version 2 542 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 543 2014, . 545 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 546 DOI 10.17487/RFC7626, August 2015, 547 . 549 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 550 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 551 . 553 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 554 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 555 January 2019, . 557 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 558 Description Specification", RFC 8520, 559 DOI 10.17487/RFC8520, March 2019, 560 . 562 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 563 Touch Provisioning (SZTP)", RFC 8572, 564 DOI 10.17487/RFC8572, April 2019, 565 . 567 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 568 Internet Key Exchange Protocol Version 2 (IKEv2)", 569 RFC 8598, DOI 10.17487/RFC8598, May 2019, 570 . 572 [win10s] Microsoft, "Windows 10 in S mode", 573 . 575 Authors' Addresses 577 Tirumaleswar Reddy 578 McAfee, Inc. 579 Embassy Golf Link Business Park 580 Bangalore, Karnataka 560071 581 India 583 Email: kondtir@gmail.com 585 Dan Wing 586 Citrix Systems, Inc. 587 USA 589 Email: dwing-ietf@fuggles.com