-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdtsecurity-zerotouch-join-01.txt
1848 lines (1211 loc) · 67.4 KB
/
dtsecurity-zerotouch-join-01.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
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
6tisch Working Group M. Richardson
Internet-Draft Sandelman Software Works
Intended status: Informational B. Damm
Expires: May 5, 2018 Silver Spring Networks
November 01, 2017
6tisch Zero-Touch Secure Join protocol
draft-ietf-6tisch-dtsecurity-zerotouch-join-01
Abstract
This document describes a zero-touch 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 her is an augmentation to the
one-touch mechanism described in [I-D.ietf-6tisch-minimal-security].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 5, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Richardson & Damm Expires May 5, 2018 [Page 1]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scope of solution . . . . . . . . . . . . . . . . . . . . 6
1.3. Leveraging the new key infrastructure / next steps . . . 6
1.3.1. Key Distribution Process . . . . . . . . . . . . . . 7
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 7
2.1. Behaviour of a Pledge . . . . . . . . . . . . . . . . . . 7
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 9
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 9
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Architectural component: Pledge . . . . . . . . . . . 11
2.4.2. Architectural component: Stateless IPIP Proxy . . . . 12
2.4.3. Architectural component: Domain Registrar . . . . . . 12
2.4.4. Architectural component: Vendor Service . . . . . . . 12
2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 12
2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 13
2.7. Determining the MASA to contact . . . . . . . . . . . . . 13
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 13
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13
3.2. SID values . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14
4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 16
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 16
4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 16
4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 16
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 16
5.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 17
5.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 17
5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 18
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 18
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 18
5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 18
5.5.1. Completing authentication of Provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 18
5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 18
5.7. MASA authorization log Request . . . . . . . . . . . . . 19
5.7.1. MASA authorization log Response . . . . . . . . . . . 19
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 19
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 19
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 19
Richardson & Damm Expires May 5, 2018 [Page 2]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
5.8.3. EST Client Certificate Request . . . . . . . . . . . 19
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 19
5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 19
6. Reduced security operational modes . . . . . . . . . . . . . 19
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Pledge security reductions . . . . . . . . . . . . . . . 19
6.3. Registrar security reductions . . . . . . . . . . . . . . 20
6.4. MASA security reductions . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. MIME-Type Registry . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Security of MASA voucher signing key(s) . . . . . . . . . 20
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Privacy Considerations for Production network . . . . . 20
10.2. Privacy Considerations for New Pledges . . . . . . . . . 20
10.2.1. EUI-64 derived address for join time IID . . . . . . 21
10.3. Privacy Considerations for Join Proxy . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 27
A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 27
A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 27
A.1.2. Factory provided credentials (if any) . . . . . . . . 27
A.1.3. Credentials to be introduced . . . . . . . . . . . . 27
A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 28
A.2.1. Security above and below IP . . . . . . . . . . . . . 28
A.2.2. Join network assumptions . . . . . . . . . . . . . . 29
A.2.3. Number and cost of round trips . . . . . . . . . . . 29
A.2.4. Size of packets, number of fragments . . . . . . . . 29
A.3. Target end-state for join process . . . . . . . . . . . . 29
Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 30
B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 30
B.2. Provisional Enrollment process . . . . . . . . . . . . . 31
Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 32
Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 32
D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 32
D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 33
D.1.2. Registrar Discovery Protocol Details . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
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
Richardson & Damm Expires May 5, 2018 [Page 3]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
human resources issue, as well as the difficulty in getting
consistent results.
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.
This document is a constrained profile of
[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 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 ANIMA's BRSKI, 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.
This document builds upon the "one-touch" provisioning described in
[I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request
mechanism when appropriate. In addition, it uses the CoAP adaption
of EST defined in [I-D.vanderstok-ace-coap-est] in an identical way.
Otherwise, this document follows BRSKI with the following high-level
changes:
o HTTP is replaced with CoAP.
o TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/
OSCOAP+CoAP
o the domain-registrar anchor certificate is replaced with a Raw
Public Key (RPK) using [RFC7250].
o the PKCS7 signed JSON voucher format is replaced with CWT
o the GRASP discovery mechanism for the Proxy is replaced with an
announcement in the Enhanced Beacon
[I-D.richardson-6tisch-join-enhanced-beacon]
Richardson & Damm Expires May 5, 2018 [Page 4]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
o 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.
o real time clocks are assumed to be impossible, so expiry dates in
ownership vouchers are never used
o nonce-full vouchers are encouraged, but off-line nonce-less
operation is also supported
802.1AR Client certificates are retained, but optionally are
specified by reference rather than value.
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.
1.1. Terminology
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
[RFC2119] and indicate requirement levels for compliant STuPiD
implementations.
The reader is expected to be familiar with the terms and concepts
defined in [I-D.ietf-6tisch-terminology], [RFC7252],
[I-D.ietf-core-object-security], and
[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:
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.
Joined Node the prospective device, after having completing the join
process, often just called a Node.
Join Proxy (JP): a stateless relay that provides connectivity
between the pledge and the join registrar/coordinator.
Join Registrar/Coordinator (JRC): central entity responsible for
authentication and authorization of joining nodes.
Richardson & Damm Expires May 5, 2018 [Page 5]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
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.
Ownership Voucher A signed voucher from the vendor vouching that a
specific domain "owns" the new entity as defined in
[I-D.ietf-anima-voucher].
MIC manufacturer installed certificate. An [ieee802-1AR] identity.
Not to be confused with a (cryptographic) "Message Integrity
Check"
1.2. Scope of solution
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.
BRSKI describes a more general, more flexible approach for
bootstrapping devices into an ISP or Enterprise network.
[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.
1.3. Leveraging the new key infrastructure / next steps
In constrained networks, it is unlikely that an ACP be formed. This
document does not preclude such a thing, but it is not mandated.
The resulting secure channel MAY be used just to distribute network-
wide keys using a protocol such as
[I-D.ietf-6tisch-minimal-security]. (XXX - do we need to signal this
somehow?)
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}.
Richardson & Damm Expires May 5, 2018 [Page 6]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
1.3.1. Key Distribution Process
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 [I-D.richardson-6tisch-minimal-rekey].
2. Architectural Overview
Section 2 of BRSKI has a diagram with all of the components shown
together. There are no significant changes to the diagram.
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.
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)
2.1. Behaviour of a Pledge
The pledge goes through a series of steps which are outlined here at
a high level.
Richardson & Damm Expires May 5, 2018 [Page 7]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
+--------------+
| Factory |
| default |
+------+-------+
|
+------v-------+
| Discover |
+------------> |
| +------+-------+
| |
| +------v-------+
| | Identity |
^------------+ |
| rejected +------+-------+
| |
| +------v-------+
| | Request |
| | Join |
| +------+-------+
| |
| +------v-------+
| | Imprint | Optional
^------------+ <--+Manual input (Appendix C)
| Bad Vendor +------+-------+
| response | send Voucher Status Telemetry
| +------v-------+
| | Enroll |
^------------+ |
| Enroll +------+-------+
| Failure |
| +------v-------+
| | Enrolled |
^------------+ |
Factory +--------------+
reset
State descriptions for the pledge are as follows:
1. Discover a communication channel to a Registrar. This is done by
listening for beacons as described by
[I-D.richardson-anima-6join-discovery]
2. 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).
Richardson & Damm Expires May 5, 2018 [Page 8]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
The registrar identifies itself using a raw public key, while the
the pledge identifies itself to the registrar using an IDevID
credential.
3. Requests to Join the discovered Registrar. A unique nonce can be
included ensuring that any responses can be associated with this
particular bootstrapping attempt.
4. 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.
5. 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) [RFC7030].
6. 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.
2.2. Secure Imprinting using Vouchers
As in BRSKI, the format and cryptographic mechansim of vouchers is
described in detail in [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
[I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it.
2.3. Initial Device Identifier
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.
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) as SHOULD-, while newer devices SHOLD+ begin to appear
using EdDSA curves using the 25519 curves. (EDNOTE details here)
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.
Richardson & Damm Expires May 5, 2018 [Page 9]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
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.
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.
There are a number of security concerns with use of a single MASA
signing key, and section Section 9.1 addresses some of them with some
operational suggestions.
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.
The use of the MASA-URL extension is encouraged if the certificate is
sent at all.
EDNOTE: here belongs text about sending only a reference to the
IDevID rather than the entire certificate
2.4. Protocol Flow
The diagram from BRSKI is reproduced with some edits:
+--------+ +---------+ +------------+ +------------+
| Pledge | | IPIP | | Domain | | Vendor |
| | | Proxy | | Registrar | | Service |
| | | | | | | (Internet |
+--------+ +---------+ +------------+ +------------+
| | | |
|<-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---------->| |
Richardson & Damm Expires May 5, 2018 [Page 10]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
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. | | |
| | | |
| | | |
| | | |
Noteable changes are:
1. no IPv4 support/options.
2. no mDNS steps, 6tisch only uses Enhanced Beacon
3. nonce-full option is always recommended
2.4.1. Architectural component: Pledge
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.
Richardson & Damm Expires May 5, 2018 [Page 11]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
2.4.2. Architectural component: Stateless IPIP Proxy
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
[I-D.ietf-6tisch-minimal-security] section 5.1. The stateless DTLS
mechanism is not yet described (XXX).
2.4.3. Architectural component: Domain Registrar
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.
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.
2.4.4. Architectural component: Vendor Service
The Vendor 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.
2.5. Lack of realtime clock
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.
The heuristic described in BRSKI under this section SHOULD be applied
if there are dates in the CWT format voucher.
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.
Richardson & Damm Expires May 5, 2018 [Page 12]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
2.6. Cloud Registrar
In 6tisch, the pledge never has network connectivity until it is
enrolled, so no alternate registrar is ever possible.
2.7. Determining the MASA to contact
There are no changes from BRSKI: the IDevID provided by the pledge
will contain a MASA URL extension.
3. Voucher-Request artifact
As in BRSKI, a voucher-request artifact is derived from the base
voucher definition. The constrained version differs from the non-
constrained version in two ways:
1. 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.
2. the pledge voucher-request is never signed.
An appendix shows detailed examples of CWT format voucher requests.
3.1. Tree Diagram
module: ietf-cwt-voucher-request
grouping voucher-request-cwt-grouping
+---- voucher
+---- created-on yang:date-and-time
+---- expires-on? yang:date-and-time
+---- assertion enumeration
+---- serial-number string
+---- idevid-issuer? binary
+---- pinned-domain-cert binary
+---- domain-cert-revocation-checks? boolean
+---- nonce? binary
+---- last-renewal-date? yang:date-and-time
+---- proximity-registrar-subject-public-key-info? binary
3.2. SID values
Richardson & Damm Expires May 5, 2018 [Page 13]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
SID experimental base 60100 is used for voucher-requests.
dictionary keys are:
60100 ietf-cwt-voucher
60101 assertion
60102 created-on
60103 domain-cert-revocation-checks
60104 expires-on
60105 idevid-issuer
60106 last-renewal-date
60107 nonce
60108 pinned-domain-cert
60109 pinned-domain-subject-public-key-info
60110 prior-signed-voucher
60111 serial-number
60112 proximity-registrar-cert
60113 proximity-registrar-subject-public-key-info
60100 ietf-cwt-voucher-request
3.3. YANG Module
/* -*- c -*- */
module ietf-cwt-voucher-request {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request";
prefix "vcwt";
import ietf-restconf {
prefix rc;
description
"This import statement is only present to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
import ietf-voucher {
prefix "v";
}
organization
"IETF 6tisch Working Group";
Richardson & Damm Expires May 5, 2018 [Page 14]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
contact
"WG Web: <http://tools.ietf.org/wg/6tisch/>
WG List: <mailto:6tisch@ietf.org>
Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>";
description
"This module defines the format for a voucher, which is produced by
a pledge's manufacturer or delegate (MASA) to securely assign one
or more pledges to an 'owner', so that the pledges may establish a
secure connection to the owner's network infrastructure.
This version provides a very restricted subset appropriate
for very constrained devices.
In particular, it assumes that nonce-ful operation is
always required, that expiration dates are rather weak, as no
clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
the module text are to be interpreted as described in RFC 2119.";
revision "YYYY-MM-DD" {
description
"Initial version";
reference
"RFC XXXX: Voucher Profile for Constrained Devices";
}
// Grouping defined for future usage
grouping voucher-request-cwt-grouping {
description
"Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping {
augment "voucher" {
description "Base the CWT voucher-request upon the regular one";
leaf proximity-registrar-subject-public-key-info {
type binary;
description
"The proximity-registrar-subject-public-key-info replaces the
proximit-registrar-cert in constrained uses of
the voucher-request.
The proximity-registrar-subject-public-key-info is the
Raw Public Key of the Registrar. This field is encoded
as specified in RFC7250, section 3.
The ECDSA algorithm MUST be supported.
Richardson & Damm Expires May 5, 2018 [Page 15]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
The EdDSA algorithm as specified in
draft-ietf-tls-rfc4492bis-17 SHOULD be supported.
Support for the DSA algorithm is not recommended.
Support for the RSA algorithm is a MAY.";
}
}
}
}
}
This definition, translated via the rules in
[I-D.ietf-core-yang-cbor] uses the
4. Proxy details
The role of the Proxy is to facilitate communication. In the
constrained situation the proxy needs to be stateless.
4.1. Pledge discovery of Proxy
In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD
messages sent by the proxy. In 6tisch-zero-touch, the existence of
the proxy is related by the Enhanced Beacon.
4.2. CoAP connection to Registrar
In BRSKI CoAP is future work. This document represents this work.
4.3. HTTPS proxy connection to Registrar
HTTPS connections are not used.
4.4. Proxy discovery of Registrar
In BRSKI, the proxy autonomically discovers the Registrar by
listening for GRASP messages. In the constrained network, the
proxies are optionally configured with the address of the registrar
by the Join Response in [I-D.ietf-6tisch-minimal-security] section
XX. The address of the registrar otherwise defaults to be that of
the DODAG root.
5. Protocol Details
BRSKI is specified to run over HTTPS. This document respecifies it
to run over CoAP with either DTLS or EDHOC-provided OSCOAP security.
There is an emerging (hybrid) possibility of DTLS-providing the
OSCOAP security, but such a specification does not yet exist.
Richardson & Damm Expires May 5, 2018 [Page 16]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
[I-D.vanderstok-ace-coap-est] specifies that CoAP specifies the use
of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST
messages at the application layer.
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. 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 [RFC5056].
As in [I-D.vanderstok-ace-coap-est], support for Observe CoAP options
[RFC7641] with BRSKI is not supported in the current BRSKI/EST
message flows. 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.
Redirection as described in [RFC7030] section 3.2.1 is NOT supported.
5.1. BRSKI-EST (D)TLS establishment details
Zerotouch Join does not use TLS. The connection is either CoAP over
DTLS, or CoAP with EDHOC security.
5.1.1. BRSKI-EST CoAP/DTLS estasblishment details
The details in the BRSKI document apply directly to use of DTLS.
The registrar SHOULD authenticate itself with a raw public key.
The pledge SHOULD authenticate itself with the built-in IDevID
certificate.
5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details
[I-D.ietf-6tisch-minimal-security] section YYY details how to setup
EDHOC.
The registrar SHOULD authenticate itself with a raw public key.
The pledge SHOULD authenticate itself with the built-in IDevID
certificate.
Richardson & Damm Expires May 5, 2018 [Page 17]
Internet-Draft 6tisch Zero-Touch Secure Join protocol November 2017
5.2. Pledge Requests Voucher from the Registrar
The voucher request and response as defined by BRSKI is modified
slightly.
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.
BRSKI permits the voucher request to be signed or unsigned. This
document defines the voucher request to be unsigned.
5.3. BRSKI-MASA TLS establishment details
There are no changes. The connection from the Registrar to MASA is
still HTTPS.
5.4. Registrar Requests Voucher from MASA
There are no change from BRSKI, as this step is between two non-
constrained devices. The format of the voucher is CWT, which implies
changes to both the Registrar and the MASA, but semantically the
content is the same.
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.
5.5. Voucher Response
The format of the voucher is CWT as described in section YYY.
5.5.1. Completing authentication of Provisional TLS connection
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.
5.6. Voucher Status Telemetry