-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ietf-netconf-zerotouch.xml
3137 lines (2876 loc) · 171 KB
/
draft-ietf-netconf-zerotouch.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
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc category="std"
ipr="trust200902"
docName="draft-ietf-netconf-zerotouch-latest">
<front>
<title abbrev="Secure Zero Touch Provisioning (SZTP)">Secure Zero Touch Provisioning (SZTP)</title>
<author initials="K.W." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="M.A." surname="Abrahamsson" fullname="Mikael Abrahamsson">
<organization>T-Systems</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="I.F." surname="Farrer" fullname="Ian Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>zerotouch</keyword>
<keyword>bootstrap</keyword>
<keyword>sztp</keyword>
<keyword>ztp</keyword>
<abstract>
<t>This draft presents a technique to securely provision a networking
device when it is booting in a factory-default state. Variations
in the solution enables it to be used on both public and private
networks. The provisioning steps are able to update the boot image,
commit an initial configuration, and execute arbitrary scripts to
address auxiliary needs. The updated device is subsequently able
to establish secure connections with other systems. For instance,
a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040)
connections with deployment-specific network management systems.</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other
RFC Editor instructions are specified elsewhere in this document.</t>
<t>Artwork in the IANA Considerations section contains placeholder
values for DHCP options pending IANA assignment. Please apply the
following replacements:
<list style="symbols">
<t><spanx style="verb">TBD1</spanx> --> the assigned value for id-ct-sztpConveyedInfoXML</t>
<t><spanx style="verb">TBD2</spanx> --> the assigned value for id-ct-sztpConveyedInfoJSON</t>
<t><spanx style="verb">TBD_IANA_URL</spanx> --> the assigned URL for the IANA registry</t>
</list>
</t>
<t>Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
<list style="symbols">
<t><spanx style="verb">XXXX</spanx> --> the assigned numerical RFC value for this draft</t>
</list>
</t>
<t>Artwork in this document contains placeholder values for the date of publication of this
draft. Please apply the following replacement:
<list style="symbols">
<t><spanx style="verb">YYYY-MM-DD</spanx> --> the publication date of this draft</t>
</list>
</t>
<t>The following one Appendix section is to be removed prior to publication:
<list style="symbols">
<t>Appendix D. Change Log</t>
</list>
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>A fundamental business requirement for any network operator is
to reduce costs where possible. For network operators, deploying
devices to many locations can be a significant cost, as sending
trained specialists to each site for installations is both cost
prohibitive and does not scale.</t>
<t>This document defines Secure Zero Touch Provisioning (SZTP),
a bootstrapping strategy enabling devices to securely obtain
bootstrapping data with no installer action beyond physical
placement and connecting network and power cables. As such,
SZTP enables non-technical personnel to bring up devices in
remote locations without the need for any operator input.</t>
<t>The SZTP solution includes updating the boot image,
committing an initial configuration, and executing arbitrary scripts to
address auxiliary needs. The updated device is subsequently able to
establish secure connections with other systems. For instance, a
devices may establish NETCONF <xref target="RFC8040"/> and/or RESTCONF
<xref target="RFC6241"/> connections with deployment-specific network
management systems.</t>
<t>This document primarily regards physical devices, where the setting
of the device's initial state, described in <xref target="initial-state"/>,
occurs during the device's manufacturing process. The SZTP solution
may be extended to support virtual machines or other such logical
constructs, but details for how this can be accomplished is left
for future work.</t>
<section title="Use Cases" anchor="use-cases">
<t>
<list style="symbols">
<t>Device connecting to a remotely administered network
<list style="empty">
<t>This use-case involves scenarios, such as a remote branch office
or convenience store, whereby a device connects as an access gateway
to an ISP's network. Assuming it is not possible to customize the
ISP's network to provide any bootstrapping support, and with no other
nearby device to leverage, the device has no recourse but to reach
out to an Internet-based bootstrap server to bootstrap from.</t>
</list>
</t>
<t>Device connecting to a locally administered network
<list style="empty">
<t>This use-case covers all other scenarios and differs only in that
the device may additionally leverage nearby devices, which may direct
it to use a local service to bootstrap from. If no such information
is available, or the device is unable to use the information provided,
it can then reach out to the network just as it would for the remotely
administered network use-case.</t>
</list>
</t>
</list>
</t>
<t>Conceptual workflows for how SZTP might be deployed are
provided in <xref target="workflow-overview"/>.</t>
</section>
<section title="Terminology" anchor="terminology">
<t>This document uses the following terms (sorted by name):
<list style="hanging" hangIndent="4">
<t hangText="Artifact:">The term "artifact" is used throughout to represent
any of the three artifacts defined in <xref target="artifacts"/> (conveyed
information, ownership voucher, and owner certificate). These artifacts
collectively provide all the bootstrapping data a device may use.</t>
<t hangText="Bootstrapping Data:">The term "bootstrapping data" is used
throughout this document to refer to the collection of data that a device
may obtain during the bootstrapping process. Specifically, it refers
to the three artifacts conveyed information, owner certificate, and
ownership voucher, as described in <xref target="artifacts"/>. </t>
<t hangText="Bootstrap Server:">The term "bootstrap server" is used within
this document to mean any RESTCONF server implementing the YANG module
defined in <xref target="yang-module"/>.</t>
<t hangText="Conveyed Information:">The term "conveyed information" is used
herein to refer either redirect information or onboarding information.
Conveyed information is one of the three bootstrapping artifacts described in
<xref target="artifacts"/>.</t>
<t hangText="Device:">The term "device" is used throughout this document
to refer to a network element that needs to be bootstrapped. See
<xref target="device-details"/> for more information about devices.</t>
<t hangText="Manufacturer:">The term "manufacturer" is used herein to
refer to the manufacturer of a device or a delegate of the manufacturer.</t>
<t hangText="Network Management System (NMS):">The acronym "NMS" is used
throughout this document to refer to the deployment-specific management
system that the bootstrapping process is responsible for introducing devices to.
From a device's perspective, when the bootstrapping process has completed,
the NMS is a NETCONF or RESTCONF client.</t>
<t hangText="Onboarding Information:">The term "onboarding information" is used
herein to refer to one of the two types of "conveyed information"
defined in this document, the other being "redirect information". Onboarding
information is formally defined by the "onboarding-information" YANG-data
structure in <xref target="info-yang-module"/>.</t>
<t hangText="Onboarding Server:">The term "onboarding server" is used
herein to refer to a bootstrap server that only returns onboarding
information.</t>
<t hangText="Owner:">The term "owner" is used throughout this document
to refer to the person or organization that purchased or otherwise owns
a device.</t>
<t hangText="Owner Certificate:">The term "owner certificate" is used in
this document to represent an X.509 certificate that binds an owner identity
to a public key, which a device can use to validate a signature over the
conveyed information artifact. The owner certificate may be communicated
along with its chain of intermediate certificates leading up to a known
trust anchor. The owner certificate is one of the three bootstrapping
artifacts described in <xref target="artifacts"/>.</t>
<t hangText="Ownership Voucher:">The term "ownership voucher" is used in
this document to represent the voucher artifact defined in <xref
target="RFC8366"/>. The ownership voucher is used to
assign a device to an owner. The ownership voucher is one of
the three bootstrapping artifacts described in <xref target="artifacts"/>.</t>
<t hangText="Redirect Information:">The term "redirect information" is used
herein to refer to one of the two types of "conveyed information"
defined in this document, the other being "onboarding information". Redirect
information is formally defined by the "redirect-information" YANG-data
structure in <xref target="info-yang-module"/>.</t>
<t hangText="Redirect Server:">The term "redirect server" is used to refer
to a bootstrap server that only returns redirect information. A redirect
server is particularly useful when hosted by a manufacturer, as a
well-known (e.g., Internet-based) resource to redirect devices to
deployment-specific bootstrap servers.</t>
<t hangText="Signed Data:">The term "signed data" is used throughout to mean
conveyed information that has been signed, specifically by a private key
possessed by a device's owner.</t>
<t hangText="Unsigned Data:">The term "unsigned data" is used throughout to mean
conveyed information that has not been signed.</t>
</list>
</t>
</section>
<section title="Requirements Language" anchor="requirements-language">
<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 target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section title="Tree Diagrams">
<t>Tree diagrams used in this document follow the notation
defined in <xref target="RFC8340"/>.</t>
</section>
</section> <!-- end Introduction -->
<section title="Types of Conveyed Information" anchor="types-of-information">
<t>This document defines two types of conveyed information that devices can access during
the bootstrapping process. These conveyed information types are described in
this section. Examples are provided in <xref target="zt-info-data-model-examples"/></t>
<section title="Redirect Information" anchor="redirect-information">
<t>Redirect information redirects a device to
another bootstrap server. Redirect information encodes a list of bootstrap
servers, each specifying the bootstrap server's hostname (or IP address),
an optional port, and an optional trust anchor certificate that the device
can use to authenticate the bootstrap server with.</t>
<t>Redirect information is YANG modeled data formally defined by the
"redirect-information" container in the YANG module presented in
<xref target="info-yang-module"/>. This container has the tree
diagram shown below.</t>
<t><figure>
<artwork name="redirect-information-tree.txt" align="center"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/redirect-information-tree.txt)
]]></artwork>
</figure></t>
<t>Redirect information may be trusted or untrusted. The redirect information
is trusted whenever it is obtained via a secure connection to a trusted bootstrap
server, or whenever it is signed by the device's owner. In all other
cases, the redirect information is untrusted.</t>
<t>Trusted redirect information is useful for enabling a device to establish
a secure connection to a specified bootstrap server, which is possible when the redirect
information includes the bootstrap server's trust anchor certificate.</t>
<t>Untrusted redirect information is useful for directing a device to a bootstrap
server where signed data has been staged for it to obtain. Note that, when the
redirect information is untrusted, devices discard any potentially included trust
anchor certificates.</t>
<t>How devices process redirect information is described in
<xref target="process-redirect-information"/>.</t>
</section>
<section title="Onboarding Information" anchor="onboarding-information">
<t>Onboarding information provides data necessary for a device
to bootstrap itself and establish secure connections with other
systems. As defined in this document, onboarding information can
specify details about the boot image a device must be running,
specify an initial configuration the device must commit, and
specify scripts that the device must successfully execute.</t>
<t>Onboarding information is YANG modeled data formally defined by the
"onboarding-information" container in the YANG module presented in
<xref target="info-yang-module"/>. This container has the tree diagram
shown below.</t>
<t><figure>
<artwork name="onboarding-information-tree.txt" align="center"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/onboarding-information-tree.txt)
]]></artwork>
</figure></t>
<t>Onboarding information must be trusted for it to be of any use to a device.
There is no option for a device to process untrusted onboarding information.</t>
<t>Onboarding information is trusted whenever it is obtained via a secure connection
to a trusted bootstrap server, or whenever it is signed by the device's
owner. In all other cases, the onboarding information is untrusted.</t>
<t>How devices process onboarding information is described in
<xref target="process-onboarding-information"/>.</t>
</section>
</section>
<section title="Artifacts" anchor="artifacts">
<t>This document defines three artifacts that can be made available
to devices while they are bootstrapping. Each source of bootstrapping
data specifies how it provides the artifacts defined in this section
(see <xref target="sources"/>).</t>
<section title="Conveyed Information" anchor="conveyed-information">
<t>The conveyed information artifact encodes the essential bootstrapping
data for the device. This artifact is used to encode the redirect
information and onboarding information types discussed in <xref
target="types-of-information"/>.</t>
<t>The conveyed information artifact is a CMS structure, as described
in <xref target="RFC5652"/>, encoded using ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690 <xref target="ITU.X690.2015"/>.
The CMS structure MUST contain content conforming to the
YANG module specified in <xref target="info-yang-module"/>.</t>
<t>The conveyed information CMS structure may encode signed or
unsigned bootstrapping data. When the bootstrapping data is signed,
it may also be encrypted but, from a terminology perspective, it
is still "signed data" <xref target="terminology"/>.</t>
<t>When the conveyed information artifact is unsigned, as it might
be when communicated over trusted channels, the CMS structure's
top-most content type MUST be one of the OIDs described in
<xref target="cms_cts"/> (i.e., id-ct-sztpConveyedInfoXML or
id-ct-sztpConveyedInfoJSON), or the OID id-data (1.2.840.113549.1.7.1).
When the OID id-data is used, the encoding (JSON, XML, etc.)
SHOULD be communicated externally. In either case, the associated
content is an octet string containing "conveyed-information"
data in the expected encoding.</t>
<t>When the conveyed information artifact is unsigned and
encrypted, as it might be when communicated over trusted
channels but, for some reason, the operator wants to ensure
that only the device is able to see the contents, the CMS
structure's top-most content type MUST be the OID id-envelopedData
(1.2.840.113549.1.7.3). Furthermore, the encryptedContentInfo's
content type MUST be one of the OIDs described in
<xref target="cms_cts"/> (i.e., id-ct-sztpConveyedInfoXML
or id-ct-sztpConveyedInfoJSON), or the OID id-data
(1.2.840.113549.1.7.1). When the OID id-data is used,
the encoding (JSON, XML, etc.) SHOULD be communicated
externally. In either case, the associated content is
an octet string containing "conveyed-information" data
in the expected encoding.</t>
<t>When the conveyed information artifact is signed, as it might
be when communicated over untrusted channels, the CMS structure's
top-most content type MUST be the OID id-signedData (1.2.840.113549.1.7.2).
Furthermore, the inner eContentType MUST be one of the OIDs described in
<xref target="cms_cts"/> (i.e., id-ct-sztpConveyedInfoXML or
id-ct-sztpConveyedInfoJSON), or the OID id-data (1.2.840.113549.1.7.1).
When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD
be communicated externally. In either case, the associated content
or eContent is an octet string containing "conveyed-information"
data in the expected encoding.</t>
<t>When the conveyed information artifact is signed and encrypted,
as it might be when communicated over untrusted channels and
privacy is important, the CMS structure's top-most content type
MUST be the OID id-envelopedData (1.2.840.113549.1.7.3). Furthermore,
the encryptedContentInfo's content type MUST be the OID id-signedData
(1.2.840.113549.1.7.2), whose eContentType MUST be one of the OIDs
described in <xref target="cms_cts"/> (i.e., id-ct-sztpConveyedInfoXML
or id-ct-sztpConveyedInfoJSON), or the OID id-data
(1.2.840.113549.1.7.1). When the OID id-data is used, the encoding
(JSON, XML, etc.) SHOULD be communicated externally. In either case,
the associated content or eContent is an octet string containing
"conveyed-information" data in the expected encoding.</t>
</section>
<section title="Owner Certificate" anchor="owner-certificate">
<t>The owner certificate artifact is an X.509 certificate
<xref target="RFC5280"/> that is used to identify an "owner" (e.g.,
an organization). The owner certificate can be signed by any
certificate authority (CA). The owner certificate either MUST have
no Key Usage specified or the Key Usage MUST at least set the
"digitalSignature" bit. The values for the owner certificate's
"subject" and/or "subjectAltName" are not constrained by this
document.</t>
<t>The owner certificate is used by a device to verify the signature over
the conveyed information artifact (<xref target="conveyed-information"/>)
that the device should have also received, as described in
<xref target="artifact-groupings"/>. In particular, the device
verifies the signature using the public key in the owner certificate
over the content contained within the conveyed information artifact.</t>
<t>The owner certificate artifact is formally a CMS structure, as
specified by <xref target="RFC5652"/>, encoded using ASN.1
distinguished encoding rules (DER), as specified in ITU-T X.690
<xref target="ITU.X690.2015"/>.</t>
<t>The owner certificate CMS structure MUST contain the owner
certificate itself, as well as all intermediate certificates leading
to the "pinned-domain-cert" certificate specified in the ownership
voucher. The owner certificate artifact MAY optionally include the
"pinned-domain-cert" as well.</t>
<t>In order to support devices deployed on private networks,
the owner certificate CMS structure MAY also contain suitably fresh,
as determined by local policy, revocation objects (e.g., CRLs).
Having these revocation objects stapled to the owner certificate may
obviate the need for the device to have to download them dynamically
using the CRL distribution point or an OCSP responder specified in
the associated certificates.</t>
<t>When unencrypted, the owner certificate artifact's CMS structure's
top-most content type MUST be the OID id-signedData (1.2.840.113549.1.7.2).
The inner SignedData structure is the degenerate form, whereby there
are no signers, that is commonly used to disseminate certificates and
revocation objects.</t>
<t>When encrypted, the owner certificate artifact's CMS structure's
top-most content type MUST be the OID id-envelopedData
(1.2.840.113549.1.7.3), and the encryptedContentInfo's content type
MUST be the OID id-signedData (1.2.840.113549.1.7.2), whereby the
inner SignedData structure is the degenerate form that has no signers
commonly used to disseminate certificates and revocation objects.</t>
</section>
<section title="Ownership Voucher" anchor="ownership-voucher">
<t>The ownership voucher artifact is used to securely identify a device's
owner, as it is known to the manufacturer. The ownership voucher is signed
by the device's manufacturer.</t>
<t>The ownership voucher is used to verify the owner certificate
(<xref target="owner-certificate"/>) that the device should have also
received, as described in <xref target="artifact-groupings"/>. In
particular, the device verifies that the owner certificate has a chain
of trust leading to the trusted certificate included in the ownership
voucher ("pinned-domain-cert"). Note that this relationship holds
even when the owner certificate is a self-signed certificate, and
hence also the pinned-domain-cert.</t>
<t>When unencrypted, the ownership voucher artifact is as defined
in <xref target="RFC8366"/>. As described, it is
a CMS structure whose top-most content type MUST be the OID
id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST
be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1), or the
OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used,
the encoding (JSON, XML, etc.) SHOULD be communicated externally.
In either case, the associated content is an octet string
containing ietf-voucher data in the expected encoding.</t>
<t>When encrypted, the ownership voucher artifact's CMS structure's
top-most content type MUST be the OID id-envelopedData
(1.2.840.113549.1.7.3), and the encryptedContentInfo's content type
MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType
MUST be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1), or the OID
id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the
encoding (JSON, XML, etc.) SHOULD be communicated externally. In
either case, the associated content is an octet string containing
ietf-voucher data in the expected encoding.</t>
</section>
<section title="Artifact Encryption" anchor="artifact-encryption">
<t>Each of the three artifacts MAY be individually encrypted. Encryption
may be important in some environments where the content is considered
sensitive.</t>
<t>Each of the three artifacts are encrypted in the same way, by the
unencrypted form being encapsulated inside a CMS EnvelopedData type.</t>
<t>As a consequence, both the conveyed information and ownership
voucher artifacts are signed and then encrypted, never encrypted
and then signed.</t>
<t>This sequencing has the advantage of shrouding the signer's
certificate, and ensuring that the owner knows the content being
signed. This sequencing further enables the owner to inspect an
unencrypted voucher obtained from a manufacturer and then encrypt
the voucher later themselves, perhaps while also stapling in
current revocation objects, when ready to place the artifact
in an unsafe location.</t>
<t>When encrypted, the CMS MUST be encrypted using a secure device
identity certificate for the device. This certificate MAY be the
same as the TLS-level client certificate the device uses when
connecting to bootstrap servers. The owner must possess the
device's identity certificate at the time of encrypting the data.
How the owner comes to posses the device's identity certificate
for this purpose is outside the scope of this document.</t>
</section>
<section title="Artifact Groupings" anchor="artifact-groupings">
<t>The previous sections discussed the bootstrapping artifacts,
but only certain groupings of these artifacts make sense to return in the
various bootstrapping situations described in this document. These groupings
are:
<list style="hanging" hangIndent="6">
<t hangText=" Unsigned Data:">This artifact grouping is useful for cases
when transport level security can be used to convey trust (e.g., HTTPS),
or when the conveyed information can be processed in a provisional manner (i.e.
unsigned redirect information).</t>
<t hangText=" Signed Data, without revocations:">This artifact grouping
is useful when signed data is needed (i.e., because the data is obtained
from an untrusted source and it cannot be processed provisionally)
and either revocations are not needed or the revocations can be obtained
dynamically.</t>
<t hangText=" Signed Data, with revocations:">This artifact grouping
is useful when signed data is needed (i.e., because the data is obtained
from an untrusted source and it cannot be processed provisionally), and
revocations are needed, and the revocations cannot be obtained dynamically.</t>
</list>
</t>
<t>The presence of each artifact, and any distinguishing characteristics, are identified
for each artifact grouping in the table below ("yes/no" regards if the
artifact is present in the artifact grouping):
<figure>
<artwork align="center"><![CDATA[
+---------------------+---------------+--------------+--------------+
| Artifact | Conveyed | Ownership | Owner |
| Grouping | Information | Voucher | Certificate |
+=====================+===============+==============+==============+
| Unsigned Data | Yes, no sig | No | No |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, without | Yes, without |
| without revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, with | Yes, with |
| with revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Sources of Bootstrapping Data" anchor="sources">
<t>This section defines some sources for bootstrapping data that a device
can access. The list of sources defined here is not meant to be exhaustive.
It is left to future documents to define additional sources for obtaining
bootstrapping data.</t>
<t>For each source of bootstrapping data defined in this section, details
are given for how the three artifacts listed in <xref target="artifacts"/>
are provided.</t>
<section title="Removable Storage" anchor="removable-storage">
<t>A directly attached removable storage device (e.g., a USB flash drive)
MAY be used as a source of SZTP bootstrapping data.</t>
<t>Use of a removable storage device is compelling, as it does not require
any external infrastructure to work. It is notable that the raw boot
image file can also be located on the removable storage device, enabling
a removable storage device to be a fully self-standing bootstrapping
solution.</t>
<t>To use a removable storage device as a source of bootstrapping data,
a device need only detect if the removable storage device is plugged in
and mount its filesystem.</t>
<t>A removable storage device is an untrusted source of bootstrapping data.
This means that the information stored on the removable storage device
either MUST be signed or MUST be information that can be processed
provisionally (e.g., unsigned redirect information).</t>
<t>From an artifact perspective, since a removable storage device presents
itself as a filesystem, the bootstrapping artifacts need to be presented
as files. The three artifacts defined in <xref target="artifacts"/> are
mapped to files below.</t>
<t>Artifact to File Mapping:
<list style="hanging" hangIndent="6">
<t hangText=" Conveyed Information:">Mapped to a file containing
the binary artifact described in <xref target="conveyed-information"/>
(e.g., conveyed-information.cms).</t>
<t hangText=" Owner Certificate:">Mapped to a file containing the
binary artifact described in <xref target="owner-certificate"/>
(e.g., owner-certificate.cms).</t>
<t hangText=" Ownership Voucher:">Mapped to a file containing the
binary artifact described in <xref target="ownership-voucher"/>
(e.g., ownership-voucher.cms or ownership-voucher.vcj).</t>
</list>
</t>
<t>The format of the removable storage device's filesystem and the naming of the
files are outside the scope of this document. However, in order to facilitate
interoperability, it is RECOMMENDED devices support open and/or standards based
filesystems. It is also RECOMMENDED that devices assume a file naming convention
that enables more than one instance of bootstrapping data (i.e., for different
devices) to exist on a removable storage device. The file naming convention
SHOULD additionally be unique to the manufacturer, in order to enable bootstrapping
data from multiple manufacturers to exist on a removable storage device.</t>
</section>
<section title="DNS Server" anchor="dns-server">
<t>A DNS server MAY be used as a source of SZTP bootstrapping data.</t>
<t>Using a DNS server may be a compelling option for deployments having
existing DNS infrastructure, as it enables a touchless bootstrapping option
that does not entail utilizing an Internet based resource hosted by a
3rd-party.</t>
<t>DNS is an untrusted source of bootstrapping data. Even if DNSSEC
<xref target="RFC6698"/> is used to authenticate the various DNS resource
records (e.g., A, AAAA, CERT, TXT, and TLSA), the device cannot be
sure that the domain returned to it from e.g., a DHCP server, belongs
to its rightful owner. This means that the information stored in the
DNS records either MUST be signed (per this document, not DNSSEC), or
MUST be information that can be processed provisionally (e.g., unsigned
redirect information).</t>
<section title="DNS Queries" toc="exclude">
<t>Devices claiming to support DNS as a source of bootstrapping
data MUST first query for device-specific DNS records and, only
if doing so does not result in a successful bootstrap, then MUST
query for device-independent DNS records.</t>
<t>For each of the device-specific and device-independent queries,
devices MUST first query using multicast DNS <xref target="RFC6762"/>
and, only if doing so does not result in a successful bootstrap,
then MUST query again using unicast DNS <xref target="RFC1035"/>
<xref target="RFC7766"/>, assuming the address of a DNS server
is known, such as it may using techniques similar to those
described in Section 11 of <xref target="RFC6763"/>, which is
referenced a few times in this document, even though this
document does not itself use DNS-SD (RFC 6763 is identified
herein as an Informative reference).</t>
<t>When querying for device-specific DNS records, devices
MUST query for TXT records <xref target="RFC1035"/> under
"<serial-number>._sztp", where <serial-number>
is the device's serial number (the same value as in the
device's secure device identity certificate), and "_sztp"
is the globally scoped DNS attribute registered by this
document in <xref target="_sztp_attr"/>.</t>
<t>Example device-specific DNS record queries:
<?rfc subcompact="yes"?>
<list style="empty">
<t>TXT in <serial-number>._sztp.local. (multicast)</t>
<t>TXT in <serial-number>._sztp.<domain>. (unicast)</t>
</list>
<?rfc subcompact="no"?>
</t>
<t>When querying for device-independent DNS records, devices MUST
query for SRV records <xref target="RFC2782"/> under "_sztp._tcp",
where "_sztp" is the service name registered by this document in
<xref target="dns_srv"/>, and "_tcp" is the globally scoped DNS
attribute registered by <xref target="I-D.ietf-dnsop-attrleaf"/>.</t>
<t>Note that a device-independent response is anyway only able to
encode unsigned data, since signed data necessitates the use of a
device-specific ownership voucher. Use of SRV records leverages
existing DNS standards. A response containing multiple SRV
records is comparable to an unsigned redirect information's list
of bootstrap servers.</t>
<t>Example device-independent DNS record queries:
<?rfc subcompact="yes"?>
<list style="empty">
<t>SRV in _sztp._tcp.local. (multicast)</t>
<t>SRV in _sztp._tcp.<domain>. (unicast)</t>
</list>
<?rfc subcompact="no"?>
</t>
</section>
<section title="DNS Response for Device-Specific Queries" toc="exclude">
<t>For device-specific queries, the three bootstrapping artifacts defined
in <xref target="artifacts"/> are encoded into the TXT records using
key/value pairs, similar to the technique described in Section 6.3
of <xref target="RFC6763"/>.</t>
<t>Artifact to TXT Record Mapping:
<list style="hanging" hangIndent="6">
<t hangText=" Conveyed Information:">Mapped to a TXT record
having the key "ci" and the value being the binary
artifact described in <xref target="conveyed-information"/>.</t>
<t hangText=" Owner Certificate:">Mapped to a TXT record
having the key "oc" and the value being the binary
artifact described in <xref target="owner-certificate"/>.</t>
<t hangText=" Ownership Voucher:">Mapped to a TXT record
having the key "ov" and the value being the binary
artifact described in <xref target="ownership-voucher"/>.</t>
</list>
</t>
<t>Devices MUST ignore any other keys that may be returned.</t>
<t>Note that, despite the name, TXT records can and SHOULD (per
Section 6.5 of <xref target="RFC6763"/>) encode binary data.</t>
<t>Following is an example of a device-specific response, as
it might be presented by a user-agent, containing signed data.
This example assumes that the device's serial number is
"<serial-number>", the domain is "example.com", and
that "<binary data>" represents the binary artifact:
<figure>
<artwork align="center"><![CDATA[
<serial-number>._sztp.example.com. 3600 IN TXT "ci=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "oc=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "ov=<binary data>"
]]></artwork>
</figure>
</t>
<t>Note that, in the case that "ci" encodes unsigned data,
the "oc" and "ov" keys would not be present in the response.</t>
</section>
<section title="DNS Response for Device-Independent Queries" toc="exclude">
<t>For device-independent queries, the three bootstrapping
artifacts defined in <xref target="artifacts"/> are encoded
into the SVR records as follows.</t>
<t>Artifact to SRV Record Mapping:
<list style="hanging" hangIndent="6">
<t hangText=" Conveyed Information:">This artifact is not supported
directly. Instead, the essence of unsigned redirect information is
mapped to SVR records per <xref target="RFC2782"/>.</t>
<t hangText=" Owner Certificate:">Not supported. Device-independent
responses are never encode signed data, and hence there is no need for
an owner certificate artifact.</t>
<t hangText=" Ownership Voucher:">Not supported. Device-independent
responses are never encode signed data, and hence there is no need for
an ownership voucher artifact.</t>
</list>
</t>
<t>Following is an example of a device-independent response, as
it might be presented by a user-agent, containing (effectively)
unsigned redirect information to four bootstrap servers. This
example assumes that the domain is "example.com" and that there
are four bootstrap servers "sztp[1-4]":
<figure>
<artwork align="center">
_sztp._tcp.example.com. 1800 IN SRV 0 0 443 sztp1.example.com.
_sztp._tcp.example.com. 1800 IN SRV 1 0 443 sztp2.example.com.
_sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp3.example.com.
_sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp4.example.com.
</artwork>
</figure>
</t>
<t>Note that, in this example, "sztp3" and "sztp4" have equal
priority, and hence effectively represent a clustered pair
of bootstrap servers. While "sztp1" and "sztp2" only have
a single SRV record each, it may be that the record points
to a load-balancer fronting a cluster of bootstrap servers.</t>
<t>While this document does not use DNS-SD <xref target="RFC6763"/>,
per Section 12.2 of that RFC, mDNS responses SHOULD also include
all address records (type "A" and "AAAA") named in the SRV rdata.</t>
</section>
<section title="Size of Signed Data" toc="exclude">
<t>The signed data artifacts are large by DNS conventions. In the
smallest-footprint scenario, they are each a few kilobytes in size.
However, onboarding information can easily be several kilobytes in
size, and has the potential to be many kilobytes in size.</t>
<t>All resource records, including TXT records, have an upper
size limit of 65535 bytes, since "RDLENGTH" is a 16-bit field
(Section 3.2.1 in <xref target="RFC1035"/>). If it is ever
desired to encode onboarding information that exceeds this
limit, the DNS records returned should instead encode redirect
information, to direct the device to a bootstrap server from
which the onboarding information can be obtained.</t>
<t>Given the expected size of the TXT records, it is unlikely
that signed data will fit into a UDP-based DNS packet, even
with the EDNS(0) Extensions <xref target="RFC6891"/> enabled.
Depending on content, signed data may also not fit into a
multicast DNS packet, which bounds the size to 9000 bytes,
per Section 17 in <xref target="RFC6762"/>. Thus it is
expected that DNS Transport over TCP <xref target="RFC7766"/>
will be required in order to return signed data.</t>
</section>
</section> <!-- end DNS Server -->
<section title="DHCP Server" anchor="dhcp-server">
<t>A DHCP server MAY be used as a source of SZTP bootstrapping data.</t>
<t>Using a DHCP server may be a compelling option for deployments having
existing DHCP infrastructure, as it enables a touchless bootstrapping option
that does not entail utilizing an Internet based resource hosted by a
3rd-party.</t>
<t>A DHCP server is an untrusted source of bootstrapping data. Thus the
information stored on the DHCP server either MUST be signed, or it MUST
be information that can be processed provisionally (e.g., unsigned redirect
information).</t>
<t>However, unlike other sources of bootstrapping data described
in this document, the DHCP protocol (especially DHCP for IPv4) is very
limited in the amount of data that can be conveyed, to the extent that
signed data cannot be communicated. This means that only unsigned
redirect information can be conveyed via DHCP.</t>
<t>Since the redirect information is unsigned, it SHOULD NOT include the
optional trust anchor certificate, as it takes up space in the DHCP
message, and the device would have to discard it anyway. For this
reason, the DHCP options defined in <xref target="dhcp-options"/> do
not enable the trust anchor certificate to be encoded.</t>
<t>From an artifact perspective, the three artifacts defined in
<xref target="artifacts"/> are mapped to the DHCP fields specified in
<xref target="dhcp-options"/> as follows.</t>
<t>Artifact to DHCP Option Fields Mapping:
<list style="hanging" hangIndent="6">
<t hangText=" Conveyed Information:">This artifact is not supported
directly. Instead, the essence of unsigned redirect information is
mapped to the DHCP options described in <xref target="dhcp-options"/>.</t>
<t hangText=" Owner Certificate:">Not supported. There is not enough
space in the DHCP packet to hold an owner certificate artifact.</t>
<t hangText=" Ownership Voucher:">Not supported. There is not enough
space in the DHCP packet to hold an ownership voucher artifact.</t>
</list>
</t>
</section>
<section title="Bootstrap Server" anchor="bootstrap-server">
<t>A bootstrap server MAY be used as a source of SZTP bootstrapping data.
A bootstrap server is defined as a RESTCONF <xref target="RFC8040"/>
server implementing the YANG module provided in <xref target="api"/>.</t>
<t>Using a bootstrap server as a source of bootstrapping data is a compelling
option as it MAY use transport-level security, obviating the need for signed
data, which may be easier to deploy in some situations.</t>
<t>Unlike any other source of bootstrapping data described in this document,
a bootstrap server is not only a source of data, but it can also receive data
from devices using the YANG-defined "report-progress" RPC defined in the YANG
module (<xref target="yang-module"/>). The "report-progress" RPC enables
visibility into the bootstrapping process (e.g., warnings and errors), and
provides potentially useful information upon completion (e.g., the device's
SSH host-keys).</t>
<t>A bootstrap server may be a trusted or an untrusted source of bootstrapping
data, depending on if the device learned about the bootstrap server's trust
anchor from a trusted source. When a bootstrap server is trusted, the
conveyed information returned from it MAY be signed. When the bootstrap server is
untrusted, the conveyed information either MUST be signed or MUST be information
that can be processed provisionally (e.g., unsigned redirect information).</t>
<t>From an artifact perspective, since a bootstrap server presents data
conforming to a YANG data model, the bootstrapping artifacts need to be
mapped to YANG nodes. The three artifacts defined in <xref target="artifacts"/>
are mapped to "output" nodes of the "get-bootstrapping-data" RPC defined
in <xref target="yang-module"/> below.</t>
<t>Artifact to Bootstrap Server Mapping:
<list style="hanging" hangIndent="6">
<t hangText=" Conveyed Information:">Mapped to the "conveyed-information"
leaf in the output of the "get-bootstrapping-data" RPC.</t>
<t hangText=" Owner Certificate:">Mapped to the "owner-certificate"
leaf in the output of the "get-bootstrapping-data" RPC.</t>
<t hangText=" Ownership Voucher:">Mapped to the "ownership-voucher"
leaf in the output of the "get-bootstrapping-data" RPC.</t>
</list>
</t>
<t>SZTP bootstrap servers have only two endpoints, one for the
"get-bootstrapping-data" RPC and one for the "report-progress" RPC.
These RPCs use the authenticated RESTCONF username to isolate the
execution of the RPC from other devices.</t>
</section> <!-- end bootstrap server -->
</section>
<section title="Device Details" anchor="device-details">
<t>Devices supporting the bootstrapping strategy described in this
document MUST have the preconfigured state and bootstrapping logic
described in the following sections.</t>
<section title="Initial State" anchor="initial-state">
<figure>
<artwork align="center"><![CDATA[
+-------------------------------------------------------------+
| <device> |
| |
| +---------------------------------------------------------+ |
| | <read/write storage> | |
| | | |
| | 1. flag to enable SZTP bootstrapping set to "true" | |
| +---------------------------------------------------------+ |
| |
| +---------------------------------------------------------+ |
| | <read-only storage> | |
| | | |
| | 2. TLS client cert & related intermediate certificates | |
| | 3. list of trusted well-known bootstrap servers | |
| | 4. list of trust anchor certs for bootstrap servers | |
| | 5. list of trust anchor certs for ownership vouchers | |
| +---------------------------------------------------------+ |
| |
| +-----------------------------------------------------+ |
| | <secure storage> | |
| | | |
| | 6. private key for TLS client certificate | |
| | 7. private key for decrypting SZTP artifacts | |
| +-----------------------------------------------------+ |
| |
+-------------------------------------------------------------+
]]></artwork>
</figure>
<t>Each numbered item below corresponds to a numbered item in the diagram above.
<list style="numbers">
<t>Devices MUST have a configurable variable that is used to enable/disable
SZTP bootstrapping. This variable MUST be enabled by default in
order for SZTP bootstrapping to run when the device first powers on.
Because it is a goal that the configuration installed by the bootstrapping
process disables SZTP bootstrapping, and because the
configuration may be merged into the existing configuration, using a
configuration node that relies on presence is NOT RECOMMENDED, as it
cannot be removed by the merging process.</t>
<t>Devices that support loading bootstrapping data from bootstrap servers
(see <xref target="bootstrap-server"/>) SHOULD possess a TLS-level client
certificate and any intermediate certificates leading to the certificate's
well-known trust-anchor. The well-known trust anchor certificate may
be an intermediate certificate or a self-signed root certificate. To
support devices not having a client certificate, devices MAY, alternatively
or in addition to, identify and authenticate themselves to the bootstrap
server using an HTTP authentication scheme, as allowed by Section 2.5 in
<xref target="RFC8040"/>; however, this document does not define a
mechanism for operator input enabling, for example, the entering of
a password.</t>
<t>Devices that support loading bootstrapping data from well-known
bootstrap servers MUST possess a list of the well-known bootstrap servers.
Consistent with redirect information (<xref target="redirect-information"/>,
each bootstrap server can be identified by its hostname or IP address, and
an optional port.</t>
<t>Devices that support loading bootstrapping data from well-known
bootstrap servers MUST also possess a list of trust anchor certificates
that can be used to authenticate the well-known bootstrap servers. For
each trust anchor certificate, if it is not itself a self-signed root
certificate, the device SHOULD also possess the chain of intermediate
certificates leading up to and including the self-signed root certificate.</t>
<t>Devices that support loading signed data (see <xref target="terminology"/>)
MUST possess the trust anchor certificates for validating ownership vouchers.
For each trust anchor certificate, if it is not itself a self-signed
root certificate, the device SHOULD also possess the chain of intermediate
certificates leading up to and including the self-signed root certificate.</t>
<t>Devices that support using a TLS-level client certificate to identify
and authenticate themselves to a bootstrap server MUST possess the
private key that corresponds to the public key encoded in the TLS-level
client certificate. This private key SHOULD be securely stored, ideally
in a cryptographic processor, such as a trusted platform module (TPM)
chip.</t>
<t>Devices that support decrypting SZTP artifacts MUST posses the
private key that corresponds to the public key encoded in the secure
device identity certificate used when encrypting the artifacts. This
private key SHOULD be securely stored, ideally in a cryptographic
processor, such as a trusted platform module (TPM) chip. This private
key MAY be the same as the one associated to the TLS-level client
certificate used when connecting to bootstrap servers.</t>
</list>
</t>