-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-anima-brski-ae-13.txt
2408 lines (1599 loc) · 93.9 KB
/
draft-ietf-anima-brski-ae-13.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
ANIMA WG D. von Oheimb, Ed.
Internet-Draft S. Fries
Intended status: Standards Track H. Brockhaus
Expires: 16 March 2025 Siemens
12 September 2024
BRSKI-AE: Alternative Enrollment Protocols in BRSKI
draft-ietf-anima-brski-ae-13
Abstract
This document defines enhancements to the Bootstrapping Remote Secure
Key Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative
Enrollment).
BRSKI-AE extends BRSKI to support certificate enrollment mechanisms
instead of the originally specified use of EST. It supports
certificate enrollment protocols, such as CMP, that use authenticated
self-contained signed objects for certification messages, allowing
for flexibility in network device onboarding scenarios.
The enhancements address use cases where the existing enrollment
mechanism may not be feasible or optimal, providing a framework for
integrating suitable alternative enrollment protocols.
This document also updates the BRSKI reference architecture to
accommodate these alternative methods, ensuring secure and scalable
deployment across a range of network environments.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/.
Discussion of this document takes place on the anima Working Group
mailing list (mailto:[email protected]), which is archived at
https://mailarchive.ietf.org/arch/browse/anima/. Subscribe at
https://www.ietf.org/mailman/listinfo/anima/.
Source for this draft and an issue tracker can be found at
https://github.com/anima-wg/anima-brski-ae.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
von Oheimb, et al. Expires 16 March 2025 [Page 1]
Internet-Draft BRSKI-AE September 2024
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 https://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 16 March 2025.
Copyright Notice
Copyright (c) 2024 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 (https://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 include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Supported Scenarios . . . . . . . . . . . . . . . . . . . 5
2. Terminology and abbreviations . . . . . . . . . . . . . . . . 6
3. Basic Requirements and Mapping to Solutions . . . . . . . . . 8
3.1. Solution Options for Proof of Possession . . . . . . . . 9
3.2. Solution Options for Proof of Identity . . . . . . . . . 9
4. Adaptations to BRSKI . . . . . . . . . . . . . . . . . . . . 11
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Pledge - Registrar Discovery . . . . . . . . . . . . 15
4.2.2. Pledge - Registrar - MASA Voucher Exchange . . . . . 15
4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry . 15
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment . . 16
4.2.5. Pledge - Registrar Enrollment Status Telemetry . . . 19
4.3. Enhancements to the Endpoint Addressing Scheme of
BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Instantiation with Existing Enrollment Protocols . . . . . . 21
5.1. BRSKI-CMP: BRSKI-AE instantiated with CMP . . . . . . . . 21
5.2. Support of Other Enrollment Protocols . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
von Oheimb, et al. Expires 16 March 2025 [Page 2]
Internet-Draft BRSKI-AE September 2024
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Application Examples . . . . . . . . . . . . . . . . 29
A.1. Rolling Stock . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Building Automation . . . . . . . . . . . . . . . . . . . 29
A.3. Substation Automation . . . . . . . . . . . . . . . . . . 30
A.4. Electric Vehicle Charging Infrastructure . . . . . . . . 30
A.5. Infrastructure Isolation Policy . . . . . . . . . . . . . 31
A.6. Sites with Insufficient Level of Operational Security . . 31
Appendix B. History of Changes TBD RFC Editor: please delete . . 31
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction
BRSKI [RFC8995] is typically used with Enrollment over Secure
Transport (EST, [RFC7030]) as the enrollment protocol for operator-
specific device certificates, employing HTTP over TLS for secure
message transfer. BRSKI-AE is a variant using alternative enrollment
protocols with authenticated self-contained objects for the device
certificate enrollment.
This approach offers several distinct advantages. It allows for the
authentication of the origin of requests and responses independently
of message transfer mechanisms. This capability facilitates end-to-
end authentication (i.e., end-to-end proof of origin) across multiple
hops and supports the asynchronous operation of certificate
enrollment. Consequently, this provides architectural flexibility in
determining the location and timing for the ultimate authentication
and authorization of certification requests, while ensuring that the
integrity and authenticity of the enrollment messages is maintained
with full cryptographic strength.
This specification carries over the main characteristics of BRSKI,
namely:
* The pledge is assumed to have received its Initial Device
IDentifier (IDevID, [IEEE_802.1AR-2018]) credentials during its
manufacturing. It uses them to authenticate itself to the
Manufacturer Authorized Signing Authority (MASA, [RFC8995]), and
to the registrar, which is the access point of the target domain,
and to possibly further components of the domain where it will be
operated.
von Oheimb, et al. Expires 16 March 2025 [Page 3]
Internet-Draft BRSKI-AE September 2024
* The pledge first obtains via the voucher [RFC8366] exchange a
trust anchor for authenticating entities in the domain such as the
domain registrar.
* The pledge then obtains its Locally significant Device IDentifier
(IDevID, [IEEE_802.1AR-2018]). To this end, the pledge generates
a private key, called LDevID secret, and requests via the domain
registrar from the PKI of its new domain a domain-specific device
certificate, called LDevID certificate. On success, it receives
the LDevID certificate along with its certificate chain.
The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID
certificate enrollment through the use of an alternative protocol to
EST that:
* Supports end-to-end authentication over multiple hops.
* Facilitates secure message exchange over any type of transfer
mechanism, including asynchronous delivery.
It may be observed that the BRSKI voucher exchange between the
pledge, registrar, and MASA involves the use of authenticated self-
contained objects, which inherently possess these properties.
The existing well-known URI structure used for BRSKI and EST messages
is extended by introducing an additional path element that specifies
the enrollment protocol being employed.
This specification allows the registrar to offer multiple enrollment
protocols, enabling pledges and their developers to select the most
appropriate one based on the defined overall approach and specific
endpoints.
It may be important to note that BRSKI (RFC 8995) specifies the use
of HTTP over TLS, but variations such as Constrained BRSKI
[I-D.ietf-anima-constrained-voucher] which uses CoAP over DTLS, are
possible as well. In this context, 'HTTP' and 'TLS' are used as
references to the most common implementation, though variants using
CoAP and/or DTLS are implied where applicable, as the distinctions
are not pertinent here.
von Oheimb, et al. Expires 16 March 2025 [Page 4]
Internet-Draft BRSKI-AE September 2024
This specification, together with its referenced documents, is
sufficient to support BRSKI with the Certificate Management Protocol
(CMP, [RFC9480]) as profiled in the Lightweight CMP Profile (LCMPP,
[RFC9483]). Integrating BRSKI with an enrollment protocol or profile
other than LCMPP will necessitate additional IANA registrations, as
detailed in this document. Furthermore, additional specifications
may be required for the details of the protocol or profile, which
fall outside the scope of this document.
1.1. Supported Scenarios
BRSKI-AE is designed for use in scenarios such as the following:
* Pledges and/or the target domain leverage an existing certificate
enrollment protocol other than EST, such as CMP.
* The application context precludes the use of EST for certificate
enrollment due to factors such as:
- The Registration Authority (RA) is not co-located with the
registrar and requires end-to-end authentication of requesters,
which EST does not support over multiple hops.
- The RA or Certification Authority (CA) operator mandates
auditable proof of origin for Certificate Signing Requests
(CSRs), which cannot be provided by TLS as it only offers
transient source authentication.
- Certificates are requested for key types, such as Key
Encapsulation Mechanism (KEM) keys, that do not support signing
or other single-shot proof-of-possession methods, as those
described in [RFC6955]. EST, which relies on CSRs in PKCS #10
[RFC2986] format, does not accommodate these key types because
it necessitates proof-of-possession methods that operate within
a single message, whereas proof of possession for KEM keys
requires prior receipt of a fresh challenge value.
- The pledge implementation employs security libraries that do
not support EST or uses a TLS library lacking support for the
"tls-unique" value [RFC5929], which EST requires for the strong
binding of source authentication.
* Full RA functionality is not available on-site within the target
domain, and connectivity to an off-site RA may be intermittent or
entirely offline.
von Oheimb, et al. Expires 16 March 2025 [Page 5]
Internet-Draft BRSKI-AE September 2024
* Authoritative actions by a local RA at the registrar are
insufficient for fully and reliably authorizing pledge
certification requests, potentially due to a lack of access to
necessary data or inadequate security measures, such as the local
storage of private keys.
Bootstrapping may be managed in various ways depending on the
application domain. Appendix A provides illustrative examples from
different industrial control system environments and operational
contexts that motivate the support of alternative enrollment
protocols.
2. Terminology and abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document relies on the terminology defined in [RFC8995],
[RFC5280], and [IEEE_802.1AR-2018], partly repeated here. Also
several further terms are described here.
To be independent of the terminology of a specific enrollment
protocol, this document utilizes generic terminology regarding PKI
management operations.
asynchronous: time-wise interrupted delivery of messages,
here between a pledge and some backend system (e.g., an RA)
attribute request: message requesting content to be included in the
certification request
attribute response: message providing the answer to the attribute
request
authenticated self-contained object: a data structure that is
cryptographically bound to the identity of its originator by an
attached digital signature on the actual object, using a private
key of the originator such as the IDevID secret.
backend: placement of a domain component separately from the domain
registrar; may be on-site or off-site
BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995]
BRSKI-AE: BRSKI with *A*lternative *E*nrollment, a variation of
von Oheimb, et al. Expires 16 March 2025 [Page 6]
Internet-Draft BRSKI-AE September 2024
BRSKI [RFC8995] in which BRSKI-EST, the enrollment protocol
between pledge and the registrar, is replaced by enrollment
protocols that support end-to-end authentication of the pledge to
the RA, such as Lightweight CMP (see LCMPP).
CA certs request: message requesting CA certificates
CA certs response: message providing the answer to a CA certs
request
certificate confirm: message stating to the backend PKI that the
requester of a certificate received the new certificate and
accepted it
certification request: message requesting a certificate with proof
of identity
certification response: message providing the answer to a
certification request
CMP: Certificate Management Protocol [RFC9480]
CSR: Certificate Signing Request
EST: Enrollment over Secure Transport [RFC7030]
IDevID: Initial Device IDentifier of a pledge, provided by the
manufacturer and comprising a private key and the related X.509
certificate with its chain
LCMPP: Lightweight CMP Profile [RFC9483]
LDevID: Locally significant Device IDentifier of a pledge, provided
by its target domain and comprising a private key and the related
X.509 certificate with its chain
local RA (LRA): a subordinate RA that is close to entities being
enrolled and separate from a subsequent RA. In BRSKI-AE it is
needed if a backend RA is used, and in this case, the LRA is co-
located with the registrar.
MASA: Manufacturer Authorized Signing Authority, provides vouchers
off-site: locality of component or service or functionality, such as
RA or CA, not at the site of the registrar. This may be a central
site or a cloud service, to which connection may be intermittent.
on-site: locality of a component or service or functionality at the
von Oheimb, et al. Expires 16 March 2025 [Page 7]
Internet-Draft BRSKI-AE September 2024
site of the registrar
PKI/registrar confirm: acknowledgment of the PKI on the certificate
confirm
pledge: device that is to be bootstrapped into a target domain. It
requests an LDevID using IDevID credentials installed by its
manufacturer.
RA: Registration Authority, the PKI component to which a CA
typically delegates certificate management functions such as
authenticating pledges and performing authorization checks on
certification requests
registrar: short for domain registrar
site: the locality where an entity, such as a pledge, registrar, or
PKI component is deployed. The target domain may have multiple
sites.
synchronous: time-wise uninterrupted delivery of messages,
here between a pledge and a registrar or backend system (e.g., the
MASA)
target domain: the domain that a pledge is going to be bootstrapped
into
3. Basic Requirements and Mapping to Solutions
Based on the intended target scenarios described in Section 1.1 and
the application examples described in Appendix A, the following
requirements are derived to support authenticated self-contained
objects as containers carrying certification requests.
The following properties are required for a certification request:
* Proof of possession: demonstrates access to the private key
corresponding to the public key contained in a certification
request. This is typically achieved by a self-signature using the
corresponding private key but can also be achieved indirectly, see
[RFC4210], Section 4.3.
* Proof of identity, also called proof of origin: provides data
origin authentication of the certification request. Typically,
this is achieved by a signature using the pledge IDevID secret
over some data, which needs to include a sufficiently strong
identifier of the pledge, such as the device serial number
typically included in the subject of the IDevID certificate.
von Oheimb, et al. Expires 16 March 2025 [Page 8]
Internet-Draft BRSKI-AE September 2024
The remainder of this section gives a non-exhaustive list of solution
examples, based on existing technology described in IETF documents.
3.1. Solution Options for Proof of Possession
Certificate signing request (CSR) objects: CSRs are data structures
protecting only the integrity of the contained data and providing
proof of possession for a (locally generated) private key. Important
types of CSR data structures are:
* PKCS #10 [RFC2986]. This very common form of CSR is self-signed
to protect its integrity and to prove possession of the private
key that corresponds to the public key included in the request.
* Certificate Request Message Format (CRMF, [RFC4211]). This less
common but more general CSR format supports several ways of
integrity protection and proof of possession. Typically a self-
signature is used, which is generated over (part of) the structure
with the private key corresponding to the included public key.
CRMF also supports further proof-of-possession methods for types
of keys that do not have signing capability. For details see
[RFC4211], Section 4.
It should be noted that the integrity protection of CSRs includes the
public key because it is part of the data signed by the corresponding
private key. Yet this signature does not provide data origin
authentication, i.e., proof of identity of the requester because the
key pair involved is new and therefore does not yet have a confirmed
identity associated with it.
3.2. Solution Options for Proof of Identity
Binding a certificate signing request (CSR) to an existing
authenticated credential (the BRSKI context, the IDevID certificate)
enables proof of origin, which in turn supports an authorization
decision on the CSR.
The binding of data origin authentication to the CSR is typically
delegated to the protocol used for certificate management. This
binding may be achieved through security options in an underlying
transport protocol such as TLS if the authorization of the
certification request is (sufficiently) done at the next
communication hop. Depending on the key type, the binding can also
be done in a stronger, transport-independent way by wrapping the CSR
with a signature.
This requirement is addressed by existing enrollment protocols in
various ways, such as:
von Oheimb, et al. Expires 16 March 2025 [Page 9]
Internet-Draft BRSKI-AE September 2024
* EST [RFC7030], also its variant EST-coaps [RFC9148], utilizes PKCS
#10 to encode Certificate Signing Requests (CSRs). While such a
CSR has not been designed to include proof of origin, there is a
limited, indirect way of binding it to the source authentication
of the underlying TLS session. This is achieved by including in
the CSR the tls-unique value [RFC5929] resulting from the TLS
handshake. As this is optionally supported by the EST
"/simpleenroll" endpoint used in BRSKI and the TLS handshake
employed in BRSKI includes certificate-based client authentication
of the pledge with its IDevID credentials, the proof of pledge
identity being an authenticated TLS client can be bound to the
CSR.
Yet this binding is only valid in the context of the TLS session
established with the registrar acting as the EST server and
typically also as an RA. So even such a cryptographic binding of
the authenticated pledge identity to the CSR is not visible nor
verifiable to authorization points outside the registrar, such as
a (second) RA in the backend. What the registrar needs to do is
to authenticate and pre-authorize the pledge and to indicate this
to the (second) RA by signing the forwarded certification request
with its private key and a related certificate that has the id-kp-
cmcRA extended key usage attribute.
[RFC7030], Section 2.5 sketches wrapping PKCS #10-formatted CSRs
with a Full PKI Request message sent to the "/fullcmc" endpoint.
This would allow for source authentication at the message level,
such that the registrar could forward it to external RAs in a
meaningful way. This approach is so far not sufficiently
described and likely has not been implemented.
* SCEP [RFC8894] supports using a shared secret (passphrase) or an
existing certificate to protect CSRs based on SCEP Secure Message
Objects using CMS wrapping ([RFC5652]). Note that the wrapping
using an existing IDevID in SCEP is referred to as 'renewal'.
This way SCEP does not rely on the security of the underlying
message transfer.
* CMP [RFC4210] [RFC9480] supports using a shared secret
(passphrase) or an existing certificate, which may be an IDevID
credential, to authenticate certification requests via the
PKIProtection structure in a PKIMessage. The certification
request is typically encoded utilizing CRMF, while PKCS #10 is
supported as an alternative. Thus, CMP does not rely on the
security of the underlying message transfer.
von Oheimb, et al. Expires 16 March 2025 [Page 10]
Internet-Draft BRSKI-AE September 2024
* CMC [RFC5272] also supports utilizing a shared secret (passphrase)
or an existing certificate to protect certification requests,
which can be either in CRMF or PKCS #10 structure. The proof of
identity can be provided as part of a FullCMCRequest, based on CMS
[RFC5652] and signed with an existing IDevID secret. Thus, CMC
does not rely on the security of the underlying message transfer.
To sum up, EST does not meet the requirements for authenticated self-
contained objects, but SCEP, CMP, and CMC do. This document
primarily focuses on CMP as it has more industry adoption than CMC
and SCEP has issues not detailed here.
4. Adaptations to BRSKI
To enable using alternative certificate enrollment protocols
supporting end-to-end authentication, asynchronous enrollment, and
more general system architectures, BRSKI-AE provides some
generalizations on BRSKI [RFC8995]. This way, authenticated self-
contained objects such as those described in Section 3 above can be
used for certificate enrollment, and RA functionality can be deployed
freely in the target domain. Parts of the RA functionality can even
be distributed over several nodes.
The enhancements are kept to a minimum to ensure the reuse of already
defined architecture elements and interactions. In general, the
communication follows the BRSKI model and utilizes the existing BRSKI
architecture elements. In particular, the pledge initiates
communication with the domain registrar and interacts with the MASA
as usual for voucher request and response processing.
4.1. Architecture
The key element of BRSKI-AE is that the authorization of a
certification request MUST be performed based on an authenticated
self-contained object. The certification request is bound in a self-
contained way to a proof of origin based on the IDevID credentials.
Consequently, the certification request MAY be transferred using any
mechanism or protocol. Authentication and authorization of the
certification request can be done by the domain registrar and/or by
backend domain components. As mentioned in Section 1.1, these
components may be offline or off-site. The registrar and other on-
site domain components may have no or only temporary (intermittent)
connectivity to them.
This leads to generalizations in the placement and enhancements of
the logical elements as shown in Figure 1.
von Oheimb, et al. Expires 16 March 2025 [Page 11]
Internet-Draft BRSKI-AE September 2024
+------------------------+
+--------------Drop-Ship--------------| Vendor Service |
| +------------------------+
| | M anufacturer| |
| | A uthorized |Ownership|
| | S igning |Tracker |
| | A uthority | |
| +--------------+---------+
| ^
| |
V | BRSKI-
+--------+ ......................................... | MASA
| | . . |
| | . +-------+ +--------------+ . |
| Pledge | . | Join | | Domain |<----+
| |<------>| Proxy |<-------->| Registrar | .
| | . | | | w/ LRA or RA | .
| IDevID | . +-------+ +--------------+ .
| | BRSKI-AE over TLS ^ .
+--------+ using, e.g., LCMPP | .
. | .
...............................|.........
on-site (local) domain components |
|
| e.g., LCMPP
|
.............................................|...............
. Public-Key Infrastructure v .
. +---------+ +---------------------------------------+ .
. | |<----+ Registration Authority RA | .
. | CA +---->| (unless part of Domain Registrar) | .
. +---------+ +---------------------------------------+ .
.............................................................
backend (central or off-site) domain components
Figure 1: Architecture Overview Using Backend PKI Components
The architecture overview in Figure 1 has the same logical elements
as BRSKI, but with a more flexible placement of the authentication
and authorization checks on certification requests. Depending on the
application scenario, the registrar MAY still do all of these checks
(as is the case in BRSKI), or part of them.
The following list describes the on-site components in the target
domain of the pledge shown in Figure 1.
* Join Proxy: same requirements as in BRSKI, see [RFC8995],
Section 4
von Oheimb, et al. Expires 16 March 2025 [Page 12]
Internet-Draft BRSKI-AE September 2024
* Domain Registrar including LRA or RA functionality: in BRSKI-AE,
the domain registrar has mostly the same functionality as in
BRSKI, namely to act as the gatekeeper of the domain for
onboarding new devices and to facilitate the communication of
pledges with their MASA and the domain PKI. Yet there are some
generalizations and specific requirements:
1. The registrar MUST support at least one certificate enrollment
protocol with authenticated self-contained objects for
certification requests. To this end, the URI scheme for
addressing endpoints at the registrar is generalized (see
Section 4.3).
2. Rather than having full RA functionality, the registrar MAY
act as a local registration authority (LRA) and delegate part
of its involvement in certificate enrollment to a backend RA.
In such scenarios, the registrar optionally checks
certification requests it receives from pledges and forwards
them to the backend RA, which performs the remaining parts of
the enrollment request validation and authorization. Note
that to this end the backend RA may need information regarding
the authorization of pledges from the registrar or from other
sources. On the way back, the registrar forwards responses by
the PKI to the pledge on the same channel.
To support end-to-end authentication of the pledge across the
registrar to the backend RA, the certification request signed
by the pledge needs to be upheld and forwarded by the
registrar. Therefore, the registrar cannot use for its
communication with the PKI an enrollment protocol that is
different from the enrollment protocol used between the pledge
and the registrar.
3. The use of a certificate enrollment protocol with
authenticated self-contained objects gives freedom how to
transfer enrollment messages between the pledge and an RA.
BRSKI demands that the RA accept certification requests for
LDevIDs only with the consent of the registrar. BRSKI-AE
guarantees this also in case that the RA is not part of the
registrar, even if the message exchange with backend systems
is unprotected and involves further transport hops. See
Section 7 for details on how this can be achieved.
Despite the above generalizations to the enrollment phase, the final
step of BRSKI, namely the enrollment status telemetry, is kept as it
is.
von Oheimb, et al. Expires 16 March 2025 [Page 13]
Internet-Draft BRSKI-AE September 2024
The following list describes the components provided by the vendor or
manufacturer outside the target domain.
* MASA: functionality as described in BRSKI [RFC8995]. The voucher
exchange with the MASA via the domain registrar is performed as
described in BRSKI.
Note: From the definition of the interaction with the MASA in
[RFC8995], Section 5 follows that it may be synchronous (using
voucher request with nonces) or asynchronous (using nonceless
voucher requests).
* Ownership tracker: as defined in BRSKI.
The following list describes backend target domain components, which
may be located on-site or off-site in the target domain.
* RA: performs centralized certificate management functions as a
public-key infrastructure for the domain operator. As far as not
already done by the domain registrar, it performs the final
validation and authorization of certification requests.
Otherwise, the RA co-located with the domain registrar directly
connects to the CA.
* CA, also called domain CA: generates domain-specific certificates
according to certification requests that have been authenticated
and authorized by the registrar and/or an extra RA.
Based on the diagram in BRSKI [RFC8995], Section 2.1 and the
architectural changes, the original protocol flow is divided into
several phases showing commonalities and differences to the original
approach as follows.
* Discovery phase: mostly as in BRSKI step (1). For details see
Section 4.2.1.
* Identification phase: same as in BRSKI step (2).
* Voucher exchange phase: same as in BRSKI steps (3) and (4).
* Voucher status telemetry: same as in BRSKI directly after step
(4).
* Certificate enrollment phase: the use of EST in step (5) is
changed to employing a certificate enrollment protocol that uses
an authenticated self-contained object for requesting the LDevID
certificate.
von Oheimb, et al. Expires 16 March 2025 [Page 14]
Internet-Draft BRSKI-AE September 2024
For transporting the certificate enrollment request and response
messages, the (D)TLS channel established between pledge and
registrar is REQUIRED to use. To this end, the enrollment
protocol, the pledge, and the registrar need to support the use of
this existing channel for certificate enrollment. Due to this
architecture, the pledge does not need to establish additional
connections for certificate enrollment and the registrar retains
full control over the certificate enrollment traffic.
* Enrollment status telemetry: the final exchange of BRSKI step (5).
4.2. Message Exchange
The behavior of a pledge described in BRSKI [RFC8995], Section 2.1 is
kept, with one major exception. After finishing the Imprint step
(4), the Enroll step (5) MUST be performed with an enrollment
protocol utilizing authenticated self-contained objects, as explained
in Section 3. Section 5 discusses selected suitable enrollment
protocols and options applicable.
An abstract overview of the BRSKI-AE protocol can be found at
[BRSKI-AE-overview].
4.2.1. Pledge - Registrar Discovery
Discovery as specified in BRSKI [RFC8995], Section 4 does not support
the discovery of registrars with enhanced feature sets. A pledge can
not find out in this way whether discovered registrars support the
certificate enrollment protocol it expects, such as CMP.
As a more general solution, the BRSKI discovery mechanism can be
extended to provide up-front information on the capabilities of
registrars. Future work such as [draft-ietf-anima-brski-discovery]
may provide this.
In the absence of such a generally applicable solution, BRSKI-AE
deployments may use their particular way of doing discovery.
Section 5.1 defines a minimalist approach that MAY be used for CMP.
4.2.2. Pledge - Registrar - MASA Voucher Exchange
The voucher exchange is performed as specified in [RFC8995].
4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry
The voucher status telemetry is performed as specified in [RFC8995],
Section 5.7.
von Oheimb, et al. Expires 16 March 2025 [Page 15]
Internet-Draft BRSKI-AE September 2024
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
This replaces the EST integration for PKI bootstrapping described in
[RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the
final phase, see below).
The certificate enrollment phase may involve the transmission of
several messages. Details can depend on the application scenario,
the employed enrollment protocol, and other factors.
The only message exchange REQUIRED is for the actual certification
request and response. Further message exchanges MAY be performed as
needed.
Note: The message exchanges marked OPTIONAL in the below Figure 2
cover all those supported by the use of EST in BRSKI. The last
OPTIONAL one, namely certificate confirmation, is not supported by
EST, but by CMP and other enrollment protocols.
von Oheimb, et al. Expires 16 March 2025 [Page 16]
Internet-Draft BRSKI-AE September 2024
+------+ +---------+ +--------+
|Pledge| |Domain | |Operator|
| | |Registrar| |RA/CA |
| | |(JRC) | |(PKI) |
+------+ +---------+ +--------+
| | |
|[OPTIONAL request of CA certificates]| |
|------- CA Certs Request (1) ------->| |
| | [OPTIONAL forwarding] |
| |--- CA Certs Request ----->|
| |<-- CA Certs Response -----|
|<------ CA Certs Response (2) -------| |
| | |
|[OPTIONAL request of attributes | |
| to include in Certification Request]| |
|------- Attribute Request (3) ------>| |
| | [OPTIONAL forwarding] |
| |--- Attribute Request ---->|
| |<-- Attribute Response ----|
|<------ Attribute Response (4) ------| |
| | |
|[REQUIRED certification request] | |
|------- Certification Request (5) -->| |
| | [OPTIONAL forwarding] |
| |---Certification Request-->|
| |<--Certification Resp. ---|
|<----- Certification Response (6) ---| |
| | |
|[OPTIONAL certificate confirmation] | |
|------- Certificate Confirm (7) ---->| |
| | [OPTIONAL forwarding] |
| |--- Certificate Confirm--->|
| |<-- PKI Confirm -----------|
|<------ PKI/Registrar Confirm (8) ---| |
Figure 2: Certificate Enrollment Message Flow
It may be noted that connections between the registrar and the PKI
components of the operator (RA, CA, etc.) may be intermittent or off-
line. Messages should be sent as soon as sufficient transfer
capacity is available.
von Oheimb, et al. Expires 16 March 2025 [Page 17]
Internet-Draft BRSKI-AE September 2024
The label [OPTIONAL forwarding] in Figure 2 means that on receiving
from a pledge a request message of the given type, the registrar MAY
answer the request directly. In this case, it MUST authenticate its
responses with the same credentials as used for authenticating itself
at the TLS level for the voucher exchange. Otherwise, the registrar
MUST forward the request to the RA and forward any resulting response
back to the pledge.
The decision of whether to forward a request or to answer it directly
can depend on various static and dynamic factors. They include the
application scenario, the capabilities of the registrar and of the
local RA possibly co-located with the registrar, the enrollment
protocol being used, and the specific contents of the request.
Note that there are several options for how the registrar could be
able to directly answer requests for CA certificates or for
certification request attributes. It could cache responses obtained
from the domain PKI and later use their contents for responding to
requests asking for the same data. The contents could also be
explicitly provisioned at the registrar.
Further note that certification requests typically need to be handled
by the backend PKI, but the registrar can answer them directly with
an error response in case it determines that such a request should be
rejected, for instance, because is not properly authenticated or not
authorized.Also, certificate confirmation messages will usually be
forwarded to the backend PKI, but if the registrar knows that they
are not needed or wanted there it can acknowledge such messages
directly.
The following list provides an abstract description of the flow
depicted in Figure 2.
* CA Certs Request (1): The pledge optionally requests the latest
relevant CA certificates. This ensures that the pledge has the
complete set of current CA certificates beyond the pinned-domain-
cert (which is contained in the voucher and which may be just the
domain registrar certificate).
* CA Certs Response (2): This MUST contain any intermediate CA
certificates that the pledge may need to validate certificates and
MAY contain the LDevID trust anchor.