-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-reddy-add-enterprise-00.txt
728 lines (500 loc) · 29.6 KB
/
draft-reddy-add-enterprise-00.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
ADD T. Reddy
Internet-Draft McAfee
Intended status: Informational D. Wing
Expires: December 17, 2020 Citrix
June 15, 2020
DNS-over-HTTPS and DNS-over-TLS Server Deployment Considerations for
Enterprise Networks
draft-reddy-add-enterprise-00
Abstract
This document discusses DoH/DoT deployment considerations for
Enterprise networks. It particularly sketches the required steps to
use DNS-over-TLS (DoT) and/or DNS-over-HTTPS (DoH) server provided by
the Enterprise network.
One of the goals of the document is to assess to what extent existing
tools can be used to provide such service.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Reddy & Wing Expires December 17, 2020 [Page 1]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IT-owned devices . . . . . . . . . . . . . . . . . . . . . . 4
4. IoT Devices . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. BYOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Roaming Enterprise Users . . . . . . . . . . . . . . . . . . 7
6.1. VPN tunnel . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Client Authentication . . . . . . . . . . . . . . . . . . 7
7. Upstream Encryption . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
[RFC7626] discusses DNS privacy considerations in both "on the wire"
(Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of
[RFC7626]) contexts. In recent years there has also been an increase
in the availability of "public resolvers" [RFC8499] which DNS clients
may be pre-configured to use instead of the default network resolver
for a variety of reasons (e.g., offer a good reachability, support an
encrypted transport, provide a strong privacy policy, (lack of)
filtering).
If public (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484] servers
are used instead of using local DNS servers, it can adversely impact
Enterprise network-based security. Various network security services
are provided by Enterprise networks to protect endpoints (e.g.,
laptops, printers, IoT devices), and to enforce enterprise policies.
These policies may be necessary to protect employees, customers, or
citizens. They are not the subject of this memo.
Enterprise DNS servers in place for these purpose act on DNS requests
originating from endpoints. However, if an endpoint uses public DoT
or DoH servers, the desired enterprise protection and enforcement can
be bypassed.
Reddy & Wing Expires December 17, 2020 [Page 2]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
In order to act on DNS requests from endpoints, network security
services can block DoT traffic by dropping outgoing packets to
destination port 853. Identifying DoH traffic is far more
challenging than DoT traffic. Network security services may try to
identify the well-known DoH resolvers by their domain name, and DNS-
over-HTTPS traffic can be blocked by dropping outgoing packets to
these domains. However, DoH traffic can not be fully identified
without acting as a TLS proxy.
If a network security service blocks access to the public DoH/DoT
server, there are incompatibilities with the privacy profiles
discussed in [RFC8310]:
o If an endpoint has enabled strict privacy profile (Section 5 of
[RFC8310]), the endpoint cannot resolve DNS names.
o If an endpoint has enabled opportunistic privacy profile
(Section 5 of [RFC8310]), the endpoint will either fallback to an
encrypted connection without authenticating the DNS server
provided by the local network or fallback to clear text DNS, and
cannot exchange encrypted DNS messages. The fallback adversely
impacts security and privacy as internal attacks are possible in
Enterprise networks. For example, an internal attacker can modify
the DNS responses to re-direct the client to malicious servers or
pervasively monitor the DNS traffic. The reader may refer to
Section 3.2.1 of [I-D.arkko-farrell-arch-model-t] for a discussion
on the need for more awareness about attacks from within closed
domains.
To overcome the above threats, this document specifies mechanisms to
configure endpoints to use Enterprise provided DoT and DoH servers,
and bootstrap IoT devices and unmanaged endpoints to discover and
authenticate the DoT and DoH servers provided by the Enterprise
network.
A common usage pattern for an IoT device is for it to "call home" to
a service that resides on the public Internet, where that service is
referenced through a domain name (A or AAAA record). As discussed in
Manufacturer Usage Description Specification [RFC8520], because these
devices tend to require access to very few sites, all other access
should be considered suspect. However, if the query is not
accessible for inspection, it becomes quite difficult for the
infrastructure to suspect anything.
This document focuses on DoH/DoT deployment considerations for
Enterprise networks, DoH/DoT sever discovery and deployment
considerations for home networks are discussed in [I-D.btw-add-home].
Reddy & Wing Expires December 17, 2020 [Page 3]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document makes use of the terms defined in [RFC8499] and
[I-D.ietf-dnsop-terminology-ter].
'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS.
3. IT-owned devices
If a device is managed by an enterprise's IT department, the device
can be configured to use Enterprise-provided DoH/DoT servers. This
configuration might be manual or rely upon whatever deployed device
management tool in an Enterprise. For example, customizing Firefox
using Group Policy to use the Enterprise DoH server is discussed in
[Firefox-Policy] for Windows and MacOS, and setting Chrome policies
is discussed in [Chrome-Policy] and [Chrome-DoH].
4. IoT Devices
The solution described in this document is aimed in general at non-
constrained IoT devices (i.e., class 2+ [RFC7228]) operating on a
Enterprise network without a device management tool and require
agentless or standardized approaches. The basis for trust,
therefore, is quite different from that of a laptop, tablet, or smart
phone. The following bootstrapping mechanisms can be used to
securely provision IoT devices to use Enterprise provided DoT and DoH
servers:
o IoT devices supporting Bootstrapping Remote Secure Key
Infrastructures (BRSKI) discussed in
[I-D.ietf-anima-bootstrapping-keyinfra] can be bootstrapped with
the Enterprise-provided DoH/DoT servers using the mechanism
discussed in Section 5 of [I-D.reddy-add-iot-byod-bootstrap].
o [RFC8572] defines a bootstrapping strategy for enabling devices to
securely obtain the required configuration information with no
installer input. DHCP/RA [I-D.btw-add-home] can be used to
discover the DoH/DoT information. If the insecurely discovered
DoH/DoT information is not pre-configured in the IoT device, the
client can validate the Policy Assertion Token signature
(Section 7 [I-D.reddy-add-server-policy-selection]) using the
owner certificate (Section 3.2 of [RFC8572]).
Reddy & Wing Expires December 17, 2020 [Page 4]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
o When IoT devices connect to a network via EAP methods such as
Tunnel Extensible Authentication Protocol (TEAP) [RFC7170], it
would be possible to extend these methods to return additional
configuration elements as part of completion of the authentication
transaction. One simple approach would be after successful
completion of the EAP method in Phase 2 for a TEAP server to
return a new TLV that indicates the local DoH/DoT information.
o Not all of IoT devices support 802.1x supplicant and need an
alternate mechanism to connect to the Enterprise network. To
address this limitation, unique pre-shared keys are created for
each IoT device and WPA-PSK is used [PSK]. In other words, WPA-
PSK is used with unique pre-shared keys for different IoT devices
to deal security issues.
* The IoT device needs to be provisioned with a Pre-Shared Key
(PSK) for mutual authentication. The PSK is only known to the
IoT device and the WPA server. In this case, the bootstrapping
mechanism discussed in Section 4 of
[I-D.reddy-add-iot-byod-bootstrap] may be used to securely
bootstrap IoT device with the authentication domain name (ADN)
and DNS server certificate of the local network's DoH/ DoT
server. It uses password-based authenticated key exchange
(PAKE) scheme to authenticate the EST server and fetch the DoH/
DoT server certificate. Note that provisioning massive number
of IoT devices with PSK is not a scalable onboarding mechanism
but will work in Small Office/Home Office (SOHO) and Small/
Medium Enterprise (SME).
o If Device Provisioning Protocol (DPP) [dpp] is used, the
configurator can securely configure IoT devices with the local
DoH/DoT server by extending the content of the configuration
elements provided by the configurator. Because DPP can provide a
private shared key for use with WPA-PSK, it can be combined with
the above methods.
o The OMA LWM2M specification [oma] defines an architecture where a
new device (LWM2M client) contacts a Bootstrap-server which is
responsible for "provisioning" essential bootstrap information.
The current standard defines the following four bootstrapping
modes (1) Factory Bootstrap (2) Bootstrap from Smartcard (3)
Client Initiated Bootstrap (4) Server Initiated Bootstrap. The
bootstrap information can be extended to include the local DoH/DoT
server details.
o The Open Connectivitiy Foundation [ocf] defines the onboarding
process before a device is operational. Once the onboarding tool
and the new device have authenticated and established secure
Reddy & Wing Expires December 17, 2020 [Page 5]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
communication, the onboarding tool can provision the IoT device
with the local DoH/DoT server.
This document does not discuss opportunistic or leap-of-faith
bootstrapping methods, they are susceptible to security issues (e.g.,
IoT device can be configured with the attacker's DoH/DoT server or
disable the use of DoH/DoT).
5. BYOD
The following mechanisms can be used to bootstrap BYOD (bring your
own device) with the DoH/DoT server used by the Enterprise network:
o If mobile device management (MDM) [MDM-Apple] is used to secure
BYOD, MDM can be used to configure OS/browser with the Enterprise
provided DoH/DoT server.
o If an endpoint is on-boarded, for example, using Over-The-Air
(OTA) enrollment [OTA] to provision the device with a certificate
and configuration profile, the configuration profile can include
the authentication domain name (ADN) of the DoH/DoT server. The
OS/Browser can use the configuration profile to use the Enterprise
provided DoH/DoT server. In this case, MDM is not installed on
the device.
o If an endpoint uses the credentials (username and password)
provided by the IT admin to mutually authenticate to the
Enterprise WiFi Access Point (e.g., PEAP-MSCHAPv2 [PEAP], EAP-pwd
[RFC8146], EAP-PSK [RFC4764]), the boostrapping mechanism
discussed in Section 4 of [I-D.reddy-add-iot-byod-bootstrap] can
be used to securely bootstrap the endpoint with the ADN and DNS
server certificate of the local network's DoH/DoT server.
The DNS client uses PAKE scheme to authenticate the EST server
using the credentials to authenticate to the network. In this
case, the endpoint is neither provisioned with a configuration
profile or MDM is installed on the device. Many users have
privacy and personal data sovereignty concerns with employers
installing MDM on their personal devices; they are concerned that
admin can glean personal information and could control how they
use their devices. Yet when users do not install MDM on their
devices, IT admins do not get visibility into the security posture
of those devices.
To overcome this problem, a host agent can cryptographically
attest the security status associated with device, such as minimum
passcode length, biometric login enabled, OS version etc. This
approach is fast gaining traction especially with the advent of
Reddy & Wing Expires December 17, 2020 [Page 6]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
closed OS like Windows 10 in S mode [win10s] or Chromebook
[Chromebook], where applications are sandboxed (e.g., ransomware
attack is not possbile) and applications can only be installed via
the OS store.
When attached to the enterprise network yet needing to use the
enterprise's DoH server only to access the internal-only DNS names,
the client device can learn about domains for which the local
network's resolver is authoritative via dnsZones key defined in
Section 4.3 of [I-D.ietf-intarea-provisioning-domains] (as other DoH/
DoT servers will be unaware of the internal-only DNS names).
6. Roaming Enterprise Users
6.1. VPN tunnel
In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming
user connects to the Enterprise network through an VPN tunnel (e.g.,
IPsec, SSL, Wireguard). The split-tunnel Virtual Private Network
(VPN) configuration allows the endpoint to access hosts that reside
in the Enterprise network [RFC8598] using that tunnel; other traffic
not destined to the Enterprise does not traverse the tunnel. In
contrast, a non-split- tunnel VPN configuration causes all traffic to
traverse the tunnel into the enterprise.
When the VPN tunnel is IPsec, The DoH/DoT server hosted by the
Enterprise network can be securely discovered by the endpoint using
the INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute Type
defined in [I-D.btw-add-ipsecme-ike]. For split-tunnel VPN
configurations, the endpoint uses the Enterprise-provided DoT/DoH
server to resolve internal-only domain names. For non-split-tunnel
VPN configurations, the endpoint uses the Enterprise-provided DoT/DoH
server to resolve both internal and external domain names.
Other VPN tunnel types have similar configuration capabilities, not
detailed here.
6.2. Client Authentication
When not on the local enterprise network (e.g., at home or coffee
shop) yet needing to access the enterprise DoH/DoT server but not
through a tunnel, roaming users can use client authentication to
access the Enterprise provided DoH/DoT server. For example, Firefox
DoH setting accepts user credentials [Firefox-TRR] to authenticate
the client to access the DoH server. The exact client authentication
mechanism to authenticate to the DoH/DoT server is outside the scope
of this specification.
Reddy & Wing Expires December 17, 2020 [Page 7]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
7. Upstream Encryption
If the Enterprise network is using the local DoH/DoT server
configured as a Forwarding DNS server [RFC8499] relying on the
upstream resolver (e.g., at an ISP) to perform recursive DNS lookups,
DNS messages exchanged between the local DoH/DoT server and recursive
resolver MUST be encrypted. If the Enterprise network is using the
local DoH/DoT server configured as a recursive DNS server, DNS
messages exchanges between the recursive resolver and authoritative
servers SHOULD be encrypted to conform to the requirements discussed
in [I-D.ietf-dprive-phase2-requirements].
8. Security Considerations
Security and privacy considerations in
[I-D.reddy-add-iot-byod-bootstrap] need to be taken into
consideration.
The mechanism defined in [I-D.reddy-add-server-policy-selection] can
be used by the DNS server to communicate its privacy statement URL
and filtering policy to a DNS client. This communication is
cryptographically signed to attest to its authenticity.
The DNS client can validate the signatory (i.e., cryptographically
attested by the Organization hosting the DoH/DoT server) and the user
can review human-readable privacy policy information of the DNS
server and assess whether the DNS server performs DNS-based content
filtering.
If the discovered DoH/DoT server does not meet the privacy preserving
data policy and filtering requirements of the user, the user can
instruct the DNS client to take appropriate actions. For example,
the action can be to use the local DNS server only to access
internal-only DNS names and use another DNS server (adhering with
his/her expectations) for public domains.
9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgements
Thanks to Mohamed Boucadair, Sandeep Rao, Vinny Parla, Nancy Cam-
Winget and Eliot Lear for the discussion and comments.
Reddy & Wing Expires December 17, 2020 [Page 8]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
11. References
11.1. Normative References
[I-D.reddy-add-iot-byod-bootstrap]
Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair,
"A Bootstrapping Procedure to Discover and Authenticate
DNS-over-TLS and DNS-over-HTTPS Servers for IoT and BYOD
Devices", draft-reddy-add-iot-byod-bootstrap-00 (work in
progress), May 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
11.2. Informative References
[Chrome-DoH]
The Unicode Consortium, "Chrome DNS over HTTPS (aka DoH)",
<https://www.chromium.org/developers/dns-over-https>.
[Chrome-Policy]
The Unicode Consortium, "Chrome policies for users or
browsers", <https://support.google.com/chrome/a/
answer/2657289?hl=en>.
Reddy & Wing Expires December 17, 2020 [Page 9]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
[Chromebook]
Microsoft, "Chromebook security",
<https://support.google.com/chromebook/
answer/3438631?hl=en>.
[dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol
(DPP)", Wi-Fi Alliance , 2018, <https://www.wi-
fi.org/download.php?file=/sites/default/files/private/
Device_Provisioning_Protocol_Specification_v1.1_1.pdf>.
[Firefox-Policy]
"Policy templates for Firefox",
<https://github.com/mozilla/policy-templates/blob/master/
README.md#dnsoverhttps>.
[Firefox-TRR]
"Trusted Recursive Resolver",
<https://wiki.mozilla.org/Trusted_Recursive_Resolver>.
[I-D.arkko-farrell-arch-model-t]
Arkko, J. and S. Farrell, "Challenges and Changes in the
Internet Threat Model", draft-arkko-farrell-arch-model-
t-03 (work in progress), March 2020.
[I-D.btw-add-home]
Boucadair, M., Reddy.K, T., Wing, D., and N. Cook,
"Encrypted DNS Discovery and Deployment Considerations for
Home Networks", draft-btw-add-home-06 (work in progress),
May 2020.
[I-D.btw-add-ipsecme-ike]
Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov,
"Internet Key Exchange Protocol Version 2 (IKEv2)
Configuration for Encrypted DNS", draft-btw-add-ipsecme-
ike-00 (work in progress), April 2020.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-41 (work in progress), April 2020.
[I-D.ietf-dnsop-terminology-ter]
Hoffman, P., "Terminology for DNS Transports and
Location", draft-ietf-dnsop-terminology-ter-01 (work in
progress), February 2020.
Reddy & Wing Expires December 17, 2020 [Page 10]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
[I-D.ietf-dprive-phase2-requirements]
Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS
Privacy Requirements for Exchanges between Recursive
Resolvers and Authoritative Servers", draft-ietf-dprive-
phase2-requirements-00 (work in progress), December 2019.
[I-D.ietf-intarea-provisioning-domains]
Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
draft-ietf-intarea-provisioning-domains-11 (work in
progress), January 2020.
[I-D.reddy-add-server-policy-selection]
Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair,
"DNS Server Selection: DNS Server Information with
Assertion Token", draft-reddy-add-server-policy-
selection-02 (work in progress), May 2020.
[MDM-Apple]
Apple, "Mobile Device Management",
<https://developer.apple.com/documentation/
devicemanagement>.
[ocf] Open Connectivity Foundation, "OCF Security
Specification", Open Connectivitiy Foundation , June 2017,
<https://openconnectivity.org/specs/
OCF_Security_Specification_v1.0.0.pdf>.
[oma] Open Mobile Alliance, "Lightweight Machine to Machine
Technical Specification: Core", Open Mobile Alliance ,
June 2019,
<http://www.openmobilealliance.org/release/LightweightM2M/
V1_1_1-20190617-A/OMA-TS-LightweightM2M_Core-
V1_1_1-20190617-A.pdf>.
[OTA] Apple, "Over-the-Air Profile Delivery Concepts", <https://
developer.apple.com/library/archive/documentation/Networki
ngInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/
OTASecurity.html>.
[PEAP] Microsoft, "[MS-PEAP]: Protected Extensible Authentication
Protocol (PEAP)", <https://docs.microsoft.com/en-
us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-
beec-fb367325c0f9>.
Reddy & Wing Expires December 17, 2020 [Page 11]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
[PSK] Cisco, "Identity PSK Feature Deployment Guide",
<https://www.cisco.com/c/en/us/td/docs/wireless/
controller/technotes/8-5/
b_Identity_PSK_Feature_Deployment_Guide.html>.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
<https://www.rfc-editor.org/info/rfc4764>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<https://www.rfc-editor.org/info/rfc7626>.
[RFC8146] Harkins, D., "Adding Support for Salted Password Databases
to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017,
<https://www.rfc-editor.org/info/rfc8146>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
Reddy & Wing Expires December 17, 2020 [Page 12]
Internet-Draft DoH/DoT in Enterprise Networks June 2020
[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>.
[win10s] Microsoft, "Windows 10 in S mode",
<https://www.microsoft.com/en-us/windows/s-mode>.
Authors' Addresses
Tirumaleswar Reddy
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: [email protected]
Dan Wing
Citrix Systems, Inc.
USA
Email: [email protected]
Reddy & Wing Expires December 17, 2020 [Page 13]