-
Notifications
You must be signed in to change notification settings - Fork 5
/
shepherd-review-2-discuss.txt
8952 lines (7441 loc) · 401 KB
/
shepherd-review-2-discuss.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
From anima-bounces@ietf.org Wed Feb 14 02:09:37 2018
Return-Path: <anima-bounces@ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
faui40.informatik.uni-erlangen.de
X-Spam-Level:
X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_SIGNED=0.1,
DKIM_VALID=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.249,RCVD_IN_DNSWL_MED=-2.3,
RCVD_IN_MSPIKE_H2=-0.001,T_RP_MATCHES_RCVD=-0.01 autolearn=disabled
version=3.4.0
X-Original-To: eckert+ietf.anima@i4.informatik.uni-erlangen.de
Delivered-To: eckert+ietf.anima@i4.informatik.uni-erlangen.de
Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 21D2E58C4FF;
Wed, 14 Feb 2018 02:09:37 +0100 (CET)
Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 40E1774E205;
Wed, 14 Feb 2018 02:09:31 +0100 (CET)
Received: from ietfa.amsl.com (localhost [IPv6:::1])
by ietfa.amsl.com (Postfix) with ESMTP id 2410912EABF;
Tue, 13 Feb 2018 17:09:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
t=1518570569; bh=rmWTp/wX4rQusjhzHjEAsW5KyY5LCmPtyR3G6RAlLH8=;
h=Date:From:To:Subject:List-Id:List-Unsubscribe:List-Archive:
List-Post:List-Help:List-Subscribe:Cc;
b=Vnctdbrk3N3DuT1R9oEBSrVudruuebP31zsPGgg7ms1HzRB9VVm7r/L4LaYSImbvM
cFIvFbbRPRt2T8Hgj2YQ/ci9B0/5SwNGYiIPrQOYFwlpFgSw9TyIWUHaoVYKOHEaMw
q5mFH4CDQ44qYJrX3Z0ywMZxs19V4UJcJCNLK8nE=
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id AAD4112DA22;
Tue, 13 Feb 2018 17:09:26 -0800 (PST)
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fnUk7EhJfGzh; Tue, 13 Feb 2018 17:09:18 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de
(faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 4722012D944;
Tue, 13 Feb 2018 17:09:18 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de
(faui40p.informatik.uni-erlangen.de [131.188.34.77])
by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 75EF358C4FF;
Wed, 14 Feb 2018 02:09:10 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463)
id 609F1B0DA58; Wed, 14 Feb 2018 02:09:10 +0100 (CET)
Date: Wed, 14 Feb 2018 02:09:10 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: draft-ietf-anima-bootstrapping-keyinfra@ietf.org
Message-ID: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Cu4au3RwjJ5RpunVAkH8LcXnlYA>
Subject: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>,
<mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>,
<mailto:anima-request@ietf.org?subject=subscribe>
Cc: anima@ietf.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: anima-bounces@ietf.org
Sender: "Anima" <anima-bounces@ietf.org>
X-Virus-Scanned: clamav-milter 0.99.3 at faui45
X-Virus-Status: Clean
Status: O
Content-Length: 88239
Lines: 1863
Shepherd review against -09.
Did just browse through -10, i think it is orthogonal to the comments below.
Document is IMHO overall in very good shape!
Sorry for length, but i was trying to minimize the number of RTT to resolve comments
by trying to explain my comments as good as possible.
In many cases this resulted
in proposing text to better explain something where i wasn't even sure if i undersstood
it correctly. In those cases the texte is always a suggestion, but the ask is
to provide appropriate explanation of the subject matter.
Let me know if/how i can help getting the comments applied.
Cheers
Toerless
---------------------------------------------------------------------------------------
1.2) Terminology:
a) vendor vs. manufacturer.
The document uses 48 times "vendor" and 13 times "manufacturer". Please
revisit this: If there is a clear reason when/why to use vendor and when/why
to use the term "manufacturer", then please put these explanations into
terminology. Otherwise maybe eliminate "vendor".
For example: Abstract: "using vendor installed X.509 certificate" ...
"vendor's authorizing service". This latter one definitely seems to be
wrong (MASA = "manufacturer authorizied..., not vendor).
b) Key infrastructure
There is no definition/reference for this term. Please describe on
first use and in terminology. Is there a difference
between "key infrastructure" and "keying material" ? If not, then
maybe remove one term otherwise pls. describe difference.
c) (terminology) MASA definition: "A third-party Manufacturer...". Why "third-party" ?
who are the first two parties ? If this is only slang and we can't explain who the
first two parties are, delete "third-party" ?
d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text mostly
uses "Domain Registrar" and very seldom "Join Registar".
JRC is used in exactly three places in the draft. I also can not find on www.google.com
or wikipedia any example of "The term JRC is used in common with other bootstrap
mechanisms" as the Terminology claims. Either provide a non-anima reference for the
use of that term or eliminate it in the document.
Suggest to use "(Domain Join) Registar (and Coordinator) in 1.2 and say for example
that the text uses "Join Registrar" when referring to the mechanics of building the
connection (Join Proxy and Join Registrar) and Domain Registrar when discussing
authentication and any other aspects of the registrar (where the domain is relevant).
e) Voucher
- misses ":" after term.
- please change "statement" to "artifact" so the terminology aligns with both voucher
draft and voucher-request text which also uses artifact. See also section 2.2
where you use "cryptographically protected" instead of "signed" and figure out
which term you want to use in all cases (hint: signed).
f) IMPORTANT: Please add/define the term "ANI"
ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and
Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI
systems (pledges, proxies, registrar) have specific requirements detailled in
the document.
Without this term we can not nail down the explicit requirements against
ANI Pledges, Proxies, Registrars that we need from the document (and distinguish
from requirements against any non-ANI adaptation of BRSKI). I added according
comments into other parts of the doc.
g) Please replace "MASA server" with "MASA service" everywhere.
-----------------------------------------------------------------------------
Overall:
a) Requirements about EST:
- The introduction says: "Integration with a complete EST enrollment is
optional but trivial"
- 5.8.3 says "The Pledge MUST request a new client certificate".
- 1.4 says "bootstrapped devices have a common trust anchor and a certificate
has optionally been issued from a local PKI
a) The text needs to be made consistent across all places where requirements
are defined. I have in general no strong opinion how "optional" the text should
say EST operations are, BUT consider he following points:
b) We need a complete list of BRSKI requirements for ANI devices, where EST
operation requirements are made stronger. I suggest a separate subsection at an
appropriate place so that "ANI requirements" shows up in the table of contents:
Section X.Y.Z Requirements for ANI devices:
For BRSKI on ANI Devices (ANI = BRSKI + ACP), EST operations is mandator.
The ANI pledge MUST perform
- "CA Certificates Request",
- "CSR Attributes"
- "Client Certificate Request"
- "Enrollment status Telemetry"
The ANI registrar MUST support BRSKI and these EST operations.
All ANI devices SHOULD support the BRSKI proxy function.
c) If EST operations are optional, how about the following considerations:
I) In instances of BRSKI where no EST operations happens after bootstrap, the
Pledge only has trust anchors, but no certificate. This may still be useful,
but today i think this is not really a considered option at all:
After receipt of the voucher, the pledge is willing to do some action on behalf
of the BRSKI connection it was previously unwilling to - e.g: receive & apply config.
(i thought Max never liked this idea..., so if it is off the table, then
_some_ subset of EST seems mandatory because EST operations is the only thing
alowed after receiving a voucher that Ma would like.... unless Max has changed
his opinion).
II) This leaves the option that EST to install trust anchor is mandatory, but
enrolment with a certificate is optional (except for ANI case).
Aka: would be good to write a sentence/paragraph exactly outlining what is
permitted to happen after a voucher and if any, what parts of EST are deemed to
be necessary by BRSKI (outside of ANI devices. the requirements for ANI devices
are listed above).
-----------------------------------------------------------------------------
1.) Introduction
a) The intro of 1. is somehat confusing to the uninitiated.
Suggest the followinf replacement text for two paragraps:
BRSKI provides a solution for secure zero-touch (automated) bootstrap of
virgin (untouched) devices that are called Pledges in this document. These Pledges
need to discover (or be discovered by) an element of the network domain to which the
Pledge belongs to perform the bootstrap. This element (device) is called the
(Domain Join) Registrar. Before any other operation, Pledge and Registrar need to
establish mutual trust:
Then the four existing bullet points, but number them.
Then followed by th following paragraph to replace the existing paragraph after
the four bullet poins.
This document details protocols and messages to answer the above questions.
It uses a TLS connection and an X.509 certificate
(LDevID) of the Pledge to answer points 1 and 2. It uses a new artefact
called a "voucher" that the registrar receives from a
"Manufacturer Authorized Signing Authority" and passes to the Pledge to answer
points 3 and 2.
b) It would be nice to have a paragraph mentioning the proxy as a mean to
provide easier connectivity for Pledges (no need for full network connectivity).
-----------------------------------------------------------------------------
1.1)
a) "other Bootstrapping Approaches": "other" -> "prior" or "existing" ?
b) "_or_ that domain-specific keying material". Is this not an _and_ ?
c) "in a costly and non-scaleable manner". "non-scaleable" may be hard to
argue. Whole economies where built on manual labor. Might rather use
qualifiers such as "little or not at all automated", "error-prone" and/or
referring to physical security (.e.g: trusted pre-staging location).
d) "existing mechanisms" -> "existing automated mechanisms".
e) Paragraph 2 and following about EST: The first two sentences sound
contradictory/conflicting. "...minimize user action..." , "details a set of
non-autonomic bootstrapping methods". Suggest text like:
"EST does reduce user actions during bootstrap but does not provide
solutions for how the following protocol steps can be made autonomic
(not involving user actions).
(Note: first use of "autonomic" here, so an explanation like "not
involving user action" is required (any other definition here what autonomic
or non-autonomic means in the context of this document is fine too,
"not involving user action" is just a suggestion).
-----------------------------------------------------------------------------
1.3)
a) The order of paragraphs is confusing. Even if the mayority of readers
(which i don't think) would primarily be interested in class 1 devices,
it is irritating in style and context to start with the first two
paragraphs.
I would suggest to start with existing paragraph 3, change maybe the
sentence to "This solution (BRSKI) can support large router platforms..."
Then insert the first two paragraphs after current paragraph 5. All the
text after paragraph 5 already discusses constrained situations so
it would nicely follow on to the first two paragraphs.
b) paragraph 5 is confusing: What is a handoff, why would somebody
even think to apply BRSKI in a handoff, and why is there a normative,
capital letter SHOULD. Here is how i would write it more explanatory
(if i understand the implied use case correctly):
BRSKI could be used by nomadic or mobile devices to aquire certificates
used as credentials to access the network at the new location. This
is usually called handoff. Nevertheless, BRSKI is not intended for low-latency
handoff which is usually a requirement in mobility solutions (e.g.: seamless
handover). For these solutions BRSKI could be used to aquire keying
material and re-use that during handover without re-initiating BRSKI
during handover later on.
(which is also implying that re-using BRSKI in nomadic environments
is not off the table, but not saying so explicitly because we really
have not thought that trough a lot).
c) It would loosen up a very long section to create three subsection headings
- supported environments
- constrained envionments
- network access control
-----------------------------------------------------------------------------
Section 2 1)
a) ..Each component is logical and may be combined with other components as necessary..
Ok. I always want the pledge to live in the same device as the MASA.
Would suggest deleting that sentence. More harm than benefit.
b) I suggest to move section 2.4 up to become section 2.1) directly after the
picture in section 2., because otherwise there is no explanaction following
the picture.
c) "The a domain" (delete a)
-----------------------------------------------------------------------------
Section 2.1
a) The term "Request Join" is only used here, and its IMHO not very logical
(disclaimer: toerless: en.wikipedia.org/wiki/ESL). It sounds to me like the
pledge says "i want to join". And also sounds as if the pledge could be
disappointed if rejected. I would rather call it "Domain membership inquiry".
Or if you're hooked up on the term "joining", then maybe "Join Inquiry".
Whatever best makes it clear that rejection is a perfect and important
outcome option.
b) Please see my issue section 5.1 a). If you agree with that statement, then there
should be no "rejected" arrow in Figure 2 coming out of the "Identify" block.
I would also suggest that the "Bad Vendor response" arrow does not come out
of the "Imprint" block but out of the "Request Join" block. AFAIK, this is
an error reply to the Request Voucher, so it happens before imprinting
(imprinting happens only when there is a vocker reply. AFAIK).
I don't think "Bad Vendor reply" in Figure 2 is a good term. Most logical to me would
be "Error or not member". In any case, the text in section 2 below should
mention the exact words used on the labels, the text is missing ll the
labels on the left: "Factory reset", "Enroll Failure", "Bad Vendor response",...
c)
Point 1 nicely explains how this is done during TLS.
Likewise, Point 2 should mention that this is the "Voucher Request", and
Point 3 should mention that it is the "Voucher Reply" - so readers can match
up section 2.1 with the rest of the document.
remove the "e.g." from "protocol, e.g. Enrollment over". Otherwise some text
outlining when something else than EST is to be used. (see next comment).
d)
I am missing in the initial chapters a succinct summary how EST enrollment is optional and
what can be achieved with/without it, there is only some side sentences later in the
EST sections. I would suggest to insert such an explanation here.
After point 4 insert (unnumbered) paragraph:
| After step 4, the pledge has received and authenticated an explicit TA (trust anchor)
| (pinned-domain-cert in the Voucher response). In some use cases this may be sufficient
| and the bootstrap can be terminated here. The pledge can now use this TA to securely
| trust domain members, but it can not securely identify itself to them as a domain member.
| Therefore BRSKI usually proceeds with the following steps that support this via EST
| enrollment (see also 5.5.1 for the limitations of the trust feasible through the imprint).
Also maybe insert some dotted line between imprint and enroll in Figure 2 to
highlight this distinction. Maybe with "mandatory" / "optional" (EST enroll part)
on the right hand side
-----------------------------------------------------------------------------
Section 2.2
a)
The core sentence is hard to understand because it does not spell out the
implication of the alternatives:
At the
lowest security levels the MASA server can indiscriminately issue
vouchers. At the highest security levels issuance of vouchers can be
integrated with complex sales channel integrations that are beyond
the scope of this document.
Would suggest amending like this:
At the lowest security levels the MASA server can indiscriminately issue
vouchers AND LOG CLAIMS OF OWNERSHIP BY DOMAINS. At the highest security
levels issuance of vouchers can be integrated with complex sales channel
integrations that are beyond the scope of this document BUT THAT WOULD
INTENT TO VERIFY ACTUAL (LEGAL) OWNERSHIP OF THE PLEDGE BY THE DOMAIN.
b)
"Vouchers provide a signed but non-encrypted communication channel
between the Pledge, the MASA, and the Registrar."
Why is this mentioned ? If there is a conclusion of this statement that
is relevant to BRSKI it should be spelled out, otherwise its a detail
belonging into voucher. I do not see how the following sentence is that
relevant conclusion. But maybe i am too confused by the sentence structure.
Do you mean something like this:
| Vouchers are signed but not encrypted. This allows registars to maintain
| better control over pledges attached to the domains network by examining
| and filtering Vouchers received from a MASA before sending them to the pledge.
If thats the idea, i suggest to use language like i suggested because it's
more explicit and simpler (not having to think what the relevance of
"communication channel" is etc..).
Also may warrant a note that this control does not necessarily apply to the
case of a Cloud Registrar (see section 2.6).
-----------------------------------------------------------------------------
Section 2.3)
a)
The first paragraph is too terse and not very explanatory arguing why BRSKI
mandates and how it uses the IDevID. I would suggest a bulleted list
with explained reasons:
- Uniquely identifying the pledge by parameters in the IDevID. The unique
identification of a pledge in the voucher objects are derived from
those parameters as described below.
- Securely authentating the pledges identity via TLS connection to registrar.
This provides protection against cloned/fake pledged.
- Secure auto-discovery of the pledges MASA by the registrar via the MASA URI
in IDevID as explained below.
- (Optional) Signing of voucher-request by the pledges IDevID to enable MASA
to generate voucher only to a registrar that has a connection to the pledge.
- (Optional) authorizing pledge (by registrar) to receive certificate from local CA.
I am unclear about the "authenticating the Pledge during subsequent protocol exchanges ...".
Does this refer to the TLS exchange or others ? If others, then please list
accordingly maybe as a separate bullet point which those are.
Please keep the "There is no requirement for a common root PKI hierarchy.
Each device vendor can generate their own root certificate."
-----------------------------------------------------------------------------
Section 2.3 2)
a) Please put the description of identification of the pledge into a subsection
2.3.1 "Identification of the Pledge"
b) I am confused about the first MUST (serialNumber) and following SHOULD (HardwareModuleName).
The conversion rules make it clear that you want the device to be uniquely identified
via the serialNumber, but if that is not in the certificate, then you would use the
HardwareModuleName. Therefore the conversion rules contradict the MUST for serialNumber.
Or else you wouldn't define a fallback if it does not exist.
c) The MUST/SHOULD bullet points are IMHO a duplication of the conversion rules,
so maybe just drop them.
d) I would start the section with a sentence clearly describing what is done here:
In the context of BRSKI, pledges are uniquely identified by a "serial-number". This
serial-number is used both in the "serial-number" field of Voucher or Voucher requests
(see section 3.) and in local policies on Registrar or MASA (see section 5.).
The serial-number is derived from the IDevID as follows:
... then add the three bullet-points.
e) I do not see "serialNumber" attribute mentioned in rfc4514 nor rfc4108. You mention
"previously defined". Could you provide a reference where "serialNumber" was defined ?
f) Please provide example of each of the three fields and how they convert into
serial-number. This is especially important because for the average reader who has
never seen a certificate (and with no actual reference to e.g.: serialNumber format
thats easily readable), it may be hard to understand if or how something called
"serialNumber" can unique identify a device - aka: that it includes also the
device-type (unless a company only produces one type of device and somehow even
the name of the company can be implied).
e.g.: if i take the Cisco device IDevID format i used on the anima mailing list before:
serialNumber=PID:C819HWD-A-K9 SN:FXXXXFZ
That "PID/SN" format makes it clear how a device can be uniquely be identified, so
it would be a great example if it was not just a Cisco speciality (hence the ask for
any reference for the definition). Could be anonymized accordingly:
serialNumber=PID:MEGAROUTER1 SN:12345
I also think the examples would be good to explain what otherwise would likely be
hard to figure out from references (assuming there would be references):
- To uniquely identify a device, the certificate field choosen needs to contain some
form of at least a product identifier and an actual serial number of that product
identifier.
- Note that the certificate field itself does not need to identify the manufacturer/brand
of the product as long as the field is unique within the scope of the IDevIDs root of
trust. For example both the EXAMPLE and the ACME manufacturer/brands could have a
MEGAROUTER1 product as long as they use different root of trusts for their IDevIDs.
- Product that have a unique root of trust may have a certificate field that
is only containing an actual serial number but no product identifier.
I have no examples of HardwareModuleName. If there is a specific set of devices or
industries that prefers/mandated HardwareModuleName instead of serialNumber, then
an explanatory sentence would be good.
I only have a non-working example of the "common name" , e.g.: in the
cisco example it was:
cn=C819HWD-A-K9
which would be insufficient. So any explanation of known cases where the common name
would actually be used (absence of serialNumber/HardwareModuleName) AND sufficient
would be great to describe (not necessarily referring to specific vendor/manufacturers
but rather product types if possible).
g) Please change the examples "JADA123456789" in the remainder of the document to
the example choosen here.
h) Probably need to end the section with "Device types whose above mentioned IDevID attributes
do not allow for unique identification of devices are outside the scope of this
specification. ". Unless you are sure this case can not exist.
-----------------------------------------------------------------------------
Section 2.3 2)
a) Please put the description of MASA URI into a subsection 2.3.2 "MASA URI"
b) If the following statements are correct, i would suggest to integrate them into the
section text to make it clearer and more explicit. If not then i did not understand
how it is meant to work and the explanations could be approved accordingly to make it
clearer:
- The type and format of the MASA URI indicates the protocol supported by the MASA.
- If a MASA supports multiple protocols, multiple instances of the new MASA URI
can be put into the certificate.
- This document defines the BRSKI-MASA protocol. It is indicated through a URI of
the form
MASA URI is "https:// authority "./well-known/est".
see section 5 for more explanations. (this would replace the current sentence
mentioning section 5).
c) We discussed the risk of introducing new certificate fields and potential
compatibility issues with existing code parsing such a certificate. Which is why we
went for the obfuscated email encoding of the ACP information in the LDevID. It would
therefore be good to have an explaining sentence why the new MASA URI extension
is a better solution than encoding into existing attributes and safe to deploy into
devices.
I am not sure about the full extent of the answer, but probably IDevIDs are meant to
and actually used in a far smaller and newer set of software than that processing
arbitrary LDevIDs. Therefore the risk is smaller and the clean encoding outweights
the risk of compatibility issues with badly written old software.
-----------------------------------------------------------------------------
Section 2.4.1) 1)
"it does has network" -> "it does have network"
But better: "it does only require subnet (link) local connectivity to the
circuit proxy but no routeable IPv6/IPv6 address (exception: see section 2.6)".
-----------------------------------------------------------------------------
Section 2.4.2) 1)
"The proxy mechanism" -> "The circuit proxy mechanism"
" optional stateless mechanism" -> "optional stateless proxy mechanism"
add: The registrar (likely?) also needs manual configuration of per-MASA credentials to
contact them (see section 5.3).
Q: Any case where unauthenticated BRSKI-MASA connections make sense ?
-----------------------------------------------------------------------------
Section 2.4.3) 1)
Suggest to clarify roles:
separate functions: the MANDATORY ...MASA including audit log, and an ADDITIONAL
OPTIONAL Ownership Tracker providing sales channel integration.
Aka: reuse same terminology so readers are not confused. Maybe go through text
to check only "ownership tracker" and "sales channel integration" are used for that part.
-----------------------------------------------------------------------------
Section 2.4.3) 1)
a) Expand CMC.
"authenticate any pledge" -> "authenticate (the IDevID of) any pledge"
b) The document is still very vague on terminology to distinguish between the
initial bootstrap and the (optional) EST server role. Please come up with
a clear terminology and clearly summarize the functionality required to be
supported by the roles.
Here is my suggested text. If any explanation to cover this information is
felt to be too long for 2.4.3, please find another place but make 2.4.3 refer to
that place.
| A "Domain Join Registar and CMC" (abbreviated Domain Registrar in most of the document)
| serves two roles: BRSKI Bootstrap Service and BRSKI enhanced EST Enrollment Service.
|
| The "BRSKI Bootstrap Service" role is newly defined in this document. It performs
| the bootstrapping of Pledges with a "pinned-domain-cert" called trust anchor.
| The BRSKI Bootstrap Service communicates with the Pledge and the MASA. It does
| not need to communicate with the Key Infrastructure (as long as it can support
| cacerts from locally stored information). As a HTTPS/REST server it supports the
| following REST services under /.well-known/est/ newly defined in this document:
| /voucher-request, /cacerts, /status-telemetry
| As a HTTPS/REST client, it support the following REST service under /.well-known/est
| to request vouchers from MASAs:
| requestvoucher, requestauditlog
|
| The "BRSKI enhanced EST Enrollment Service" is an enhanced version of the RFC7030
| defined EST-Server to support automated enrollment of Pledges with certificates. This
| role does not need to support certificate renewal or other services not related to initial
| enrollment. This role communicates with Pledges and Key Infrastructure. It does not
| communicate with MASA. As a HTTPS/REST server it supports (at least) the following
| RFC7030 defined servervices under /.well-known/est/:
| /cacerts, /fullcmc, /csrattrs, /simpleenroll, /serverkeygen
| This document does add new requirements against the details required to be supported
| in the /csrattr service.
| In addition, it supports the new service under /.well-known/est defined in this document
| (which makes it a "BRSKI enhanced" EST Enrollment Service):
| /enrollstatus
[Here is where i wonder:]
| While not recommended, BRSKI Bootstrap Server and BRSKI enhanced EST-Server can
|be provided by separate servers. In this case, the BRSKI Bootstrap Server must
| support redirection of the Pledge after a successfull requestauditlog to the
| URI of a BRSKI enhanced EST-Server.
[I am not sure if this is true, or how else it would work, but if that separation
is meant to be supported that level of detail needs to be written, otherwise
the opposite:]
| This document does not cover cases where BRSKI Bootstrap Server and BRSKI enhanced EST
| Enrollment Server are separated onto two servers. It also does not define what
| (additional) functionality might be required on Pledges to support this.
IMHO with the current design decisions, one would even need to write something like this:
| The design choosen in BRSKI does not always allow to use common modular design
| choices of HTTP(S)/REST servers to separate the Bootstrap Service from the enhanced
| EST enrollment service without operating them on separate transport locators:
| When using a single transport locator, REST request can only be demultiplexed
| by the request path and both Boothstrap Service and EST enrollment service do not
| only share the /.well-known/est/ prefix but even the same /cacerts command.
c) The document must include a statment such as:
| An ANI "Domain Join Registar and CMC" MUST support both BRSKI Bootstrap Service
| and BRSKI enhanced EST Enrollment Service roles.
[or whatever terms you choose to use]
-----------------------------------------------------------------------------
Section 2.4.4)
a) It would be IMHO good to move the (mayority of the) initial paragraph of 5.4 into
this section to explain what the scope of the MASA functionality is by listing the
interface services requestvoucher and requestauditlog here - similar to how i
proposed to summarize the interfaces of the Domain Registrar above for section 2.4.3.
5.4 is not a good place to do that because it's only about requestvoucher, and
then after another non-maza intermezzo 5.6 requestauditlog is again about the
MASA. So no single place summarizing the MASA functionality at this level.
More details see comments about 5.4 below.
-----------------------------------------------------------------------------
Section 2.4.x)
a) Please add subsection "Architectural Component: Key Infrastructure (PKI)"
Suggested text (as in: this is the type of information i would like to see
explained here, whatever language you use):
| The Key Infrastructure (PKI) administers certificates for the domain of concerns,
| providing the trust anchor(s) for it and allowing enrollment of Pledges
| with domain certificates.
|
| The Domain Registrar ('s BRSKI Bootstrap service role) uses a Trust Anchor (TE)
| from the PKI in the BRSKI Voucher pinned-domain-cert to authenticate itself to the
| Pledge with the help of MASA.
|
| The Domain Registrar ('s BRSKI enhanced EST enrollment service) acts as an
| EST Server and request certificates for Pledges from the Key Infrastructure.
|
| The requirements and expectations against the Key Infrastructure are unchanged
| from RFC7030: There are no BRSKI specific features defined or required for
| the Key Infrastructure - only for the Domain Registrar.
Would especially like to see something like the last paragraph because its IMHO
the key part of being able to deploy BRSKI and right now it's hidden in explanations
in specific explanation in section 5.
b) Figure 1 labels the path to the PKI with "EST" and i remember Max to repeatedly
state that CAs could support EST. Nevertheless, i read in RFC7030:
"The nature of communication between an EST server and a CA is not described in this document".
But then it defines the term "EST CA". So i am confused if there is an actual
spec stating the EST profile? of an EST CA.
Aka: Can we write here:
| It is recommended but not required that the Domain Registrar ('s BRSKI enhanced EST
| Enrollment service) also uses RFC7030 to talk to the PKI, e.g.: a CA or subordinate
| CA supporting EST. Nevertheless, the Domain Registrar may choose any standardized
| or non-standardized protocol to talk to the PKI.
If we can not make the first part of that statement here, then also remove "EST" label
from picture 2 and replace with something like "Any CMC? protocol" ?
-----------------------------------------------------------------------------
Section 2.5) 1)
a) If the following sentence is functionally correct, please add text accordingly:
Bootstrapping Pledges that have a Realtime Clock (RTC), SHOULD use it to verify
certificate validity.
b) And from my own experience, it should add:
but they MUST be prepared to recognize local time failure and revert to the above
described mechanisms. For example when RTC battery failure leads to a well-known
default-time (e.g.: Jan 1 1970).
-----------------------------------------------------------------------------
Section 2.5) 2)
a) Please move the bullet about the registrar behavior out of the bullet list, maybe at
the end of the section. Even better:
- rename 2.5 to "Certificate Validity"
- 2.5.1 "Lack of Realtime Clock in Pledges
- 2.5.2 "Infinite Lifetime of IDevID"
(move text into 2.5.1)
b) Its hard to comprehend what the pargraph means to say. I think its something like:
According to RFC5280, IDevIDs are examples of certificates that should have
no well-defined expiration date. This is indicated through the
GeneralizedTime value of 99991231235959Z". Registrars SHOULD have a configuration
option to ignore IDevID lifetime values if they do not conform to this recommendation.
As expected, i always like an explicit example to bring it to the point:
For example, IDevID may have incorrect lifetime of N <= 3 years, rendering replacement
Pledges from storage useless after N years unless registrars support this option.
-----------------------------------------------------------------------------
Section 2.6)
IMHO, without further text, it is unclear a) what a cloud registrar is,
b) why we care and c) how a solution using a cloud registrar would have to be built
to work.
To resolve a), b) better i suggest to replace first paragraph with something like this:
Local Registrars are those for which proxies can be discovered by means under control
of the network to which the pledge connects, such as GRASP or mDNS (see <appropriate sections>).
When a pledge connects to a network connection not under the control of the
domain claiming to own the pledge or if the Pledge's target use
cases want to simply deployments by avoiding the use of proxies, local Registrars and/or
network methods to discover proxies, then the pledge can only connect to a so called
Cloud Registrar via a URL well-known to the non-bootstrapped pledge.
c) If i understand it correctly, then the explanation for c) would be something like this:
When a cloud registrar is used, it must be assumed that it is not operated by the
owner of the pledge. Instead, it would be operated by or on behalf of the manufacturer
similar to the MASA. Such a Cloud Registrar can provide a Voucher to the Pledge,
but that Vouchers pinned-domain-cert could not help the Pledge to authenticate the
BRSKI EST connection because the Cloud Registrar does not belong to a domain of the
owner which the pinned-domain-cert is used for. Therefore trust for the Cloud Registrar
must be provided by the Plede itself:
[add existing second paragraph of 2.6 here]
[I am not sure exactly how you thought about answering c). Here is what i guess could work:,
so this would have to go at the end of 2.6 ]
A Cloud Registrar may operate in different ways:
III) It can answer the Pledges Voucher request with a redirect response to cloud based BRSKI
Registrar oeperarted by or on behalf of the Pledges domain owner. We call this service
of a Cloud Registrar the "redirect-only" model. When the Pledge connects to that BRSKI
server after the redirect, it would again have to perform delayed authentication
of the Registrar after it receives a Voucher from it.
II) Alternatively, the Cloud registrar could provide the pledge with a Voucher and
respond with a redirect response to a successful Voucher Status Telementry,
redirecting the Pledge to a potentially cloud based EST server operated by the owner
of the pledge to complete the Pledge enrollment with a domain certificate. When the
pledge connects to that EST server, it can authenticate it using the pinned-domain-cert
from the Voucher. The pledge would not need to repeat the Voucher request/Status
telemetry transactions.
II) Finally, the Cloud Registrar could provide Voucher AND EST enrolment to the Pledge
directly without any redirect. The mutual trust models for this (between the domain owner
and Cloud Registrar operator) are outside the scope of this specification.
Finally, most crazy (but i know how customers had to do this with pre-BRSKI methods,
so it might make sense):
Pledges MAY support a model in which domain operators could redirect URI connections
from a cloud registrar to a domain operated Registrar because this can be a lightweight
Registrar discovery mechanism - assuming the pledge connects to a network under control
of the domain operator. This can be done by overriding the DNS resolution for the
URI or transport layer redirection. In this case the above decribed implicit TA check by
the client for the TLS connection to the Cloud Registrar fails, but the Pledge falls
back to the delayed authentication after receipt of a voucher as it does for non-Cloud
Registrars.
If you feel this is overall too much, then maybe delete the whole section 2.6
and put it into a followup document. Borderline to me. If its "just" what i sugested
above, its fine, if there is more to it to make it work, maybe better in separate document.
-----------------------------------------------------------------------------
Section 2.7 1)
a)
> Note that the Registrar can only select the configured MASA URL based on the
> trust anchor -- so vendors can only leverage this approach if they
> ensure a single MASA URL works for all Pledge's associated with each
> trust anchor.
I do not think this is true. A registrar could have configuration policy
mapping from IDevID serial-number patterns to MASA URI.
Rewrite accordingly ? Let me know if you hate this approach, i had had to brainstorm it
for my planned yang model for ANI.
b) I also think it might be necessary for Registrars to allow policies that
override MASA URIs learned from the IDevID because the longevity of URIs can
not always be guaranteed and the MASA may move (merger & aquisitions etc.. ).
c) I am unclear from the document whether registrars may require configuration
to know what specific options for voucher-requests a MASA supports.
- If i understand it correctly, a registrar may use a voucher-request to request a
voucher in the absence of the pledge (stage the voucher). This certainly is something
not every MASA must support, so that would need to be configured.
- It is not clear to me if the REgistrar can correctly fill out all Registrar
voucher-requests in the presence of the pledge (aka: after receiving the Pledge
voucher-request). See also discussion for Section 3. If this is not fully automatic,
but may rquire Registrar configuration, this counfig should be mentionedhere.
-----------------------------------------------------------------------------
Setion 3. 1)
So... I guess Registrars can request Vouchers for pledges before being in contact
with that pledge, right ?
If correct, the following would be less confusing to read for me:
| Voucher-requests are how vouchers are requested.
|
| A Pledge send "Pledge voucher-requests" and submit them to the Registrar.
| The Registrar in turn submits a voucher-request to the MASA server. The
| "proximity-registrar-cert" leaf may be used in these Pledge voucher-requests.
| The "prior-signed-voucher-request" leaf may be used in Registrar voucher-requests
| that include a Pledge voucher-request. See [XXX] for a description of the
| semantics of these leafs.
|
| An addition, Registrars may retrieve (nonceless) vouchers by sending
| Pledge voucher-requests to the MASA. The "prior-signed-voucher-request" leaf
| is never used in these voucher-requests.
In any case, you need at least a forward reference for those leaf types if
you want to mention them without other explanations.
-----------------------------------------------------------------------------
Setion 3. 1)
a) Even with above concern Section 3. 1) fixed the section still does not provide a
good taxonomy of the different type of voucher-requests and how to fully identify
them because of the "may be used"...
b) There is no text here explaning how a registrar transforms a Pledge
Voucher request to a Registrar voucher request. If explained later, insert
a forward reference. Else. pls add text to explain.
b) I have my doubts that the flow of the document is ideal with all the
yang formalisms thrown into section 3. If this is what other documents do as
well, fine. I for once would like it better if it was put into a separate section
towards the end of the document.
"nah, not going to happen" is an acceptable answer ;-)
-----------------------------------------------------------------------------
Setion 3.2 1)
"provides voucher examples" -> "provides voucher-request examples"
-----------------------------------------------------------------------------
Section 4. 1)
a.1) Suggest to change title to "Proxying Details (Plege - Proxy - Registrar)"
because the section does not only discuss the proxy but also the aspects/reqirements
of proxying relevant to Client and Registrar.
a.2) paragraph 1: "configured on the Proxy" append:
"or automatically discoverded (e.g.: via GRASP, see below).
b) Add: This section defines a statefu proxy which is therefore called a "circuit" proxy.
c) Simplify whole paragraph with "(In a completely autonomic network...)" - this
discussion is not specific to AN. E.g.:
Registrars are assumed to have logically a locally integrated Proxy to support directly
(subnet) connected Pledges - because Registrars themself does not define any functions
for Pledges to discover them. Such a logical local proxy does not need to provide actual
TCP proxying (just discovery) as long as the Registrar can operate with subnet (link)
local addresses on the interfaces where Pledges may connect to.
d) "to discovery the" -> "to discover the"
e) Paragraph starting with: "If the Proxy joins an Autonomic Control Plane"
Suggest following replacement:
In the ANI, the Autonomic Control Plane (ACP) secured instance of GRASP (<ref>)
MUST be used for discovery of ANI Registrar ACP addresses and ports by ANI Proxies.
The TCP leg of the proxy connection between ANI Proxy and ANI Registrar therefore
also runs across the ACP.
(separate because it would apply for any GRASP learning, not only ACP):
If GRASP is used by proxies for discovery of Registrars (ACP or not),
the proxy can also learn the proxy mechanism (Circuit Proxy vs. IPIP encapsulation
or other)
(there is no negotiation in GRASP, therefore "agreed" as in current text is not
a good choice of word).
f) "SHOULD be the same as on the registrar in order for the proxy to remain stateless".
Does such a proxy makes sense when it is not stateless ? Aka: should this not be a MUST
instead of a SHOULD ?
-----------------------------------------------------------------------------
Section 4. 2)
"In order to permit the proxy functionality to be implemented on the
maximum variety of devices...
with available capabilities for the proxy function similar to many class 2 IoT devices"
This IMHO is an incorrect assumption. I am not aware of any network device in
ANIMAs "well managed network" charter" that would today fall into class 2. I was
and am often extremely annoyed how underpowered control plane of multi-terrabit
switches are but those too don't get down to that level. Even OpenWRT small home
rotuers (outside scope of ANIMA) don't go below 4 MByte these days.
Here are statements i could support/recommend:
- Registrars must support the proxy method supportable by the type of proxies it
needs to support. If pledges could be IoT class 2, then IPIP would be a better
solution for them than a CP circuit proxy. Note that in ANI adopted to class 2 IoT
or similar "mesh network" solutions, Plege become proxies proxy and therefore IoT
class 2 pledges imply also the need to support IoT class 2 proxies.
-----------------------------------------------------------------------------
Section 4.1 1)
a) "[RFC4941] temporary addresses is encouraged...."
Please remove or add text explaining why. Given how a pledge is happy to spill it's
IDevID to everyone claiming to be a proxy i am not sure what benefit privacy
addresses have, and they are additional implementation work for pledges, whereas
link-local (permanent) addresses are always required. And changing addresses
makes diagnostics harder.