-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-reddy-add-iot-byod-bootstrap-01.xml
884 lines (741 loc) · 42.7 KB
/
draft-reddy-add-iot-byod-bootstrap-01.xml
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
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-add-iot-byod-bootstrap-00"
ipr="trust200902">
<front>
<title
abbrev="DoT/DoH server discovery for for BYOD/IoT devices in Enterprise Networks">A
Bootstrapping Procedure to Discover and Authenticate DNS-over-TLS and
DNS-over-HTTPS Servers for IoT and BYOD Devices</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="McAfee">McAfee, Inc.</organization>
<address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560071</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization>
<address>
<postal>
<street></street>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Michael C. Richardson" initials="M."
surname="Richardson">
<organization>Sandelman Software Works</organization>
<address>
<postal>
<street></street>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="5" month="May" year="2020" />
<workgroup>ADD WG</workgroup>
<abstract>
<t>This document specifies mechanisms to bootstrap endpoints (e.g.,
hosts, IoT devices) to discover and authenticate DNS-over-TLS and
DNS-over-HTTPS servers provided by a local network for IoT/BYOD devices
in Enterprise networks.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Traditionally a caching DNS server has been provided by local
networks. This provides benefits such as low latency to reach that DNS
server (owing to its network proximity to the endpoint). However, if an
endpoint is configured to use Internet-hosted or public DNS-over-TLS
(DoT) <xref target="RFC7858"></xref> or DNS-over-HTTPS (DoH) <xref
target="RFC8484"></xref> servers, any available local DNS server cannot
serve DNS requests from local endpoints. If public DNS servers are used
instead of using local DNS servers, some operational problems can occur
such as those listed below:</t>
<t><list style="symbols">
<t>"Split DNS" <xref target="RFC2775"></xref> to use the special
internal-only domain names (e.g., "internal.example.com") in
enterprise networks will not work, and ".local" and "home.arpa"
names cannot be locally resolved in home networks.</t>
<t>Content Delivery Networks (CDNs) that map traffic based on DNS
may lose the ability to direct end-user traffic to a nearby
service-specific cluster in cases where a DNS service is being used
that is not affiliated with the local network and which does not
send "EDNS Client Subnet" (ECS) information <xref
target="RFC7871"></xref> to the CDN's DNS authorities <xref
target="CDN"></xref>.</t>
</list></t>
<t>If public DNS servers are used instead of local DNS servers, the
following discusses the impacts on network-based security:</t>
<t><list style="symbols">
<t>Various network security services are provided by Enterprise
networks to protect endpoints (e.g,. Hosts, IoT devices).
Network-based security solutions such as firewalls (FW) and
Intrusion Prevention Systems (IPS) rely on network traffic
inspection to implement perimeter-based security policies. The
network security services may for example prevent malware download,
block known malicious URLs, enforce use of strong ciphers, stop data
exfiltration, etc. These network security services act on DNS
requests originating from endpoints. However, if an endpoint is
configured to use public DoH/DoT servers, network security services
cannot act on DNS requests from these endpoints.</t>
<t>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 domains offering DoH servers, and DoH traffic can be
blocked by dropping outgoing packets to these domains. If an
endpoint has enabled strict privacy profile (Section 5 of <xref
target="RFC8310"></xref>), and the network security service blocks
the traffic to the public DNS server, the DNS service won't be
available to the endpoint and ultimately the endpoint cannot access
Internet-reachable services.</t>
<t>If an endpoint has enabled opportunistic privacy profile (Section
5 of <xref target="RFC8310"></xref>), and the network security
service blocks traffic to the public DNS server, 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.</t>
</list></t>
<t>If the network security service fails to block DoH/DoT traffic, this
can compromise the endpoint security; some of the potential security
threats are listed below:</t>
<t><list style="symbols">
<t>The network security service cannot prevent an endpoint from
accessing malicious domains.</t>
<t>If the endpoint is an IoT device which is configured to use
public DoH/DoT servers, and if a policy enforcement point in the
local network is programmed using, for example, a Manufacturer Usage
Description (MUD) file <xref target="RFC8520"></xref> by a MUD
manager to only allow intended communications to and from the IoT
device, the policy enforcement point cannot enforce the network
Access Control List (ACL) rules based on domain names (Section 8 of
<xref target="RFC8520"></xref>).</t>
</list></t>
<t>If the network security service successfully blocks DoT and DoH
traffic, this can still compromise the endpoint security and privacy;
some of the potential security threats are listed below:<list
style="symbols">
<t>Networks are susceptible to internal attacks as discussed in
Section 3.2 of <xref
target="I-D.arkko-farrell-arch-model-t"></xref>. An internal
attacker can modify the DNS responses to re-direct the client to
malicious servers.</t>
<t>Pervasive monitoring of DNS traffic.</t>
</list></t>
<t>In addition, the local network's DNS server is advertised using
DHCP/RA which is insecure and also provides no mechanism to securely
authenticate the DNS server. To overcome the above threats, this
document specifies a mechanism to bootstrap endpoints to discover and
authenticate the DoT and DoH servers provided by their local network.
The overall procedure can be structured into the following steps:<list
style="symbols">
<t><xref target="bootstrap-endpoint">Bootstrapping</xref> is
necessary only when connecting to a new network or when the
network's DNS certificate has changed. Bootstrapping procedure
authenticates the Enrollment over Secure Transport (EST) <xref
target="RFC7030"></xref> server to the endpoint. After
authenticating the EST server, DNS server certificate used by the
local network is downloaded to the endpoint. This DNS server
certificate enables subsequent authenticated encrypted communication
with the local DNS server (e.g., DoH) during in the connection
phase.</t>
<t><xref target="auth">Connection handshake and service
invocation</xref>: The DNS client initiates a TLS handshake with the
DNS server learned in the discovery phase, and validates the DNS
server's identity using the credentials obtained in the
bootstrapping phase.</t>
</list></t>
<t><list style="hanging">
<t hangText="Note: ">The strict and opportunistic privacy profiles
as defined in <xref target="RFC8310"></xref> only applies to DoT
protocol, there has been no such distinction made for DoH
protocol.</t>
</list></t>
</section>
<section anchor="scope" title="Scope">
<t>The problems discussed in <xref target="intro"></xref> will be
encountered in Enterprise networks. Typically Enterprise networks do not
assume that all devices in their network are managed by the IT team or
Mobile Device Management (MDM) devices, especially in the quite common
BYOD ("Bring Your Own Device") scenario. The mechanisms specified in
this document can be used by BYOD devices to discover and authenticate
DoT and DoH servers provided by the Enterprise network. This mechanism
can also be used by IoT devices (managed by IT team) after onboarding to
discover and authenticate DoT and DoH servers provided by the Enterprise
network.</t>
<t>Wireless LAN as frequently deployed is vulnerable to various attacks
(<xref target="Evil-Twin"></xref>,<xref target="Krack"> </xref> and
<xref target="Dragonblood"></xref>). Because of these attacks, only
cryptographically authenticated communications are trusted on Wireless
LAN networks. This means information provided by such networks via DHCP,
DHCPv6, or RA (e.g., NTP server, DNS server, default domain) are
untrusted because DHCP and RA are not authenticated. <xref
target="I-D.btw-add-home"></xref> discusses DoH/DoT server discovery
using DHCP/RA but requires the DoH/DoT server to be pre-configured in
the endpoint (OS or Browser) or the DNS client must be able
cryptographically identify it is connecting to a DoT/DoH server hosted
by a specific organization (e.g., ISP or Enterprise) (see <xref
target="I-D.reddy-add-server-policy-selection"></xref>) to prevent the
client from connecting to a attackers server.</t>
<t>Users have to indicate to their system in some way that they desire
bootstrapping to be performed only when connecting to a specific network
(e.g., organization for which a user works or a user works temporarily
within another corporation), similar to the way users disable VPN
connection in specific network (e.g., Enterprise network) and enable VPN
connection by default in other networks. If the discovered DNS server
meets the privacy preserving data policy requirements of the user, the
user can select to use the discovered DoT and DoH servers.</t>
<!--
<t>If the client device joins an open WiFi network (that is, one without
any security credentials) or joins a WiFi using a single shared
password among all the attached devices (e.g., as commonly deployed
with WPA2-Personal), such networks can be spoofed by an attacker
hosting a fake access point with the same SSID and password. With
such WiFi networks, the client cannot know if the
discovered DNS-over-HTTPS or DNS-over-TLS server is hosted by the
legitimate network operator or by an attacker.
</t>
-->
</section>
<section anchor="notation" title="Terminology">
<t>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
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
only when, they appear in all capitals, as shown here.</t>
<t>This document makes use of the terms defined in <xref
target="RFC8499"></xref> and <xref
target="I-D.ietf-dnsop-terminology-ter"></xref>.</t>
<t>'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS.</t>
</section>
<section anchor="bootstrap-endpoint"
title="Bootstrapping Endpoint Devices">
<t>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 <xref
target="Firefox-Policy"></xref> for Windows and MacOS, and setting
Chrome policies is discussed in <xref target="Chrome-Policy"></xref> and
<xref target="Chrome-DoH"></xref>.</t>
<t>If mobile device management (MDM) (e.g, <xref
target="MDM-Apple"></xref>) is used to secure BYOD, MDM can be used to
configure OS/browser with the Enterprise provided DoH/DoT server. If an
endpoint is on-boarded, for example, using Over-The-Air (OTA) enrollment
<xref target="OTA"></xref> 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.</t>
<section anchor="bootstrap-byod" title="Bootstrapping BYOD">
<t>This section focuses on bootstrapping Bring your own device (BYOD)
to discover and authenticate DoH/DoT server provided by the enterprise
network but without MDM or configuration profile on the endpoint. If
an endpoint uses the credentials (username and password) provided by
the IT admin to mutually authenticate to the Enterprise WLAN Access
Point (e.g., PEAP-MSCHAPv2 <xref target="PEAP"></xref>, EAP-pwd <xref
target="RFC8146"></xref>, EAP-PSK <xref target="RFC4764"></xref>), the
following steps can be used to securely bootstrap the endpoint with
the authentication domain name (ADN, defined in <xref
target="RFC8310"></xref>) and DNS server certificate of the local
network's DoH/DoT server:</t>
<t><list style="numbers">
<t>The endpoint authenticates to the local network and discovers
the Enrollment over Secure Transport (EST) <xref
target="RFC7030"></xref> server using the procedure discussed in
<xref target="EST_Discovery"></xref>.</t>
<t>The endpoint establishes provisional TLS connection with that
EST server, i.e., the endpoint provisionally accepts the
unverified TLS server certificate. However, the endpoint MUST
authenticate the EST server before it accepts the DNS server
certificate. The endpoint either uses password-based authenticated
key exchange (PAKE) with TLS 1.3 <xref
target="I-D.barnes-tls-pake"></xref> as an authentication method
or uses the mutual authentication protocol for HTTP <xref
target="RFC8120"> </xref> to authenticate the discovered EST
server. <vspace blankLines="1" />As a reminder, PAKE is an
authentication method that allows the use of usernames and
passwords over unencrypted channels without revealing the
passwords to an eavesdropper. Similarly, the mutual authentication
for HTTP is based on PAKE and provides mutual authentication
between an HTTP client and an HTTP server using username and
password as credentials. The cryptographic algorithms to use with
the mutual authentication protocol for HTTP are defined in <xref
target="RFC8121"></xref>. <vspace blankLines="1" />Note that the
Crypto Forum Research Group (cfrg) has selected draft-haase-cpace
and draft-krawczyk-cfrg-opaque drafts to recommend for balanced
and augmented password-based authenticated key establishment in
IETF protocols. This step will be further updated.<vspace
blankLines="1" /></t>
<t>The endpoint needs to use PAKE scheme to perform authentication
the first time it connects to an EST server. If the EST server
authentication is successful, the server's identity can be used to
authenticate subsequent TLS connections to that EST server. The
endpoint configures the reference identifier for the EST server
using the DNS-ID identifier type in the EST server certificate. On
subsequent connections to the EST server, the endpoint MUST
validate the EST server certificate using the Implict Trust Anchor
database (i.e, the EST server certificate must pass PKIX
certification path validation <xref target="RFC6125"></xref>) and
match the reference identifier against the EST server's identity
according to the rules specified in Section 6.4 of <xref
target="RFC6125"></xref>.</t>
<t>The endpoint learns the End-Entity certificates <xref
target="RFC8295"></xref> from the EST server. The certificate
provisioned to the DNS server in the local network will be treated
as a End-Entity certificate. As a reminder, the End-Entity
certificates must be validated by the endpoint using an authorized
trust anchor (Section 3.2 of <xref target="RFC8295"></xref>). The
endpoint needs to identify the certificate provisioned to the DNS
server. The SRV-ID identifier type <xref target="RFC6125"></xref>
within subjectAltName entry MUST be used to identify the DNS
server certificate. <vspace blankLines="1" />For example, DNS
server certificate will include SRV-ID "_domain-s.example.net"
along with DNS-ID "example.net". The SRV service label "domain-s"
is defined in Section 6 of <xref target="RFC7858"></xref> for DoT
protocol. The SRV service label "doh" is defined in <xref
target="IANA"></xref> for DoH protocol.</t>
<t>The endpoint configures the authentication domain name (ADN)
(defined in <xref target="RFC8310"></xref>) for the DNS server
from the DNS-ID identifier type within subjectAltName entry in the
DNS server certificate. The DNS server certificate is associated
with the ADN to be matched with the certificate given by the DNS
server in TLS. To some extent, this approach is similar to
certificate usage PKIX-EE(1) defined in <xref
target="RFC7671"></xref>.</t>
</list></t>
<t><xref target="fig1"></xref> illustrates a sequence diagram for
bootstrapping an endpoint with the local network's ADN and DNS server
certificate.</t>
<t><figure anchor="fig1" title="Bootstrapping Endpoint Devices">
<artwork align="left"><![CDATA[
+----------+ +--------+ +--------+
| Endpoint | | EST | | DNS |
| | | Server | | Server |
+----------+ +--------+ +--------+
| DNS-SD query to discover the EST server | |
|-------------------------------------------------------->|
| | |
| optional: mDNS query to | |
| discover the EST server | |
|--------------------------------------------->| |
| | |
| Establish provisional TLS connection | |
|<-------------------------------------------->| |
| | |
| PAKE scheme to authenticate the EST server | |
|<-------------------------------------------->| |
| | |
[Generate reference identifier for the EST server | |
to compare with the EST server certificate | |
in subsequent TLS connections] | |
| | |
| Get EE certificates | |
|--------------------------------------------->| |
| | |
[Identify the DNS server certificate in EE | |
certificates to match with the certificate | |
by the DNS server in TLS handshake] | |
| |
[Configure ADN and associate DNS server certificate] | |
| | |
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="bootstrap-iot" title="Bootstrapping IoT Devices">
<t>The following steps explain the mechanism to bootstrap IoT devices
supporting Bootstrapping Remote Secure Key Infrastructures (BRSKI)
discussed in <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"></xref> with local
network's CA certificates, ADN and DNS server certificate:</t>
<t><list style="symbols">
<t>Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed
in <xref target="I-D.ietf-anima-bootstrapping-keyinfra"></xref>
provides a solution for secure automated bootstrap of devices. BRSKI
specifies means to provision credentials on devices to be used to
operationally access networks. In addition, BRSKI provides an
automated mechanism for the bootstrap distribution of CA
certificates from the EST server. The IoT device can use BRSKI to
bootstrap the IoT device using the IoT manufacturer provisioned
X.509 certificate, in combination with a registrar provided by the
local network and IoT device manufacturer's authorizing service
(MASA):<list style="numbers">
<t>The IoT device authenticates to the local network using the
IoT manufacturer provisioned X.509 certificate. The IoT device
can request and get a voucher from the MASA service via the
registrar. The voucher is signed by the MASA service and
includes the local network's CA public key.</t>
<t>The IoT device validates the signed voucher using the
manufacturer installed trust anchor associated with the MASA,
stores the CA's public key and validates the provisional TLS
connection to the registrar.</t>
<t>The IoT device requests the full EST distribution of current
CA certificates (Section 5.9.1 in <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"></xref>) from the
registrar operating as a BRSKI-EST server. The IoT devices
stores the CA certificates as Explicit Trust Anchor database
entries. The IoT device uses the Explicit Trust Anchor database
to validate the DNS server certificate.</t>
<t>The IoT device learns the End-Entity certificates from the
BRSKI-EST server. The certificate provisioned to the DNS server
in the local network will be treated as an End-Entity
certificate. The IoT device needs to identify the certificate
provisioned to the DNS server. The SRV-ID identifier type within
subjectAltName entry MUST be used to identify the DNS server
certificate (see Step 4 in <xref
target="bootstrap-byod"></xref>).</t>
<t>The endpoint configures the ADN for the DNS server from the
DNS-ID identifier type within subjectAltName entry in the DNS
server certificate. The DNS server certificate is associated
with the ADN to be matched with the certificate given by the DNS
server in TLS.</t>
</list></t>
</list></t>
</section>
<section anchor="auth" title="Connection Handshake and Service Invocation">
<t>The DNS client resolves the ADN using the mechanism discussed in
Section 7.2 of <xref target="RFC8310"></xref>. The DNS client initiates
TLS handshake with the DNS server, the DNS server presents its
certificate in ServerHello message, and the DNS client MUST match the
DNS server certificate downloaded in Step 4 in <xref
target="bootstrap-byod"></xref> or <xref target="bootstrap-iot"></xref>
with the certificate provided by the DNS server in TLS handshake. If the
match is successful, the DNS client MUST validate the server certificate
using an authorized trust anchor.</t>
<t>If the match is successful and server certificate is successfully
validated, the client continues with the connection as normal.
Otherwise, the client MUST treat the server certificate validation
failure as a non-recoverable error. If the DNS client cannot reach or
establish an authenticated and encrypted connection with the
privacy-enabling DNS server provided by the local network, the DNS
client can fallback to a privacy-enabling public DNS server.</t>
<t>The DoH client contacts that DoH resolver to retrieve the list of
supported DoH services using the well-known URI defined in <xref
target="I-D.btw-add-rfc8484-clarification"></xref>.</t>
</section>
<section anchor="EST_Discovery" title="EST Service Discovery Procedure">
<t>An EST client discovers the EST server in the local network by using
DNS-based Service Discovery (DNS-SD) <xref target="RFC6763"></xref> or
Multicast DNS (mDNS) <xref target="RFC6762"></xref>. The <Domain>
portion specifies the DNS sub-domain where the service instance is
registered. It may be "local.", indicating the mDNS local domain, or it
may be a conventional domain name such as "example.com.". The
<Service> portion of the EST service instance name MUST be
"_est._tcp".</t>
<t>A EST client application can proactively discover an EST server being
advertised in the site by multicasting a PTR query to the following:</t>
<t><list style="empty">
<t>"_est._tcp.local"</t>
</list>An EST server can send out gratuitous multicast DNS answer
packets whenever it starts up, wakes from sleep, or detects a change in
EST server configuration. EST client application can receive these
gratuitous packets and cache information contained in them.</t>
</section>
<section anchor="reattach" title="Network Reattachment">
<t>On subsequent attachments to the network, the endpoint initiates TLS
handshake with the DoH/DoT server (configured in Step 5 of <xref
target="bootstrap-byod"></xref> or <xref target="bootstrap-iot"></xref>)
and follows the mechanism discussed in <xref target="auth"></xref> to
validate the DNS server certificate.</t>
<t>If the DNS server certificate is invalid (e.g., revoked or expired),
the endpoint discovers and initiates TLS handshake with the EST server,
and uses the validation techniques described in <xref
target="RFC6125"></xref> to compare the reference identifier (created in
Step 2 of <xref target="bootstrap-byod"></xref> in this document) to the
EST server certificate and verifies the entire certification path as per
<xref target="RFC5280"></xref>. The endpoint then gets the DNS server
certificate from the EST server. If the DNS-ID identifier type within
subjectAltName entry in the DNS server certificate does not match the
configured ADN, the ADN is replaced with the DNS-ID identifier type. The
DNS server certificate associated with the ADN is replaced with the one
provided by the EST server. The endpoint initiates TLS handshake with
the newly discovered ADN and follows the mechanism discussed in <xref
target="auth"></xref> to validate the DNS server certificate.</t>
<t><xref target="fig2"></xref> illustrates a sequence diagram for
re-configuring an endpoint with ADN and local network's DNS server
certificate on subsequent attachments to the network.</t>
<t><figure anchor="fig2"
title="Bootstrapping Endpoint Devices on subsequent attachments to the network">
<artwork align="left"><![CDATA[+----------+ +--------+ +--------+
| Endpoint | | EST | | DNS |
| | | Server | | Server |
+----------+ +--------+ +--------+
| DNS-SD query to discover the EST server | |
|-------------------------------------------------------->|
| | |
| optional: mDNS query to | |
| discover the EST server | |
|--------------------------------------------->| |
| | |
| Establish TLS connection | |
| and validate EST server certificate | |
|<-------------------------------------------->| |
| | |
| Get EE certificates | |
|<-------------------------------------------->| |
| | |
[Identify the DNS server certificate in EE | |
certificates to match with the certificate | |
by the DNS server in TLS handshake] | |
| |
[Re-configure ADN and associate DNS server certificate]| |
| | |
]]></artwork>
</figure></t>
</section>
<section anchor="privacy" title="Privacy Considerations">
<t><xref target="RFC7626"></xref> discusses DNS privacy considerations
in both "on the wire" (Section 2.4 of <xref target="RFC7626"></xref>)
and "in the server" (Section 2.5 of <xref target="RFC7626"></xref>
contexts. The mechanism defined in <xref
target="I-D.reddy-add-server-policy-selection"></xref> 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. By evaluating the DNS privacy statement,
filtering policy and the signatory, the client can use the discovered
DNS server if it meets privacy preserving data policy and filtering
requirements of the user.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The bootstrapping procedure to obtain the certificate of the local
network's DNS server uses a client identity and password to authenticate
the EST server using PAKE schemes. Security considerations such as those
discussed in <xref target="I-D.barnes-tls-pake"></xref> or <xref
target="RFC8120"></xref> and <xref target="RFC8121"></xref> need to be
taken into consideration.</t>
<t>Users cannot be expected to enable or disable the bootstrapping or
the discovery procedure as they switch networks. Thus, it is RECOMMENDED
that users indicate to their system in some way that they desire
bootstrapping to be performed when connecting to a specific network,
similar to the way users disable VPN connection in specific network
(e.g., Enterprise network) and enable VPN connection by default in other
networks.</t>
<t>If an endpoint has enabled strict privacy profile, and the network
security service blocks the traffic to the privacy-enabling public DNS
server, a hard failure occurs and the user is notified. The user has a
choice to switch to another network or if the user trusts the network,
the user can enable strict privacy profile with the DoH/DoT server
discovered in the network instead of downgrading to opportunistic
privacy profile.</t>
<t>The primary attacks against the methods described in <xref
target="EST_Discovery"></xref> are the ones that would lead to
impersonation of a EST server and spoofing the DNS response to indicate
that the network does not support any EST server. To protect against
DNS-vectored attacks, secured DNS (DNSSEC) can be used to ensure the
validity of the DNS records received. Impersonation of the EST server is
prevented by authenticating the EST server using the PAKE scheme. The
PAKE scheme is only used once to configure the reference identifier of
the EST server and the server certificate is validated for subsequent
TLS connections to the EST server.</t>
<t>Security considerations in <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"></xref> need to be taken
into consideration for IoT devices.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="Service Name for EST">
<t>IANA is requested to allocate the following service name from the
registry available at: https://www.iana.org/assignments/service-
names-port-numbers/service-names-port-numbers.xhtml.</t>
<t><figure>
<artwork><![CDATA[ Service Name: est
Port Number: N/A
Transport Protocol(s): TCP
Description: Enrollment over Secure Transport (EST)
Assignee: IESG <[email protected]>
Contact: IETF Chair <[email protected]>
Reference: [ThisDocument]
]]></artwork>
</figure></t>
</section>
<section title="Service Name for DoH">
<t>IANA is requested to allocate the following service name from the
registry available at: https://www.iana.org/assignments/service-
names-port-numbers/service-names-port-numbers.xhtml.</t>
<t><figure>
<artwork><![CDATA[ Service Name: doh
Port Number: N/A
Transport Protocol(s): TCP
Description: DNS-over-HTTPS
Assignee: IESG <[email protected]>
Contact: IETF Chair <[email protected]>
Reference: [ThisDocument]
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick
McManus, Bob Harold, Livingood Jason, Winfield Alister, Eliot Lear,
Stephane Bortzmeyer, Ted Lemon and Sara Dickinson for the discussion and
comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.8174'?>
<?rfc include="reference.RFC.6125"?>
<?rfc include="reference.RFC.7030"?>
<?rfc include="reference.RFC.8295"?>
<?rfc include="reference.RFC.8484"?>
<?rfc include="reference.RFC.7858"?>
<?rfc include="reference.RFC.6763"?>
<?rfc include="reference.RFC.8499"?>
<?rfc include="reference.RFC.8121"?>
<?rfc include="reference.RFC.6762"?>
<?rfc include="reference.RFC.5280"?>
<?rfc include='reference.I-D.ietf-anima-bootstrapping-keyinfra'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.8310"?>
<?rfc include="reference.RFC.8120"?>
<?rfc include='reference.I-D.barnes-tls-pake'?>
<?rfc include='reference.I-D.reddy-add-server-policy-selection'?>
<?rfc include='reference.I-D.btw-add-rfc8484-clarification'?>
<?rfc include='reference.I-D.btw-add-home'?>
<?rfc include='reference.I-D.ietf-dnsop-terminology-ter'?>
<?rfc include='reference.I-D.arkko-farrell-arch-model-t' ?>
<?rfc include="reference.RFC.2775"?>
<?rfc include="reference.RFC.7871"?>
<?rfc include="reference.RFC.7626"?>
<?rfc include='reference.RFC.8520'?>
<?rfc include='reference.RFC.7671'?>
<?rfc include='reference.RFC.8146' ?>
<?rfc include='reference.RFC.4764' ?>
<reference anchor="CDN"
target="https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p167.pdf">
<front>
<title>End-User Mapping: Next Generation Request Routing for Content
Delivery</title>
<author>
<organization></organization>
</author>
<date year="2015" />
</front>
</reference>
<reference anchor="Evil-Twin"
target="https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)">
<front>
<title>Evil twin (wireless networks)</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="Krack" target="https://www.krackattacks.com/">
<front>
<title>Key Reinstallation Attacks</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="2017" />
</front>
</reference>
<reference anchor="Dragonblood"
target="https://papers.mathyvanhoef.com/dragonblood.pdf">
<front>
<title>Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and
EAP-pwd</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="PEAP"
target="https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9">
<front>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol
(PEAP)</title>
<author>
<organization>Microsoft</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="MDM-Apple"
target="https://developer.apple.com/documentation/devicemanagement">
<front>
<title>Mobile Device Management</title>
<author>
<organization>Apple</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="OTA"
target="https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html">
<front>
<title>Over-the-Air Profile Delivery Concepts</title>
<author>
<organization>Apple</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="Firefox-Policy"
target="https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps">
<front>
<title>Policy templates for Firefox</title>
<author></author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="Chrome-Policy"
target="https://support.google.com/chrome/a/answer/2657289?hl=en">
<front>
<title>Chrome policies for users or browsers</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="Chrome-DoH"
target="https://www.chromium.org/developers/dns-over-https">
<front>
<title>Chrome DNS over HTTPS (aka DoH)</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
</references>
</back>
</rfc>