-
Notifications
You must be signed in to change notification settings - Fork 0
/
dtsecurity-zerotouch-join.xml
1977 lines (1619 loc) · 93.8 KB
/
dtsecurity-zerotouch-join.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" encoding="us-ascii"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.7 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-6lo-privacy-considerations SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-privacy-considerations.xml">
<!ENTITY RFC7030 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml">
<!ENTITY RFC7228 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY RFC7250 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY RFC4514 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4514.xml">
<!ENTITY I-D.ietf-anima-bootstrapping-keyinfra SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-bootstrapping-keyinfra.xml">
<!ENTITY I-D.richardson-6tisch-enrollment-enhanced-beacon SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.richardson-6tisch-enrollment-enhanced-beacon.xml">
<!ENTITY I-D.ietf-anima-constrained-voucher SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml">
<!ENTITY I-D.ietf-6tisch-minimal SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-minimal.xml">
<!ENTITY I-D.ietf-anima-grasp SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-grasp.xml">
<!ENTITY I-D.ietf-6tisch-minimal-security SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-minimal-security.xml">
<!ENTITY I-D.richardson-anima-6join-discovery SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.richardson-anima-6join-discovery.xml">
<!ENTITY I-D.richardson-6tisch-minimal-rekey SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.richardson-6tisch-minimal-rekey.xml">
<!ENTITY I-D.ietf-core-object-security SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-object-security.xml">
<!ENTITY I-D.ietf-6tisch-terminology SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-terminology.xml">
<!ENTITY I-D.ietf-netconf-keystore SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-keystore.xml">
<!ENTITY I-D.ietf-core-comi SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-comi.xml">
<!ENTITY I-D.ietf-ace-cbor-web-token SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ace-cbor-web-token.xml">
<!ENTITY I-D.ietf-ace-coap-est SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ace-coap-est.xml">
<!ENTITY I-D.ietf-core-yang-cbor SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-yang-cbor.xml">
<!ENTITY I-D.selander-ace-cose-ecdhe SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.selander-ace-cose-ecdhe.xml">
<!ENTITY I-D.schaad-cose-x509 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.schaad-cose-x509.xml">
<!ENTITY RFC7217 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml">
<!ENTITY I-D.richardson-6tisch-join-enhanced-beacon SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.richardson-6tisch-join-enhanced-beacon.xml">
<!ENTITY RFC6775 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC7252 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY I-D.ietf-anima-voucher SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-voucher.xml">
<!ENTITY RFC7959 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC7554 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml">
<!ENTITY RFC4191 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY RFC5056 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5056.xml">
<!ENTITY RFC7641 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml">
<!ENTITY RFC7731 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7731.xml">
<!ENTITY I-D.ietf-roll-useofrplinfo SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-useofrplinfo.xml">
<!ENTITY I-D.ietf-anima-autonomic-control-plane SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-autonomic-control-plane.xml">
<!ENTITY I-D.ietf-ace-actors SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ace-actors.xml">
<!ENTITY I-D.ietf-core-sid SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-sid.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-6tisch-dtsecurity-zerotouch-join-03" category="info">
<front>
<title>6tisch Zero-Touch Secure Join protocol</title>
<author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2018" month="June" day="18"/>
<area>Internet</area>
<workgroup>6tisch Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes a Zero-touch Secure Join (ZSJ) mechanism to enroll a
new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch
signaling mechanisms. The resulting device will obtain a domain specific
credential that can be used with either 802.15.9 per-host pair keying
protocols, or to obtain the network-wide key from a coordinator. The
mechanism describe here is an augmentation to the one-touch mechanism
described in <xref target="I-D.ietf-6tisch-minimal-security"/>, and a constrained
version of <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Enrollment of new nodes into LLNs present unique challenges.
The constrained nodes has no user interfaces, and even if they did,
configuring thousands of such nodes manually is undesireable from a human
resources issue, as well as the difficulty in getting consistent results.</t>
<t>This document is about a standard way to introduce new nodes into a 6tisch
network that does not involve any direct manipulation of the nodes themselves.
This act has been called "zero-touch" provisioning, and it does not occur by
chance, but requires coordination between the manufacturer of the node, the
service operator running the LLN, and the installers actually taking the
devices out of the shipping boxes.</t>
<t>This document is a constrained profile of
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>. The above document/protocol is
referred by by it's acronym: BRSKI. The pronounciation of which is
"brew-ski", a common north american slang for beer with a pseudo-polish
ending. This constrained protocol is called ZSJ.</t>
<t>This document follows the same structure as it's parent in order to emphasize
the similarities, but specializes a number of things to constrained networks
of constrained devices.
Like <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>, the networks which are in
scope for this protocol are deployed by a professional operator.
The deterministic mechanisms which have been designed into 6tisch have been
created to satisfy the operational needs of industrial settings where such
an operator exists.</t>
<t>This document builds upon the "one-touch" provisioning described in
<xref target="I-D.ietf-6tisch-minimal-security"/>,
reusing the OSCOAP Join Request mechanism when appropriate, but preceeding it
with either the EDHOC key agreement protocol, or a DTLS channel.
The <xref target="RFC7030"/> EST protocol extended in
<xref target="I-D.ietf-6tisch-minimal-security"/>, has been mapped by
<xref target="I-D.ietf-ace-coap-est"/> into CoAP.</t>
<t>Otherwise, this document follows BRSKI with the following high-level changes:</t>
<t><list style="symbols">
<t>HTTP is replaced with CoAP.</t>
<t>TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/OSCOAP+CoAP</t>
<t>the domain-registrar anchor certificate is replaced with a Raw Public Key
(RPK) using <xref target="RFC7250"/>.</t>
<t>the PKCS7 signed JSON voucher format is replaced with CWT</t>
<t>the GRASP discovery mechanism for the Proxy is replaced with an
announcement in the Enhanced Beacon
<xref target="I-D.richardson-6tisch-join-enhanced-beacon"/></t>
<t>the TCP circuit proxy mechanism is not used. The IPIP mechanism if
mandatory to implement when deployed with DTLS, while the CoAP based
stateless proxy mechanism is used for OSCOAP/EDHOC.</t>
<t>real time clocks are assumed to be unavailable, so expiry dates in
ownership vouchers are never used</t>
<t>nonce-full vouchers are encouraged, but off-line nonce-less operation is
also supported, however, the resulting vouchers have infinite life.</t>
</list></t>
<t>802.1AR Client certificates are retained, but optionally are specified by reference rather than value.</t>
<t>It is expected that the back-end network operator infrastructure would be
able to bootstrap ANIMA BRSKI-type devices over ethernet, while also being able
bootstrap 6tisch devices over 802.15.4 with few changes.</t>
<t>NOTE TO RFC-EDITOR: during production of this document, it was matched
against <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> section by section.
This results in a few sections, such as IANA Considerations where there
is no requested activity. Those sections are marked "NO ACTION, PLEASE REMOVE"
and should be removed (along with this paragraph) from the final document.</t>
<section anchor="prior-bootstrapping-approaches" title="Prior Bootstrapping Approaches">
<t>Constrained devices as used in industrial control systems are usually
installed (or replaced) by technicians with expertise in the equipment being
serviced, not in secure enrollment of devices.</t>
<t>Devices therefore are typically pre-configured in advance, marked for a
particular factory, assembly line, or even down to the specific machine.
It is not uncommon for manufacturers to have a product code (stock keeping
unit -SKU) for each part, and for each customer as the part will be loaded
with customer specifc security configuration. The resulting
customer-specific parts are hard to inventory and spare, and should parts
be delivered to the wrong customer, determining the reason for inability
to configure is difficult and time consuming.</t>
<t>End-user actions to configure the part at the time of installation, aside
from being error prone, also suffer from requiring a part that has an interface.</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
<xref target="RFC2119"/> and indicate requirement levels for compliant STuPiD
implementations.</t>
<t>The reader is expected to be familiar with the terms and concepts defined in
<xref target="I-D.ietf-6tisch-terminology"/>, <xref target="RFC7252"/>,
<xref target="I-D.ietf-core-object-security"/>, and
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>. The following terms are
imported: drop ship, imprint, enrollment, pledge, join proxy, ownership
voucher, join registrar/coordinator. The following terms are repeated here
for readability, but this document is not authoritative for their definition:</t>
<t><list style="hanging">
<t hangText='pledge'>
the prospective device, which has the identity provided to
at the factory. Neither the device nor the network knows if the
device yet knows if this device belongs with this network.</t>
<t hangText='Joined Node'>
the prospective device, after having completing the join process, often just called a Node.</t>
<t hangText='Join Proxy (JP):'>
a stateless relay that provides connectivity between the pledge
and the join registrar/coordinator.</t>
<t hangText='Join Registrar/Coordinator (JRC):'>
central entity responsible for authentication and authorization of joining nodes.</t>
<t hangText='Audit Token'>
A signed token from the manufacturer authorized signing
authority indicating that the bootstrapping event has been
successfully logged. This has been referred to as an
"authorization token" indicating that it authorizes bootstrapping
to proceed.</t>
<t hangText='Ownership Voucher'>
A signed voucher from the vendor vouching that a specific domain "owns"
the new entity as defined in <xref target="I-D.ietf-anima-voucher"/>.</t>
<t hangText='MIC'>
manufacturer installed certificate. An <xref target="ieee802-1AR"/> identity. Not to be confused with a (cryptographic) "Message Integrity Check"</t>
</list></t>
</section>
<section anchor="scope-of-solution" title="Scope of solution">
<t>The solution described in this document is appropriate to enrolling between
hundreds to hundreds of thousands of diverse devices into a network without
any prior contact with the devices. The devices could be shipped by the
manufacturer directly to the customer site without ever being seen by the
operator of the network. As described in BRSKI, in the audit-mode of
operation the device will be claimed by the first network that sees it. In
the tracked owner mode of operation, sales channel integration provides a
strong connection that the operator of the network is the legitimate owner of
the device.</t>
<t>BRSKI describes a more general, more flexible approach for bootstrapping
devices into an ISP or Enterprise network.</t>
<t><xref target="I-D.ietf-6tisch-minimal-security"/> provides an extremely streamlined
approach to enrolling from hundreds to thousands of devices into a network,
provided that a unique secret key can be installed in each device.</t>
<section anchor="support-environment" title="Support environment">
<t>TBD</t>
</section>
<section anchor="constrained-environments" title="Constrained environments">
<t>TBD</t>
</section>
<section anchor="network-access-controls" title="Network Access Controls">
<t>TBD</t>
</section>
</section>
<section anchor="leveraging-the-new-key-infrastructure-next-steps" title="Leveraging the new key infrastructure / next steps">
<t>In constrained networks, it is unlikely that an ACP be formed.
This document does not preclude such a thing, but it is not mandated.</t>
<t>The resulting secure channel MAY be used just to distribute network-wide
keys using a protocol such as <xref target="I-D.ietf-6tisch-minimal-security"/>.
(XXX – do we need to signal this somehow?)</t>
<t>The resulting secure channel MAY be instead used to do an enrollment
of an LDevID as in BRSKI, but the resulting certificate is used to do
per-pair keying such as described by {{ieee802159}.</t>
<section anchor="key-distribution-process" title="Key Distribution Process">
<t>In addition to being used for the initial enrollment process, the secure
channel may be kept open (and reversed) to use for network rekeying.
Such a process is out of scope of this document, please see future work such
as <xref target="I-D.richardson-6tisch-minimal-rekey"/>.</t>
</section>
</section>
<section anchor="requirements-for-autonomic-network-infrastructure-ani-devices" title="Requirements for Autonomic Network Infrastructure (ANI) devices">
<t>TBD</t>
</section>
</section>
<section anchor="architectural-overview" title="Architectural Overview">
<t>Section 2 of BRSKI has a diagram with all of the components shown together.
There are no significant changes to the diagram.</t>
<t>The use of a circuit proxy is not mandated. Instead the IPIP mechanism
described in appendix C ("IPIP Join Proxy mechanism") SHOULD be be used
instead as it supports both DTLS, EDHOC and OSCOAP protocols.</t>
<t>The CoAP proxy mechanism MAY be implemented instead: the decision depends
upon the capabilities of the Registrar and the proxy. A mechanism is
included for the Registrar to announce it's capabilities (XXX)</t>
<section anchor="behavior-of-a-pledge" title="Behavior of a Pledge">
<t>The pledge goes through a series of steps which are outlined here at
a high level.</t>
<figure><artwork><![CDATA[
+--------------+
| Factory |
| default |
+------+-------+
|
+------v-------+
| (1) Discover |
+------------> |
| +------+-------+
| |
| +------v-------+
| | (2) Identity |
^------------+ |
| rejected +------+-------+
| |
| +------v-------+
| | (3) Request |
| | Join |
| +------+-------+
| |
| +------v-------+
| | (4) Imprint |
^------------+ |
| Bad MASA +------+-------+
| response | send Voucher Status Telemetry
| +------v-------+
| | (5) Enroll |
^------------+ |
| Enroll +------+-------+
| Failure |
| +------v-------+
| | (6) Enrolled |
^------------+ |
Factory +--------------+
reset
]]></artwork></figure>
<t>State descriptions for the pledge are as follows:</t>
<t><list style="numbers">
<t>Discover a communication channel to a Registrar. This is done by
listening for beacons as described by <xref target="I-D.richardson-anima-6join-discovery"/></t>
<t>Identify itself. This is done by presenting an X.509 IDevID credential
to the discovered Registrar (via the Proxy) in a DTLS or EDHOC handshake.
(The Registrar credentials are only provisionally accepted at this time). <vspace blankLines='1'/>
The registrar identifies itself using a raw public key, while the the
pledge identifies itself to the registrar using an IDevID credential.</t>
<t>Requests to Join the discovered Registrar. A unique nonce can be
included ensuring that any responses can be associated with this
particular bootstrapping attempt.</t>
<t>Imprint on the Registrar. This requires verification of the
vendor service (MASA) provided voucher. A voucher contains sufficient
information for the Pledge to complete authentication of a
Registrar. The voucher is signed by the vendor (MASA) using a raw public
key, previously installed into the pledge at manufacturing time.</t>
<t>Optionally Enroll. By accepting the domain specific information from a
Registrar, and by obtaining a domain certificate from a Registrar
using a standard enrollment protocol, e.g. Enrollment over
Secure Transport (EST) <xref target="RFC7030"></xref>.</t>
<t>The Pledge is now a member of, and can be managed by, the domain
and will only repeat the discovery aspects of bootstrapping if it
is returned to factory default settings.</t>
</list></t>
</section>
<section anchor="secure-imprinting-using-vouchers" title="Secure Imprinting using Vouchers">
<t>As in BRSKI, the format and cryptographic mechansim of vouchers is described
in detail in <xref target="I-D.ietf-anima-voucher"/>. As described in section YYY, the
physical format for vouchers in this document differs from that of BRSKI, in
that it uses <xref target="I-D.ietf-ace-cbor-web-token"/> to encode the voucher and to sign it.</t>
</section>
<section anchor="initial-device-identifier" title="Initial Device Identifier">
<t>The essential component of the zero-touch operation is that the pledge is
provisioned with an 802.1AR (PKIX) certificate installed during the
manufacturing process.</t>
<t>It is expected that constrained devices will use a signature algorithm
corresponding to the
hardware acceleration that they have, if they have any. The anticipated algorithms are
the ECDSA P-256 (secp256p1), and SHOULD be supported.
Newer devices SHOULD begin to appear using EdDSA curves using the 25519
curves.</t>
<t>The manufacturer will always know what algorithms are available in the
Pledge, and will use an appropriate one. The other components that need to
evaluate the IDevID (the Registrar and MASA) are expected to support all
common algorithms.</t>
<t>There are a number of simplications detailed later on in this document
designed to eliminate the need for an ASN.1 parser in the pledge.</t>
<t>The pledge should consider it's 802.1AR certificate to be an opaque blob of
bytes, to be inserted into protocols at appropriate places. The pledge
SHOULD have access to it's public and private keys in the most useable native
format for computation.</t>
<t>The pledge MUST have the public key of the MASA built in a manufacturer time.
This is a seemingly identical requirement as for BRSKI, but rather than being
an abstract trust anchor that can be augmented with a certificate chain, the
pledge MUST be provided with the Raw Public Key that the MASA will use to
sign vouchers for that pledge.</t>
<t>There are a number of security concerns with use of a single MASA signing
key, and section <xref target="masaprivatekey"/> addresses some of them with some
operational suggestions.</t>
<t>BRSKI places some clear requirements upon the contents of the IDevID, but
leaves the exact origin of the voucher serial-number open. This document
restricts the process to being the hwSerialNum OCTET STRING. As CWT can
handle binary formats, no base64 encoding is necessary.</t>
<t>The use of the MASA-URL extension is encouraged if the certificate is sent at all.</t>
<t>EDNOTE: here belongs text about sending only a reference to the IDevID rather
than the entire certificate</t>
<section anchor="identification-of-the-pledge" title="Identification of the Pledge">
<t>TBD</t>
</section>
<section anchor="masa-uri-extension" title="MASA URI extension">
<t>TBD</t>
</section>
</section>
<section anchor="protocol-flow" title="Protocol Flow">
<t>The diagram from BRSKI is reproduced with some edits:</t>
<figure><artwork><![CDATA[
+--------+ +---------+ +------------+ +------------+
| Pledge | | IPIP | | Domain | | Vendor |
| | | Proxy | | Registrar | | Service |
| | | | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+
| | | |
|<-RFC4862 IPv6 adr | | |
| | | |
|<--------------------| | |
| Enhanced Beacon | | |
| periodic broadcast| | |
| | | |
|<------------------->C<----------------->| |
| DTLS via the IPIP Proxy | |
|<--Registrar DTLS server authentication--| |
[PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| |
P | | |
P---Voucher Request (include nonce)------>| |
P | | |
P | | |
P | [accept device?] |
P | [contact Vendor] |
P | |--Pledge ID-------->|
P | |--Domain ID-------->|
P | |--nonce------------>|
P | | [extract DomainID]
P | | |
P | | [update audit log]
P | | |
P | | |
P | | |
P | | |
P | | |
P | |<-device audit log--|
P | |<- voucher ---------|
P | | |
P | | |
P | [verify audit log and voucher] |
P | | |
P<------voucher---------------------------| |
[verify voucher ] | | |
[verify provisional cert| | |
| | | |
|<--------------------------------------->| |
| Continue with RFC7030 enrollment | |
| using now bidirectionally authenticated | |
| DTLS session. | | |
| | | |
|<--------------------------------------->| |
| Use 6tisch-minimal-security join request |
]]></artwork></figure>
<t>Noteable changes are:</t>
<t><list style="numbers">
<t>no IPv4 support/options.</t>
<t>no mDNS steps, 6tisch only uses Enhanced Beacon</t>
<t>nonce-full option is always mandatory</t>
</list></t>
</section>
<section anchor="architectural-components" title="Architectural Components">
<t>The bootstrap process includes the following architectural components:</t>
<section anchor="pledge" title="Pledge">
<t>The Pledge is the device which is attempting to join. Until the
pledge completes the enrollment process, it has network
connectivity only to the Proxy.</t>
</section>
<section anchor="stateless-ipip-join-proxy" title="Stateless IPIP Join Proxy">
<t>The stateless CoAP or DTLS Proxy provides CoAP or DTLS connectivity
(respectively) between the pledge and the registrar. The stateless CoAP
proxy mechanism is described in <xref target="I-D.ietf-6tisch-minimal-security"/> section 5.1.</t>
<t>The stateless DTLS mechanism is not yet described (TBD).</t>
</section>
<section anchor="domain-registrar" title="Domain Registrar">
<t>The Domain Registrar (having the formal name Join Registrar/
Coordinator (JRC)), operates as a CMC Registrar, terminating the EST
and BRSKI connections. The Registrar is manually configured or
distributed with a list of trust anchors necessary to authenticate
any Pledge device expected on the network. The Registrar
communicates with the Vendor supplied MASA to establish ownership.</t>
<t>The JRC is typically located on the 6LBR/DODAG root, but it may be
located elsewhere, provided IP level connectivity can be established.
The 6LBR may also provide a proxy or relay function to connect to the
actual registrar in addition to the IPIP proxy described above.
The existence of such an additional proxy is a private matter, and this
documents assumes without loss of generality that the registrar is co-located
with the 6LBR.</t>
</section>
<section anchor="manufacturer-service" title="Manufacturer Service">
<t>The Manufacturer Service provides two logically seperate functions: the
Manufacturer Authorized Signing Authority (MASA), and an ownership
tracking/auditing function.
This function is identical to that used by BRSKI, except that
a different format voucher is used.</t>
</section>
<section anchor="public-key-infrastructure-pki" title="Public Key Infrastructure (PKI)">
<t>TBD</t>
</section>
</section>
<section anchor="certificate-time-validation" title="Certificate Time Validation">
<section anchor="lack-of-realtime-clock" title="Lack of realtime clock">
<t>For the constrained situation it is assumed that devices have no real time clock.
These nodes do have access to a monotonically increasing clock that will not
go backwards
in the form of the Absolute Sequence Number.
Synchronization to the ASN is required in
order to transmit/receive data and most nodes will maintain it in hardware.</t>
<t>The heuristic described in BRSKI under this section SHOULD be applied if there
are dates in the CWT format voucher.</t>
<t>Voucher requests SHOULD include a nonce.
For devices intended for off-line deployment,
the vouchers will have been generated in advance and no nonce-ful
operation will not be possible.</t>
</section>
<section anchor="infinite-lifetime-of-idevid" title="Infinite Lifetime of IDevID">
<t>TBD</t>
</section>
</section>
<section anchor="cloud-registrar" title="Cloud Registrar">
<t>In 6tisch, the pledge never has network connectivity until it is enrolled,
so no alternate registrar is ever possible.</t>
</section>
<section anchor="determining-the-masa-to-contact" title="Determining the MASA to contact">
<t>There are no changes from BRSKI: the IDevID provided by the pledge will contain
a MASA URL extension.</t>
</section>
</section>
<section anchor="voucher-request-artifact" title="Voucher-Request artifact">
<t>The voucher-request artifact is defined in
<xref target="I-D.ietf-anima-constrained-voucher"/> section 6.1.</t>
<t>For the 6tisch ZSJ protocol defined in this document, only COSE signed
vouchers as described in <xref target="I-D.ietf-anima-constrained-voucher"/>
section 6.3.2 are supported.</t>
</section>
<section anchor="proxying-details-pledge-proxy-registrar" title="Proxying details (Pledge - Proxy - Registrar)">
<t>The voucher-request artifact is defined in <xref target="I-D.ietf-anima-constrained-voucher"/>.</t>
<t>The 6tisch use of the constrained version differs from the non-constrained version
in two ways:</t>
<t><list style="numbers">
<t>it does not include the pinned-domain-cert, but rather than pinned-domain-subjet-public-key-info entry. This accomodates the use of a raw public key to identify the registrar.</t>
<t>the pledge voucher-request is never signed.</t>
</list></t>
<t>An appendix shows detailed examples of COSE format voucher requests.</t>
</section>
<section anchor="proxy-details" title="Proxy details">
<t>The role of the Proxy is to facilitate communication.
In the constrained situation the proxy needs to be stateless as there is
very little ram to begin with, and none can be allocated to keep state for
an unlimited number of potential pledges.</t>
<section anchor="pledge-discovery-of-proxy" title="Pledge discovery of Proxy">
<t>In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD messages
sent by the proxy. In 6tisch ZSJ, the existence of the proxy is announced
by the Enhanced Beacon message described in
<xref target="I-D.richardson-6tisch-enrollment-enhanced-beacon"/>.
The proxy as described by <xref target="I-D.ietf-6tisch-minimal-security"/> section 10 is
to be used in an identical fashion when EDHOC and OSCOAP are used.</t>
<t>When DTLS security is provided, then the proxy mechanism described in TBD
must be used.</t>
</section>
<section anchor="coap-connection-to-registrar" title="CoAP connection to Registrar">
<t>In BRSKI CoAP is future work. This document represents this work.</t>
</section>
<section anchor="https-proxy-connection-to-registrar" title="HTTPS proxy connection to Registrar">
<t>HTTPS connections are not used between the Pledge, Proxy and Registrar.
The Proxy relays CoAP or DTLS packets and does not interpret or terminate
either CoAP or DTLS connections. (HTTPS is still used between the Registrar
and MASA)</t>
</section>
<section anchor="proxy-discovery-of-registrar" title="Proxy discovery of Registrar">
<t>In BRSKI, the proxy autonomically discovers the Registrar by listening for
GRASP messages.</t>
<t>In the constrained network, the proxies are optionally configured with the
address of the JRC by the Join Response in
in <xref target="I-D.ietf-6tisch-minimal-security"/> section 9.3.2.
(As described in that section, the address of the registrar otherwise defaults to be that of the DODAG root)</t>
<t>Whether or not a 6LR will announce itself as a possible Join Proxy is
outside the scope of this document.</t>
</section>
</section>
<section anchor="protocol-details-pledge-registrar-masa" title="Protocol Details (Pledge - Registrar - MASA)">
<t>BRSKI is specified to run over HTTPS. This document respecifies it to
run over CoAP with either DTLS or EDHOC-provided OSCOAP security.</t>
<t>BRSKI introduces the concept of a provisional state for EST.</t>
<t>The same situation must also be added to DTLS: a situation where the connection is active but the identity of the Registar has not yet been confirmed.
The DTLS MUST validate that the exchange has
been signed by the Raw Public Key that is presented by the Server, even though there is
as yet no trust in that key. Such a key is often available through APIs that provide for
channel binding, such as described in <xref target="RFC5056"/>.</t>
<t>There is an emerging (hybrid) possibility of DTLS-providing the OSCOAP
security, but such a specification does not yet exist, and this document
does at this point specify it.</t>
<t><xref target="I-D.ietf-ace-coap-est"/> specifies that CoAP specifies
the use of CoAP Block-Wise Transfer ("Block") <xref target="RFC7959"/> to fragment
EST messages at the application layer.</t>
<t>BRSKI introduces the concept of a provisional state for EST.
The same situation must also be added to DTLS: a situation where the
connection is active but the identity of the Registar has not yet been confirmed.</t>
<t>The DTLS MUST validate that the exchange has been signed by the
Raw Public Key that is presented by the Server, even though there is
as yet no trust in that key. Such a key is often available through
APIs that provide for channel binding, such as described in <xref target="RFC5056"/>.</t>
<t>As in <xref target="I-D.ietf-ace-coap-est"/>, support for Observe CoAP options <xref target="RFC7641"/> with
BRSKI is not supported in the current BRSKI/EST message flows.</t>
<t>Observe options could be used by the server to notify clients about
a change in the cacerts or csr attributes (resources) and
might be an area of future work.</t>
<t>Redirection as described in <xref target="RFC7030"/> section 3.2.1 is NOT supported.</t>
<section anchor="brski-est-dtls-establishment-details" title="BRSKI-EST (D)TLS establishment details">
<t>6tisch ZSJ does not use TLS. The connection is either CoAP over DTLS,
or CoAP with EDHOC security.</t>
<section anchor="brski-est-coapdtls-estasblishment-details" title="BRSKI-EST CoAP/DTLS estasblishment details">
<t>The details in the BRSKI document apply directly to use of DTLS.</t>
<t>The registrar SHOULD authenticate itself with a raw public key.
A 256 bit ECDSA raw public key is RECOMMENDED.
Pledges SHOULD support EDDSA keys if they contain hardware that supports
doing so efficiently.</t>
<t>TBD: the Pledge needs to signal what kind of Raw Public Key it supports
before the Registrar sends its ServerCertificate. Can SNI be used to do this?</t>
<t>The pledge SHOULD authenticate itself with the built-in IDevID certificate
as a ClientCertificate.</t>
</section>
<section anchor="brski-est-coapedhoc-estasblishment-details" title="BRSKI-EST CoAP/EDHOC estasblishment details">
<t><xref target=" I-D.selander-ace-cose-ecdhe"/> details how to use EDHOC.
The EDHOC description identifiers a party U (the initiator), and
a party V. The Pledge is the party U, and the JRC is the party V.</t>
<t>The communication from the Pledge is via CoAP via the Join Proxy.
The Join proxy relays traffic to the JRC, and using the mechanism
described in <xref target="I-D.ietf-6tisch-minimal-security"/> section 5.1.
This is designed so that the Join Proxy does not need to know if
it is performing the one-touch enrollment described in
<xref target="I-D.ietf-6tisch-minimal-security"/> or the zero-touch enrollment
protocol described in this document. A network could consist of a mix
of nodes of each type.</t>
<t>As generating ephemeral keys is expensive for a low-resource Pledge,
the use of a common E_U by the Pledge for multiple enrollment attempts
(should the first turn out to be the wrong network) is encouraged.</t>
<t>The first communication detailed in <xref target="I-D.ietf-ace-coap-est"/> is to query
the "/.well-known/core" resource to request the Link for EST. This is
where the initial CoAP request is to sent.</t>
<t>The JRC MAY replace it's E_V ephermal key on a periodic basis, or even for every
communication session.</t>
<t>The Pledge's ID_U is the Pledge's IDevID. It is transmitted in an x5bag
<xref target="I-D.schaad-cose-x509"/>. An x5u (URL) MAY be used.
An x5t (hash) MAY also be used and would be the smallest,
but the Registrar may not know where to find the Pledge's IDevID
unless the JRC has been preloaded will all the IDevIDs via out-of-band
mechanism. It is impossible for the Pledge to know if the JRC has
been loaded in such a way so x5t is discouraged for general use.</t>
<t>The JRC's ID_V is the JRC's Raw Public Key. It is transmitted
as a key in COSE's YYY parameter.</t>
<t>The initial Mandatory to Implement (MTI) of an HKDF of SHA2-256, an
AEAD based upon AES-CCM-16-64-128, a signature verification of BBBB, and
signature generation of BBBB. The Pledge proposes a set of algorithms
that it supports, and Pledge need not support more than one combination.</t>
<t>JRCs are expected to run on non-constrained servers, and are expected to
support the above initial MTI, and any subsequent ones that become common.
A JRC SHOULD support all available algorithms for a significant amount of time.
Even when algorithms become weak or suspect, it is likely that it will
still have to perform secure join for older devices. A JRC that responds
to such an older device might not in the end accept the device into the
network, but it is important that it be able to audit the event and
communicate the event to an operator.</t>
<t>While EDHOC supports sending additional data in the message_3, in the
constrained network situation, it is anticipated that the size of the
this message will already be large, and no additional data is to be sent.</t>
<t>A COAP confirmable message SHOULD be used.</t>
<t><xref target="I-D.ietf-6tisch-minimal-security"/> section 6 details how to setup OSCORE
context given a shared key derived by EDHOC.</t>
<t>The registrar SHOULD authenticate itself with a raw public key.</t>
<t>The pledge SHOULD authenticate itself with the built-in IDevID certificate.</t>
</section>
</section>
<section anchor="pledge-requests-voucher-from-the-registrar" title="Pledge Requests Voucher from the Registrar">
<t>The voucher request and response as defined by BRSKI is modified slightly.</t>
<t>In order to simplify the pledge, the use of a certificate (and chain) for the
Registrar is not supported. Instead the newly
defined pinned-domain-subject-public-key-info must contain the (raw) public key
info for the Registrar. It MUST be byte for byte identical to that
which is transmitted by the Registrar during the TLS ServerCertificate handshake.</t>
<t>BRSKI permits the voucher request to be signed or unsigned. This document defines the
voucher request to be unsigned.</t>
</section>
<section anchor="brski-masa-tls-establishment-details" title="BRSKI-MASA TLS establishment details">
<t>There are no changes. The connection from the Registrar to MASA is still HTTPS.</t>
</section>
<section anchor="registrar-requests-voucher-from-masa" title="Registrar Requests Voucher from MASA">
<t>There are no change from BRSKI, as this step is between two non-constrained devices.</t>
<t>The format of the voucher is COSE, which implies changes to both the Registrar and
the MASA,
but semantically the content is the same.</t>
<t>The format of the voucher is COSE, which implies changes to both the
Registrar and the MASA, but semantically the content is the same.</t>
<t>The manufacturer will know what algorithms are supported by the pledge, and
will issue a 406 (Conflict) error to the Registrar if the Registar's public key
format is not supported by the pledge. It is however, too late for the
Registar to use a different key, but at least it can log a reason for a failure.
It is likely that the ZSJ-BRSKI-EST connection has already failed, and this
step is never reached.</t>
<section anchor="masa-renewal-of-expired-vouchers" title="MASA renewal of expired vouchers">
<t>There are assumed to be no useful real-time clocks on constrained devices, so all
vouchers are in effect infinite duration. Pledges will use nonces for freshness,
and a request for a new voucher with a new voucher for the same Registrar
is not unusual. A token-bucket system SHOULD be used such that no more than
24 vouchers are issued per-day, but more than one voucher can be issued
in a one hour period. Tokens should not accumulate for more than one day!</t>
</section>
<section anchor="masa-verification-of-voucher-request-signature-consistency" title="MASA verification of voucher-request signature consistency">
<t>The voucher-request is signed by the Registrar using it's Raw Public Key.
There is no additional certificate authority to sign this key. The MASA
MAY have this key via sales-channel integration, but in most cases it will
be seeing the key for the first time.</t>
<t>XXX-should the TLS connection from Registrar to MASA have a ClientCertificate?
If so, then should it use the same Public Key? Or a different one?</t>
</section>
<section anchor="masa-authentication-of-registrar-certificate" title="MASA authentication of registrar (certificate)">
<t>IDEA: The MASA SHOULD pin the Raw Public Key (RPK) to the IP address that was first
used to make a request with it. Should the RPK <-> IP address relationship
be 1:1, 1:N, N:1? Should we take IP address to mean, "IP subnet", essentially
the IPv4/24, and IPv6/64? The value of doing is about DDoS mitigation?</t>
<t>Should above mapping be on a per-Pledge basis?</t>
</section>
<section anchor="masa-revocation-checking-of-registrar-certificate" title="MASA revocation checking of registrar (certificate)">
<t>As the Registrar has a Raw Public Key as an identity, there is no meaningful
standard revocation checking that can be done. The MASA SHOULD have
a blacklist table, and a way to add entries, but this process is out of scope.</t>
</section>
<section anchor="masa-verification-of-pledge-prior-signed-voucher-request" title="MASA verification of pledge prior-signed-voucher-request">
<t>The MASA will know whether or not the Pledge is capable of producing a
signed voucher-request for inclusion by the Registrar. In the case where
the Pledge can sign the voucher-request to the Registrar, then the
Registrar will have put it in the 'prior-signed-voucher-request'.
The MASA can verify the signature from the Pledge using the MASA's copy
of the Pledge's IDevID public key.</t>
<t>In many cases, the Pledge will not be capable of doing signatures in real time,
so no 'prior-signed-voucher-request' will be present.
The MASA will have rely on the audit log as a history function to determine
if the Pledge has previously been claimed, and to identify situations where
the claim from the Registrar is fraudulent.</t>
</section>
<section anchor="masa-pinning-of-registrar" title="MASA pinning of registrar">
<t>When the MASA creates a voucher, it puts the Registrar's Raw Public Key
into the 'pinned-domain-subject-public-key-info' leaf of the voucher.</t>
<t>The MASA does not include the 'pinned-domain-cert' field.</t>
</section>
<section anchor="masa-nonce-handling" title="MASA nonce handling">
<t>Use of nonces is highly RECOMMENDED, but there are situations where not all
components are connected at the same time in which the nonce will not be present.</t>
<t>There are no significant changes from BRSKI.</t>
</section>
</section>
<section anchor="masa-voucher-response" title="MASA Voucher Response">
<t>As exaplained in <xref target="I-D.ietf-anima-constrained-voucher"/> section 6.3.2, when a
voucher is returned by the MASA to the JRC, a public key or certificate container
that will verify the voucher SHOULD also be returned.</t>
<t>In order to do this, the MASA MAY return a multipart/related return, within that
body, two items SHOULD be returned:</t>
<t><list style="numbers">
<t>An application/voucher-cose+cbor body.</t>
<t>An application/pkcs7-mime; smime-type=certs-only, or an application/SOMETHING containing a Raw Public Key.</t>
</list></t>
<t>A MASA is not obligated to return the public key, and MAY return only the
application/voucher-cose+cbor object. In that case, the JRC will be unable to
validate it.</t>
<section anchor="pledge-voucher-verification" title="Pledge voucher verification">
<t>The Pledge receives the voucher from the Registrar over it's CoAP connection.
It verifies the signature using the MASA anchor built in, as in the BRSKI case.</t>
</section>
<section anchor="pledge-authentication-of-provisional-tls-connection" title="Pledge authentication of provisional TLS connection">
<t>The BRSKI process uses the pinned-domain-cert field of the voucher to
validate the registrar's ServerCertificate. In the ZeroTouch case, the
voucher will contain a pinned-domain-subject-public-key-info field containing
the raw public key of the certificate. It should match, byte-to-byte
with the raw public key ServerCertificate.</t>
</section>
</section>
<section anchor="pledge-voucher-status-telemetry" title="Pledge Voucher Status Telemetry">
<t>The voucher status telemetry report is communicated from the pledge to
the registrar over CoAP channel. The shortened URL is as described in table QQQ.</t>
</section>
<section anchor="registrar-audit-log-request" title="Registrar audit log request">
<t>There are no changes to the Registrar audit log request.</t>
<section anchor="masa-audit-log-response" title="MASA audit log response">
<t>There are no changes to the MASA audit log response.</t>
</section>
<section anchor="registrar-audit-log-verification" title="Registrar audit log verification">
<t>There are no changes to how the Registrar verifies the audit log.</t>
</section>
</section>
<section anchor="est-integration-for-pki-bootstrapping" title="EST Integration for PKI bootstrapping">
<t>TBD.</t>
<section anchor="est-distribution-of-ca-certificates" title="EST Distribution of CA Certificates">
<t>TBD.</t>
</section>
<section anchor="est-csr-attributes" title="EST CSR Attributes">
<t>In 6tisch, no Autonomic Control Plane will be created, so none of the
criteria for SubjectAltname found in <xref target="I-D.ietf-anima-autonomic-control-plane"/>
apply.</t>
<t>The CSR Attributes request SHOULD NOT be performed.</t>
</section>
<section anchor="est-client-certificate-request" title="EST Client Certificate Request">
<t>6tisch will use a certificate to:</t>
<t><list style="numbers">
<t>to authenticate an 802.15.9 key agreement protocol.</t>
<t>to terminate an incoming DTLS or EDHOC key agreement as part of application data protection.</t>
</list></t>
<t>It is recommended that the requested subjectAltName contain only the
<xref target="RFC4514"/> hwSerialNum.</t>
</section>
<section anchor="enrollment-status-telemetry" title="Enrollment Status Telemetry">
<t>There are no changes to the status telemetry between Registrar and MASA.</t>
</section>
<section anchor="multiple-certificates" title="Multiple certificates">
<t>Multiple certificates are not supported.</t>
</section>
<section anchor="est-over-coap" title="EST over CoAP">
<t>This document and <xref target="I-D.ietf-ace-coap-est"/> detail how to run EST over CoAP.</t>
</section>
</section>