-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-anima-brski-ae-12.txt
2296 lines (1536 loc) · 90.4 KB
/
draft-ietf-anima-brski-ae-12.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: 6 January 2025 Siemens
5 July 2024
BRSKI-AE: Alternative Enrollment Protocols in BRSKI
draft-ietf-anima-brski-ae-12
Abstract
This document defines an enhancement of Bootstrapping Remote Secure
Key Infrastructure (BRSKI, RFC 8995). It supports alternative
certificate enrollment protocols, such as CMP, that use authenticated
self-contained signed objects for certification messages.
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/.
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.
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 6 January 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
von Oheimb, et al. Expires 6 January 2025 [Page 1]
Internet-Draft BRSKI-AE July 2024
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 . . . . . . . . . . . . . . . . . . . 4
2. Terminology and abbreviations . . . . . . . . . . . . . . . . 5
3. Basic Requirements and Mapping to Solutions . . . . . . . . . 8
3.1. Solution Options for Proof of Possession . . . . . . . . 8
3.2. Solution Options for Proof of Identity . . . . . . . . . 9
4. Adaptations to BRSKI . . . . . . . . . . . . . . . . . . . . 10
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
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Application Examples . . . . . . . . . . . . . . . . 28
A.1. Rolling Stock . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Building Automation . . . . . . . . . . . . . . . . . . . 29
A.3. Substation Automation . . . . . . . . . . . . . . . . . . 29
A.4. Electric Vehicle Charging Infrastructure . . . . . . . . 30
A.5. Infrastructure Isolation Policy . . . . . . . . . . . . . 30
A.6. Sites with Insufficient Level of Operational Security . . 30
Appendix B. History of Changes TBD RFC Editor: please delete . . 31
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
von Oheimb, et al. Expires 6 January 2025 [Page 2]
Internet-Draft BRSKI-AE July 2024
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 provides the following advantages. The origin of
requests and responses can be authenticated independent of message
transfer. This supports end-to-end authentication (proof of origin)
also over multiple hops, as well as asynchronous operation of
certificate enrollment. This in turn provides architectural
flexibility where and when to ultimately authenticate and authorize
certification requests while retaining full-strength integrity and
authenticity of certification requests.
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
production. 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.
* 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 goals of BRSKI-AE are to provide an enhancement of BRSKI for
LDevID certificate enrollment using, alternatively to EST, a protocol
that
* supports end-to-end authentication over multiple hops
* enables secure message exchange over any kind of transfer,
including asynchronous delivery.
von Oheimb, et al. Expires 6 January 2025 [Page 3]
Internet-Draft BRSKI-AE July 2024
Note that the BRSKI voucher exchange of the pledge with the registrar
and MASA uses authenticated self-contained objects, so the voucher
exchange already has these properties.
The well-known URI approach of BRSKI and EST messages is extended
with an additional path element indicating the enrollment protocol
being used.
Based on the definition of the overall approach and specific
endpoints, this specification enables the registrar to offer multiple
enrollment protocols, from which pledges and their developers can
then pick the most suitable one.
It may be noted that BRSKI (RFC 8995) specifies how to use HTTP over
TLS, but further variants are known, such as Constrained BRSKI
[I-D.ietf-anima-constrained-voucher] using CoAP over DTLS. In the
sequel, 'HTTP' and 'TLS' are just references to the most common case,
where variants such as using CoAP and/or DTLS are meant to be
subsumed - the differences are not relevant here.
This specification is sufficient together with its references to
support BRSKI with the Certificate Management Protocol (CMP,
[RFC9480]) profiled in the Lightweight CMP Profile (LCMPP,
[RFC9483]). Combining BRSKI with a protocol or profile other than
LCMPP will require additional IANA registrations based on the rules
specified in this document. It may also require additional
specifications for details of the protocol or profile (similar to
[RFC9483]), which are outside the scope of this document.
1.1. Supported Scenarios
BRSKI-AE is intended to be used in situations like the following.
* Pledges and/or the target domain reuse an already established
certificate enrollment protocol different from EST, such as CMP.
* The application scenario indirectly excludes the use of EST for
certificate enrollment, for reasons like these:
- The Registration Authority (RA) is not co-located with the
registrar while it requires end-to-end authentication of
requesters. Yet EST does not support end-to-end authentication
over multiple hops.
- The RA or certification authority (CA) operator requires
auditable proof of origin for Certificate Signing Requests
(CSRs). This is not possible with TLS because it provides only
transient source authentication.
von Oheimb, et al. Expires 6 January 2025 [Page 4]
Internet-Draft BRSKI-AE July 2024
- Certificates are requested for types of keys, such as Key
Encapsulation Mechanism (KEM) keys, that do not support signing
(nor alternative forms of single-shot proof of possession like
those described in [RFC6955]). This is not supported by EST
because it uses CSRs in PKCS #10 [RFC2986] format, which can
only use proof-of-possession methods that need just a single
message, while proof of possession for KEM keys, for instance,
requires receiving a fresh challenge value beforehand.
- The pledge implementation uses security libraries not providing
EST support or uses a TLS library that does not support
providing the so-called tls-unique value [RFC5929], which is
needed by EST for strong binding of the source authentication.
* No full RA functionality is available on-site in the target
domain, while connectivity to an off-site RA may be intermittent
or entirely offline.
* Authoritative actions of a local RA at the registrar is not
sufficient for fully and reliably authorizing pledge certification
requests. This may be due to missing data access or due to an
insufficient level of security, for instance regarding the local
storage of private keys.
Bootstrapping can be handled in various ways, depending on the
application domains. The informative Appendix A provides
illustrative examples from various industrial control system
environments and operational setups motivating 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]. The following terms are
described partly in addition.
asynchronous communication: time-wise interrupted delivery of
messages, here between a pledge and the registrar or an RA
authenticated self-contained object: a data structure that is
von Oheimb, et al. Expires 6 January 2025 [Page 5]
Internet-Draft BRSKI-AE July 2024
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
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).
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
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.
LCMPP: Lightweight CMP Profile [RFC9483]
MASA: Manufacturer Authorized Signing Authority
on-site: locality of a component or service or functionality at the
site of the registrar
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.
pledge: device that is to be bootstrapped into a target domain. It
requests an LDevID using IDevID credentials installed by its
manufacturer.
von Oheimb, et al. Expires 6 January 2025 [Page 6]
Internet-Draft BRSKI-AE July 2024
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 communication: time-wise uninterrupted delivery of
messages, here between a pledge and a registrar or PKI component
target domain: the domain that a pledge is going to be bootstrapped
into
This document utilizes generic terminology regarding PKI management
operations to be independent of the terminology of a specific
enrollment protocol.
certification request: message requesting a certificate with proof
of identity
certification response: message providing the answer to a
certification request
attribute request: message requesting content to be included in the
certification request
attribute response: message providing the answer to the attribute
request
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
PKI/registrar confirm: acknowledgment of the PKI on the certificate
confirm
von Oheimb, et al. Expires 6 January 2025 [Page 7]
Internet-Draft BRSKI-AE July 2024
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.
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
von Oheimb, et al. Expires 6 January 2025 [Page 8]
Internet-Draft BRSKI-AE July 2024
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:
* 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.
von Oheimb, et al. Expires 6 January 2025 [Page 9]
Internet-Draft BRSKI-AE July 2024
[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.
* 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
von Oheimb, et al. Expires 6 January 2025 [Page 10]
Internet-Draft BRSKI-AE July 2024
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 6 January 2025 [Page 11]
Internet-Draft BRSKI-AE July 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 | .
. | CA +---->| RA (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 6 January 2025 [Page 12]
Internet-Draft BRSKI-AE July 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 6 January 2025 [Page 13]
Internet-Draft BRSKI-AE July 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 6 January 2025 [Page 14]
Internet-Draft BRSKI-AE July 2024
For transporting the certificate enrollment request and response
messages, the (D)TLS channel established between pledge and
registrar is MANDATORY 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 [I-D.eckert-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 6 January 2025 [Page 15]
Internet-Draft BRSKI-AE July 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 6 January 2025 [Page 16]
Internet-Draft BRSKI-AE July 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 Response ---|
|<-------- Certification Response (6) ----| |
| | |
| [OPTIONAL certificate confirmation] | |
|--------- Certificate Confirm (7) ------>| |
| | [OPTIONAL forwarding] |
| |----- Certificate Confirm ---->|
| |<---- PKI Confirm -------------|
|<-------- PKI/Registrar Confirm (8) -----| |
Figure 2: Certificate Enrollment
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 6 January 2025 [Page 17]
Internet-Draft BRSKI-AE July 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.