-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-netconf-sztp-csr.xml
824 lines (785 loc) · 41.4 KB
/
draft-ietf-netconf-sztp-csr.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
<?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 xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
consensus="true"
ipr="trust200902"
docName="draft-ietf-netconf-sztp-csr-latest"
updates="8572">
<front>
<title abbrev="Conveying a CSR in an SZTP Request">Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization>Watsen Networks</organization>
<address>
<email>kent+ietf@watsen.net</email>
</address>
</author>
<author initials="R." surname="Housley" fullname="Russ Housley">
<organization>Vigil Security, LLC</organization>
<address>
<email>housley@vigilsec.com</email>
</address>
</author>
<author initials="S." surname="Turner" fullname="Sean Turner">
<organization>sn3rd</organization>
<address>
<email>sean@sn3rd.com</email>
</address>
</author>
<date/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>zerotouch</keyword>
<keyword>bootstrap</keyword>
<keyword>sztp</keyword>
<keyword>ztp</keyword>
<keyword>csr</keyword>
<keyword>pkcs#10</keyword>
<keyword>p10</keyword>
<keyword>p10cr</keyword>
<keyword>cmc</keyword>
<keyword>cmp</keyword>
<abstract>
<t>This draft extends the input to the "get-bootstrapping-data" RPC defined in
RFC 8572 to include an optional certificate signing request (CSR),
enabling a bootstrapping device to additionally obtain an identity
certificate (e.g., an LDevID from IEEE 802.1AR) as part of the
"onboarding information" response provided in the RPC-reply.</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 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>
<t><spanx style="verb">AAAA</spanx> --> the assigned RFC value for I-D.ietf-netconf-crypto-types</t>
</list>
</t>
<t>Artwork in this document contains a placeholder value for the publication date 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>This document contains references to other drafts in progress, both in
the Normative References section, as well as in body text throughout.
Please update the following references to reflect their final RFC assignments:
<list style="symbols">
<t>I-D.ietf-netconf-crypto-types</t>
<t>I-D.ietf-netconf-keystore</t>
<t>I-D.ietf-netconf-trust-anchors</t>
</list>
</t>
<!--
<t>The following one Appendix section is to be removed prior to publication:
<list style="symbols">
<t>Appendix A. Change Log</t>
</list>
</t>
-->
</note>
</front>
<middle>
<section title="Introduction">
<section title="Overview">
<t>This draft extends the input to the "get-bootstrapping-data" RPC defined in
<xref target="RFC8572"/> to include an optional certificate
signing request (CSR) <xref target="RFC2986"/>, enabling a
bootstrapping device to additionally obtain an identity
certificate (e.g., an LDevID <xref target="Std-802.1AR-2018"/>)
as part of the "onboarding information" response provided in
the RPC-reply.</t>
<t>The ability to provision an identity certificate that is purpose-built
for a production environment during the bootstrapping process
removes reliance on the manufacturer CA, and it also enables the
bootstrapped device to join the production environment with an
appropriate identity and other attributes in its identity
certificate (e.g., an LDevID).</t>
<t>Two YANG <xref target="RFC7950"/> modules are defined. The
"ietf-ztp-types" module defines three YANG groupings for the
various messages defined in this document. The "ietf-sztp-csr"
module augments two groupings into the "get-bootstrapping-data"
RPC and defines a YANG Data Structure <xref target="RFC8791"/>
around the third grouping.</t>
</section>
<section title="Terminology" anchor="terminology">
<t>This document uses the following terms from <xref target="RFC8572"/>:</t>
<ul spacing="compact">
<li>Bootstrap Server</li>
<li>Bootstrapping Data</li>
<li>Conveyed Information</li>
<li>Device</li>
<li>Manufacturer</li>
<li>Onboarding Information</li>
<li>Signed Data</li>
</ul>
<t>This document defines the following new terms:</t>
<!--<dl hanging="false"> FIXME: xml2rfc fails -->
<dl>
<dt>SZTP-client</dt>
<dd>The term "SZTP-client" refers to a "device" that is using a
"bootstrap server" as a source of "bootstrapping data".</dd>
<dt>SZTP-server</dt>
<dd>The term "SZTP-server" is an alternative term for "bootstrap
server" that is symmetric with the "SZTP-client" term.</dd>
<!--
<list style="hanging" hangIndent="4">
<t hangText="SZTP-client:">The term "SZTP-client" refers
to a "device" that is using a "bootstrap server" as a
source of "bootstrapping data".</t>
<t hangText="SZTP-server:">The term "SZTP-server" refers
to a "bootstrap server".</t>
</list>
-->
</dl>
</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="Conventions">
<t>Various examples in this document use "BASE64VALUE=" as a
placeholder value for binary data that has been base64
encoded (per <xref section="9.8" target="RFC7950"/>). This
placeholder value is used because real base64 encoded structures
are often many lines long and hence distracting to the example
being presented.</t>
</section>
</section> <!-- end Introduction -->
<section title='The "ietf-sztp-csr" Module'>
<t>The "ietf-sztp-csr" module is a YANG 1.1 <xref target="RFC7950"/>
module that augments the "ietf-sztp-bootstrap-server" module defined in
<xref target="RFC8572"/> and defines a YANG "structure" that is to be
conveyed in the "error-info" node defined in <relref section="7.1" target="RFC8040"/>.</t>
<section title="Data Model Overview">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"ietf-sztp-csr" module.</t>
<t>
<figure>
<artwork name="ietf-sztp-csr-tree.txt"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ietf-sztp-csr-tree.txt)
]]></artwork>
</figure>
</t>
<t>The augmentation defines two kinds of
parameters that an SZTP-client can send to an SZTP-server. The
YANG structure defines one collection of parameters that an
SZTP-server can send to an SZTP-client.</t>
<t>In the order of their intended use:</t>
<ul>
<li>The "csr-support" node is used by the SZTP-client to signal
to the SZTP-server that it supports the ability to generate CSRs.
This parameter conveys if the SZTP-client is able to generate a
new asymmetric key and, if so, which key algorithms it supports,
as well as conveys what kinds of CSR structures the SZTP-client
is able to generate.</li>
<li>The "csr-request" structure is used by the SZTP-server to request
the SZTP-client to generate a CSR. This structure is used to
select the key algorithm the SZTP-client should use to generate
a new asymmetric key, if supported, the kind of CSR structure
the SZTP-client should generate and, optionally, the content for
the CSR itself.</li>
<li>The various "csr" nodes are used by the SZTP-client to communicate
a CSR to the SZTP-server.</li>
</ul>
<aside>
<t>No data model is defined enabling an SZTP-server to communicate
the signed certificate to the SZTP-client. How to do this is
discussed in <xref target="example-usage"/>.</t>
</aside>
<t>To further illustrate how the augmentation and structure defined
by the "ietf-sztp-csr" module are used, below are two additional
tree diagrams showing these nodes placed where they are used.</t>
<t>The following tree diagram <xref target="RFC8340"/> illustrates SZTP's
"get-bootstrapping-data" RPC with the augmentation in place.</t>
<t>
<figure>
<artwork name="ietf-sztp-csr-api-n-csr-tree.txt"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ietf-sztp-api-n-csr-tree.txt)
]]></artwork>
</figure>
</t>
<t>The following tree diagram <xref target="RFC8340"/> illustrates RESTCONF's
"errors" RPC-reply message with the "csr-request" structure in place.</t>
<t>
<figure>
<artwork name="ietf-sztp-csr-errors-n-struct-tree.txt"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ietf-sztp-csr-errors-n-struct-tree.txt)
]]></artwork>
</figure>
</t>
</section>
<section title="Example Usage" anchor="example-usage">
<aside>
<t>The examples below are encoded using JSON, but they could
equally well be encoded using XML, as is supported by SZTP.</t>
</aside>
<t>An SZTP-client implementing this specification would signal
to the bootstrap server its willingness to generate a CSR by
including the "csr-support" node in its "get-bootstrapping-data"
RPC. In the example below, the SZTP-client additionally
indicates that it is able to generate keys and provides
a list of key algorithms it supports, as well as provide
a list of certificate formats it supports.</t>
<t>
<figure>
<preamble>REQUEST</preamble>
<artwork name="ex-api-gbd-without-csr-rpc.json"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-api-gbd-without-csr-rpc.json)
]]></artwork>
</figure>
</t>
<t>Assuming the SZTP-server wishes to prompt the SZTP-client to
provide a CSR, then it would respond with an HTTP 400 Bad Request
error code. In the example below, the SZTP-server specifies
that it wishes the SZTP-client to generate a key using a specific
algorithm and generate a PKCS#10-based CSR containing specific
content.</t>
<t>
<figure>
<preamble>RESPONSE</preamble>
<artwork name="ex-api-gbd-without-csr-rpc-reply.json"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-api-gbd-without-csr-rpc-reply.json)
]]></artwork>
</figure>
</t>
<t>Upon being prompted to provide a CSR, the SZTP-client would
POST another "get-bootstrapping-data" request, but this time
including one of the "csr" nodes to convey its CSR to the
SZTP-server:</t>
<t>
<figure>
<preamble>REQUEST</preamble>
<artwork name="ex-api-gbd-with-csr-rpc.json"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-api-gbd-with-csr-rpc.json)
]]></artwork>
</figure>
</t>
<t>At this point, it is expected that the SZTP-server, perhaps
in conjunction with other systems, such as a backend CA or RA,
will validate the CSR's origin and proof-of-possession and,
assuming the CSR is approved, issue a signed certificate for
the bootstrapping device.</t>
<t>The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node, shown below) containing
a signed identity certificate for the CSR provided by the
SZTP-client:</t>
<t>
<figure>
<preamble>RESPONSE</preamble>
<artwork name="ex-api-gbd-with-csr-rpc-reply.json"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-api-gbd-with-csr-rpc-reply.json)
]]></artwork>
</figure>
</t>
<t>How the signed certificate is conveyed inside the onboarding information
is outside the scope of this document. Some implementations may choose
to convey it inside a script (e.g., SZTP's "pre-configuration-script"),
while other implementations may choose to convey it inside the SZTP
"configuration" node. SZTP onboarding information is described in
<relref section="2.2" target="RFC8572"/>.</t>
<t>Below are two examples of conveying the signed certificate inside
the "configuration" node. Both examples assume that the SZTP-client
understands the "ietf-keystore" module defined in
<xref target="I-D.ietf-netconf-keystore"/>.</t>
<t>This first example illustrates the case where the signed certificate is
for the same asymmetric key used by the SZTP-client's manufacturer-generated
identity certificate (e.g., an IDevID, from <xref target="Std-802.1AR-2018"/>).
As such, the configuration needs to associate the newly signed certificate
with the existing asymmetric key:</t>
<t>
<figure>
<artwork name="ex-keystore-ldevid-same-key.json"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-keystore-ldevid-same-key.json)
]]></artwork>
</figure>
</t>
<t>This second example illustrates the case where the signed certificate is
for a newly generated asymmetric key. As such, the configuration needs
to associate the newly signed certificate with the newly generated
asymmetric key:</t>
<t>
<figure>
<artwork name="ex-keystore-ldevid-new-key.json"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-keystore-ldevid-new-key.json)
]]></artwork>
</figure>
</t>
<t>In addition to configuring the signed certificate, it is often
necessary to also configure the Issuer's signing certificate
so that the device (i.e., STZP-client) can authenticate
certificates presented by peer devices signed by the same
issuer as its own. While outside the scope of this document,
one way to do this would be to use the "ietf-truststore" module
defined in <xref target="I-D.ietf-netconf-trust-anchors"/>.</t>
</section> <!-- Example Usage -->
<section title="YANG Module">
<t>This module augments an RPC defined in <xref target="RFC8572"/>. The
module uses a data types and groupings defined in <xref target="RFC8572"/>,
<xref target="RFC8791"/>, and <xref target="I-D.ietf-netconf-crypto-types"/>.
The module also has an informative reference to <xref target="Std-802.1AR-2018"/>.</t>
<t>
<figure>
<preamble><CODE BEGINS> file "ietf-sztp-csr@YYYY-MM-DD.yang"</preamble>
<artwork name="ietf-sztp-csr@YYYY-MM-DD.yang"><![CDATA[
INSERT_TEXT_FROM_FILE(ietf-sztp-csr@YYYY-MM-DD.yang)
]]></artwork>
<postamble><CODE ENDS></postamble>
</figure>
</t>
</section> <!-- YANG Module -->
</section>
<section title='The "ietf-ztp-types" Module'>
<t>This section defines a YANG 1.1 <xref target="RFC7950"/> module
that defines three YANG groupings, one each for messages sent
between a ZTP-client and ZTP-server. This module is defined
independently of the "ietf-sztp-csr" module so that it's
groupings may be used by bootstrapping protocols other than
SZTP <xref target="RFC8572"/>.</t>
<section title="Data Model Overview">
<t>The following tree diagram <xref target="RFC8340"/> illustrates
the three groupings defined in the "ietf-ztp-types" module.</t>
<t>
<figure>
<artwork name="ietf-ztp-types-tree.txt"><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ietf-ztp-types-tree.txt)
]]></artwork>
</figure>
</t>
</section>
<section title="YANG Module">
<t>This module uses a data types and groupings <xref target="RFC8791"/>
and <xref target="I-D.ietf-netconf-crypto-types"/>. The module has
additional normative references to <xref target="RFC2986"/>,
<xref target="RFC4210"/>, <xref target="RFC5272"/>, and
<xref target="ITU.X690.2015"/>, and an informative reference
to <xref target="Std-802.1AR-2018"/>.</t>
<t>
<figure>
<preamble><CODE BEGINS> file "ietf-ztp-types@YYYY-MM-DD.yang"</preamble>
<artwork name="ietf-ztp-types@YYYY-MM-DD.yang"><![CDATA[
INSERT_TEXT_FROM_FILE(ietf-ztp-types@YYYY-MM-DD.yang)
]]></artwork>
<postamble><CODE ENDS></postamble>
</figure>
</t>
</section> <!-- YANG Module -->
</section>
<section title="Security Considerations" anchor="sec-con">
<t>This document builds on top of the solution presented in
<xref target="RFC8572"/> and therefore all the Security
Considerations discussed in RFC 8572 apply here as well.</t>
<t>For the various CSR formats, when using PKCS#10, the security considerations
in <xref target="RFC2986"/> apply, when using CMP, the
security considerations in <xref target="RFC4210"/> apply
and, when using CMC, the security considerations in
<xref target="RFC5272"/> apply.</t>
<t>For the various authentication mechanisms, when using
TLS-level authentication, the security considerations in
<xref target="RFC8446"/> apply and, when using HTTP-level
authentication, the security considerations in
<xref target="RFC7235"/> apply.</t>
<section title="SZTP-Client Considerations">
<section title="Ensuring the Integrity of Asymmetric Private Keys">
<t>The private key the SZTP-client uses for the dynamically-generated
identity certificate MUST be protected from inadvertent disclosure
in order to prevent identity fraud.</t>
<t>The security of this private key is essential in order to
ensure the associated identity certificate can be used to
authenticate the device it is issued to.</t>
<t>It is RECOMMENDED that devices are manufactured with an HSM
(hardware security module), such as a TPM (trusted platform
module), to generate and contain the private key within
the security perimeter of the HSM. In such cases, the private
key, and its associated certificates, MAY have long validity
periods.</t>
<t>In cases where the SZTP-client does not possess an HSM, or
is unable to use an HSM to protect the private key, it is
RECOMMENDED to periodically reset the private key (and
associated identity certificates) in order to minimize the
lifetime of unprotected private keys. For instance, an NMS
controller/orchestrator application could periodically prompt
the SZTP-client to generate a new private key and provide a
certificate signing request (CSR) or, alternatively, push
both the key and an identity certificate to the SZTP-client
using, e.g., a PKCS #12 message <xref target="RFC7292"/>. In another
example, the SZTP-client could be configured to periodically
reset the configuration to its factory default, thus causing
removal of the private key and associated identity certificates
and re-execution of the SZTP protocol.</t>
</section>
<section title="Reuse of a Manufacturer-generated Private Key">
<t>It is RECOMMENDED that a new private key is generated for each
CSR described in this document.</t>
<t>Implementations must randomly generate nonces and private keys.
The use of inadequate pseudo-random number generators (PRNGs) to
generate cryptographic keys can result in little or no security.
An attacker may find it much easier to reproduce the PRNG environment
that produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole
key space. As an example of predictable random numbers see
CVE-2008-0166 <xref target="CVE-2008-0166"/>, and some consequences
of low-entropy random numbers are discussed in Mining Your Ps and Qs
<xref target="MiningPsQs"/>. The generation of quality random
numbers is difficult. <xref target="ISO.20543-2019"/>,
<xref target="NIST.SP.800-90Ar1"/>, BSI AIS 31 <xref target="AIS31"/>,
BCP 106 <xref target="RFC4086"/>, and others offer valuable
guidance in this area.</t>
<t>This private key SHOULD be protected as well as the built-in
private key associated with the SZTP-client's initial device identity
certificate (e.g., the IDevID, from <xref target="Std-802.1AR-2018"/>).</t>
<t>In cases where it is not possible to generate a new private key
that is protected as well as the built-in private key, it is
RECOMMENDED to reuse the built-in private key rather than
generate a new private key that is not as well protected.</t>
</section>
<section title="Replay Attack Protection">
<t>This RFC enables an SZTP-client to announce an ability to
generate a new key to use for its CSR.</t>
<t>When the SZTP-server responds with a request for the SZTP-client
to generate a new key, it is essential that the SZTP-client actually
generates a new key.</t>
<t>Generating a new key each time enables the random bytes used
to create the key to also serve the dual-purpose of acting like
a "nonce" used in other mechanisms to detect replay attacks.</t>
<t>When a fresh public/private key pair is generated for the
request, confirmation to the SZTP-client that the response
has not been replayed is enabled by the SZTP-client's fresh
public key appearing in the signed certificate provided by
the SZTP-server.</t>
<t>When a public/private key pair associated with the
manufacturer-generated identity certificate (e.g., IDevID) is
used for the request, there may not be confirmation to the
SZTP-client that the response has not been replayed; however,
the worst case result is a lost certificate that is associated
to the private key known only to the SZTP-client. Protection
of the private-key information is vital to public-key
cryptography. Disclosure of the private-key material to
another entity can lead to masquerades.</t>
</section>
<section title="Connecting to an Untrusted Bootstrap Server" anchor="untrusted">
<t><xref target="RFC8572"/> allows SZTP-clients to connect
to untrusted SZTP-servers, by blindly authenticating the
SZTP-server's TLS end-entity certificate.</t>
<t>As is discussed in <relref section="9.5" target="RFC8572"/>,
in such cases the SZTP-client MUST assert that the
bootstrapping data returned is signed, if the SZTP-client
is to trust it.</t>
<t>However, the HTTP error message used in this document
cannot be signed data, as described in RFC 8572.</t>
<t>Therefore, the solution presented in this document
cannot be used when the SZTP-client connects to an
untrusted SZTP-server.</t>
<t>Consistent with the recommendation presented in
<relref section="9.6" target="RFC8572"/>, SZTP-clients
SHOULD NOT pass the "csr-support" input parameter
to an untrusted SZTP-server. SZTP-clients SHOULD
pass instead the "signed-data-preferred" input
parameter, as discussed in <relref section="B"
target="RFC8572"/>.</t>
</section>
<section title="Selecting the Best Origin Authentication Mechanism">
<t>The origin of the CSR must be verified before a
certificate is issued.</t>
<t>When generating a new key, it is important that the
SZTP-client be able to provide additional proof that it
was the entity that generated the key.</t>
<t>The CMP and CMC certificate request formats defined in this
document support origin authentication. A raw
PKCS#10 CSR does not support origin authentication.</t>
<t>The CMP and CMC request formats support origin
authentication using both PKI and shared secret.</t>
<t>Typically, only one possible origin authentication
mechanism can possibly be used but, in the case that the
SZTP-client authenticates itself using both TLS-level
(e.g., IDevID) and HTTP-level credentials (e.g., Basic),
as is allowed by <relref section="5.3" target="RFC8572"/>,
then the SZTP-client may need to choose between the two
options.</t>
<t>In the case that the SZTP-client must choose between an
asymmetric key option versus a shared secret for origin
authentication, it is RECOMMENDED that the SZTP-client
choose using the asymmetric key.</t>
</section>
<section title="Clearing the Private Key and Associated Certificate">
<t>Unlike a manufacturer-generated identity certificate (e.g., IDevID),
the deployment-generated identity certificate (e.g., LDevID) and
the associated private key (assuming a new private key was generated
for the purpose), are considered user data and SHOULD be cleared
whenever the SZTP-client is reset to its factory default state,
such as by the "factory-reset" RPC defined in
<xref target="RFC8808"/>.</t>
</section>
</section>
<section title="SZTP-Server Considerations">
<section title="Verifying Proof of Possession">
<t>Regardless if using a new asymmetric key or the bootstrapping
device's manufacturer-generated key (e.g., the IDevID key), the
public key is placed in the CSR and the CSR is signed by that
private key. Proof-of-possession of the private key is verified
by ensuring the signature over the CSR using the public key
placed in the CSR.</t>
</section>
<section title="Verifying Proof of Origin">
<t>When the bootstrapping device's manufacturer-generated
private key (e.g., the IDevID key) is reused for the CSR,
proof-of-origin is verified by validating the IDevID-issuer cert
and ensuring that the CSR uses the same key pair.</t>
<t>When the bootstrapping device's manufacturer-generated private key
(e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, proof-of-origin is
verified by validating the IDevID certification path and ensuring that
the CSR uses the same key pair.</t>
<t>When a fresh asymmetric key is used with the CMP or CMC formats, the
authentication is part of the protocols, which could employ either
the manufacturer-generated private key or a shared secret. In addition,
CMP and CMC support processing by a RA before the request is passed
to the CA, which allows for more robust handling of errors.</t>
</section>
<section title="Supporting SZTP-Clients that don't trust the SZTP-Server">
<t><xref target="RFC8572"/> allows SZTP-clients to connect
to untrusted SZTP-servers, by blindly authenticating the
SZTP-server's TLS end-entity certificate.</t>
<t>As is recommended in <xref target="untrusted"/> in this
document, in such cases, SZTP-clients SHOULD pass the
"signed-data-preferred" input parameter.</t>
<t>The reciprocal of this statement is that SZTP-servers,
wanting to support SZTP-clients that don't trust them,
SHOULD support the "signed-data-preferred" input parameter,
as discussed in <relref section="B" target="RFC8572"/>.</t>
</section>
</section>
<section title='Security Considerations for the "ietf-sztp-csr" YANG Module'>
<t>The recommended format for documenting the Security
Considerations for YANG modules is described in <relref
section="3.7" target="RFC8407"/>. However, this module
only augments two input parameters
into the "get-bootstrapping-data" RPC in <xref
target="RFC8572"/>, and therefore only needs to point
to the relevant Security Considerations sections in
that RFC.</t>
<list style="symbols">
<t>Security considerations for the "get-bootstrapping-data" RPC
are described in <relref section="9.16" target="RFC8572"/>.</t>
<t>Security considerations for the "input" parameters passed inside the
"get-bootstrapping-data" RPC are described in <relref section="9.6"
target="RFC8572"/>.</t>
</list>
</section>
<section title='Security Considerations for the "ietf-ztp-types" YANG Module'>
<t>The recommended format for documenting the Security
Considerations for YANG modules is described in <relref
section="3.7" target="RFC8407"/>. However, this module
does not define any protocol-accessible nodes (it only
defines "identity" and "grouping" statements) and therefore
there are no Security considerations to report.</t>
</section>
</section> <!-- end Security Considerations -->
<section title="IANA Considerations" anchor="iana-considerations">
<section title='The "IETF XML" Registry'>
<t>This document registers two URIs in the "ns" subregistry of
the IETF XML Registry <xref target="RFC3688"/> maintained at
<eref target="https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns"/>.
Following the format in <xref target="RFC3688"/>, the following
registrations are requested:</t>
<t>
<figure>
<artwork><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
]]></artwork>
</figure>
</t>
</section>
<section title='The "YANG Module Names" Registry'>
<t>This document registers two YANG modules in the YANG Module
Names registry <xref target="RFC6020"/> maintained at
<eref target="https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml"/>.
Following the format defined in <xref target="RFC6020"/>, the below
registrations are requested:</t>
<t>
<figure>
<artwork><![CDATA[
name: ietf-sztp-csr
namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr
prefix: sztp-csr
reference: RFC XXXX
name: ietf-ztp-types
namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types
prefix: ztp-types
reference: RFC XXXX
]]></artwork>
</figure>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2986.xml"?>
<?rfc include="reference.RFC.3688.xml"?>
<?rfc include="reference.RFC.4210.xml"?>
<?rfc include="reference.RFC.5272.xml"?>
<?rfc include="reference.RFC.6020.xml"?>
<?rfc include="reference.RFC.7235.xml"?>
<?rfc include="reference.RFC.7950.xml"?>
<?rfc include="reference.RFC.8040.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8446.xml"?>
<?rfc include="reference.RFC.8572.xml"?>
<?rfc include="reference.RFC.8791.xml"?>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-crypto-types.xml"/>
<!-- THE FOLLOWING LINE DOESN'T RESOLVE FOR SOME REASON:
<?rfc include="_reference.ITU.X690.2015.xml"?> -->
<!-- THE FOLLOWING IS COPIED FROM RFC 8366 -->
<reference anchor="ITU.X690.2015" target="https://www.itu.int/rec/T-REC-X.690/">
<front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="August" year="2015" />
</front>
<seriesInfo name="ITU-T Recommendation X.690," value="ISO/IEC 8825-1" />
</reference>
</references>
<references title="Informative References">
<reference anchor="Std-802.1AR-2018" target="https://standards.ieee.org/standard/802_1AR-2018.html">
<front>
<title>IEEE Standard for Local and metropolitan area networks - Secure Device Identity</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date day="14" month="June" year="2018"/>
</front>
</reference>
<reference anchor="CVE-2008-0166" target="https://nvd.nist.gov/vuln/detail/CVE-2008-0166">
<front>
<title>National Vulnerability Database - CVE-2008-0166</title>
<author>
<organization>National Institute of Science and Technology (NIST)</organization>
</author>
<date day="13" month="May" year="2008"/>
</front>
</reference>
<reference anchor="MiningPsQs" target="https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger">
<front>
<title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices</title>
<author>
<organization>Security'12: Proceedings of the 21st USENIX conference on Security symposium</organization>
</author>
<author fullname="Nadia Heninger">
<organization>UC San Diego</organization>
</author>
<author fullname="Zakir Durumeric">
<organization>University of Michigan</organization>
</author>
<author fullname="Eric Wustrow">
<organization>University of Michigan</organization>
</author>
<author fullname="J. Alex Halderman">
<organization>University of Michigan</organization>
</author>
<date month="August" year="2012"/>
</front>
</reference>
<reference anchor="ISO.20543-2019">
<front>
<title>Information technology — Security techniques — Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408</title>
<author>
<organization>International Organization for Standardization (ISO)</organization>
</author>
<date month="October" year="2019"/>
</front>
<seriesInfo name="ISO" value="Draft Standard 20543-2019"/>
</reference>
<reference anchor="NIST.SP.800-90Ar1" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf">
<front>
<title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators</title>
<author initials="Elaine B." surname="Barker" fullname="Elaine B. Barker">
<organization>Information Technology Laboratory</organization>
</author>
<author initials="John M." surname="Kelsey" fullname="John M. Kelsey">
<organization>Information Technology Laboratory</organization>
</author>
<date year="2015" month="June"/>
</front>
<seriesInfo name="NIST" value="NIST SP 800-90Ar1"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/>
</reference>
<reference anchor="AIS31" target="https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_for_random_number_generators_e.pdf">
<front>
<title>A proposal for: Functionality classes for random number generators, version 2.0</title>
<author>
<organization>Bundesamt für Sicherheit in der Informationstechnik (BSI)</organization>
</author>
<author initials="W" surname="Killmann" fullname="Wolfgang Killmann">
<organization>T-Systems GEI GmbH</organization>
</author>
<author initials="W." surname="Schindler" fullname="Werner Schindler">
<organization>Bundesamt für Sicherheit in der Informationstechnik (BSI)</organization>
<!-- <organization>Federal Office for Information Security (BSI)</organization> -->
</author>
<date day="18" month="09" year="2011"/>
</front>
</reference>
<?rfc include="reference.RFC.4086.xml"?>
<?rfc include="reference.RFC.7292.xml"?>
<?rfc include="reference.RFC.8340.xml"?>
<?rfc include="reference.RFC.8407.xml"?>
<?rfc include="reference.RFC.8808.xml"?>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-keystore.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-trust-anchors.xml"/>
</references>
<section title="Acknowledgements" numbered="no">
<t>The authors would like to thank for following for lively
discussions on list and in the halls (ordered by first name):
Benjamin Kaduk,
David von Oheimb,
Dan Romascanu,
Eric Vyncke,
Hendrik Brockhaus,
Guy Fedorkow,
Joe Clarke,
Meral Shirazipour,
Murray Kucherawy,
Rich Salz,
Rob Wilton,
Roman Danyliw,
Qin Wu,
Yaron Sheffer,
and Zaheduzzaman Sarkar.
</t>
</section>
<section title="Contributors" numbered="no">
<t>Special thanks go to David von Oheimb and Hendrik Brockhaus
for helping with the descriptions for the "cmc-csr" and "cmp-csr"
nodes.</t>
</section>
</back>
</rfc>