-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-anima-brski-async-enroll-04.txt
1512 lines (1051 loc) · 64.1 KB
/
draft-ietf-anima-brski-async-enroll-04.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 S. Fries
Internet-Draft H. Brockhaus
Intended status: Standards Track D. von Oheimb
Expires: 28 April 2022 Siemens
E. Lear
Cisco Systems
25 October 2021
Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)
draft-ietf-anima-brski-async-enroll-04
Abstract
This document describes enhancements of bootstrapping a remote secure
key infrastructure (BRSKI, [RFC8995] ) to also operate in domains
featuring no or only timely limited connectivity between involved
components. To support such use cases, BRSKI-AE relies on the
exchange of authenticated self-contained objects (signature-wrapped
objects) also for requesting and distributing of domain specific
device certificates. The defined approach is agnostic regarding the
utilized enrollment protocol allowing the application of existing and
potentially new certificate management protocols.
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 28 April 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fries, et al. Expires 28 April 2022 [Page 1]
Internet-Draft BRSKI-AE October 2021
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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Supported environment . . . . . . . . . . . . . . . . . . 6
3.2. Application Examples . . . . . . . . . . . . . . . . . . 6
3.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Building automation . . . . . . . . . . . . . . . . . 7
3.2.3. Substation automation . . . . . . . . . . . . . . . . 7
3.2.4. Electric vehicle charging infrastructure . . . . . . 8
3.2.5. Infrastructure isolation policy . . . . . . . . . . . 8
3.2.6. Less operational security in the target domain . . . 8
4. Requirement discussion and mapping to solution elements . . . 9
5. Architectural Overview and Communication Exchanges . . . . . 11
5.1. Support of off-site PKI service . . . . . . . . . . . . . 11
5.1.1. Behavior of a pledge . . . . . . . . . . . . . . . . 14
5.1.2. Pledge - Registrar discovery and voucher exchange . . 15
5.1.3. Registrar - MASA voucher exchange . . . . . . . . . . 15
5.1.4. Pledge - Registrar - RA/CA certificate enrollment . . 15
5.1.5. Addressing Scheme Enhancements . . . . . . . . . . . 18
5.2. Domain registrar support of different enrollment
options . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Example for signature-wrapping using existing enrollment
protocols . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. EST Handling . . . . . . . . . . . . . . . . . . . . . . 19
6.2. CMP Handling . . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. History of changes TBD RFC Editor: please delete . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Fries, et al. Expires 28 April 2022 [Page 2]
Internet-Draft BRSKI-AE October 2021
1. Introduction
BRSKI as defined in [RFC8995] specifies a solution for secure zero-
touch (automated) bootstrapping of devices (pledges) in a (customer)
site domain. This includes the discovery of network elements in the
target domain, time synchronization, and the exchange of security
information necessary to establish trust between a pledge and the
domain. Security information about the target domain, specifically
the target domain certificate, is exchanged utilizing voucher objects
as defined in [RFC8366]. These vouchers are authenticated self-
contained (signed) objects, which may be provided online
(synchronous) or offline (asynchronous) via the domain registrar to
the pledge and originate from a Manufacturer's Authorized Signing
Authority (MASA).
For the enrollment of devices BRSKI relies on EST [RFC7030] to
request and distribute target domain specific device certificates.
EST in turn relies on a binding of the certification request to an
underlying TLS connection between the EST client and the EST server.
According to BRSKI the domain registrar acts as EST server and is
also acting as registration authority (RA) or local registration
authority (LRA). The binding to TLS is used to protect the exchange
of a certification request (for a LDevID EE certificate) and to
provide data origin authentication (client identity information), to
support the authorization decision for processing the certification
request. The TLS connection is mutually authenticated and the
client-side authentication utilizes the pledge's manufacturer issued
device certificate (IDevID certificate). This approach requires an
on-site availability of a local asset or inventory management system
performing the authorization decision based on tuple of the
certification request and the pledge authentication using the IDevID
certificate, to issue a domain specific certificate to the pledge.
The EST server (the domain registrar) terminates the security
association with the pledge and thus the binding between the
certification request and the authentication of the pledge via TLS.
This type of enrollment utilizing an online connection to the PKI is
considered as synchronous enrollment.
For certain use cases on-site support of a RA/CA component and/or an
asset management is not available and rather provided by an
operator's backend and may be provided timely limited or completely
through offline interactions. This may be due to higher security
requirements for operating the certification authority or for
optimization of operation for smaller deployments to avoid the always
on-site operation. The authorization of a certification request
based on an asset management in this case will not / can not be
performed on-site at enrollment time. Enrollment, which cannot be
performed in a (timely) consistent fashion is considered as
Fries, et al. Expires 28 April 2022 [Page 3]
Internet-Draft BRSKI-AE October 2021
asynchronous enrollment in this document. It requires the support of
a store and forward functionality of certification request together
with the requester authentication (and identity) information. This
enables processing of the request at a later point in time. A
similar situation may occur through network segmentation, which is
utilized in industrial systems to separate domains with different
security needs. Here, a similar requirement arises if the
communication channel carrying the requester authentication is
terminated before the RA/CA authorization handling of the
certification request. If a second communication channel is opened
to forward the certification request to the issuing RA/ CA, the
requester authentication information needs to be retained and ideally
bound to the certification request. This uses case is independent
from timely limitations of the first use case. For both cases, it is
assumed that the requester authentication information is utilized in
the process of authorization of a certification request. There are
different options to perform store and forward of certification
requests including the requester authentication information:
* Providing a trusted component (e.g., an LRA) in the target domain,
which stores the certification request combined with the requester
authentication information (based on the IDevID) and potentially
the information about a successful proof of possession (of the
corresponding private key) in a way prohibiting changes to the
combined information. Note that the assumption is that the
information elements may not be cryptographically bound together.
Once connectivity to the backend is available, the trusted
component forwards the certification request together with the
requester information (authentication and proof of possession) to
the off-site PKI for further processing. It is assumed that the
off-site PKI in this case relies on the local pledge
authentication result and thus performs the authorization and
issues the requested certificate. In BRSKI the trusted component
may be the EST server residing co-located with the registrar in
the target domain.
* Utilization of authenticated self-contained objects for the
enrollment, binding the certification request and the requester
authentication in a cryptographic way. This approach reduces the
necessary trust in a domain component to storage and delivery.
Unauthorized modifications of the requester information (request
and authentication) can be detected during the verification of the
authenticated self-contained object.
Focus of this document the support of handling authenticated self-
contained objects for bootstrapping. As it is intended to enhance
BRSKI it is named BRSKI-AE, where AE stands for asynchronous
enrollment. As BRSKI, BRSKI-AE results in the pledge storing an
Fries, et al. Expires 28 April 2022 [Page 4]
Internet-Draft BRSKI-AE October 2021
X.509 domain certificate and sufficient information for verifying the
domain registrar / proxy identity (LDevID CA Certificate) as well as
domain specific X.509 device certificates (LDevID EE certificate).
The goal is to enhance BRSKI to be applicable to the additional use
cases. This is addressed by
* enhancing the well-known URI approach with an additional path for
the utilized enrollment protocol.
* defining a certificate waiting indication and handling, if the
certifying component is (temporarily) not available.
Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple
enrollment protocols on the infrastructure side, allowing the pledge
manufacturer to select the most appropriate. Thus, BRSKI-AE can be
applied for both, asynchronous and synchronous enrollment.
2. Terminology
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]. The
following terms are defined additionally:
CA: Certification authority, issues certificates.
RA: Registration authority, an optional system component to which a
CA delegates certificate management functions such as
authorization checks.
LRA: Local registration authority, an optional RA system component
with proximity to end entities.
IED: Intelligent Electronic Device (in essence a pledge).
on-site: Describes a component or service or functionality available
in the target deployment domain.
off-site: Describes a component or service or functionality
available in an operator domain different from the target
deployment domain. This may be a central site or a cloud service,
to which only a temporary connection is available, or which is in
a different administrative domain.
Fries, et al. Expires 28 April 2022 [Page 5]
Internet-Draft BRSKI-AE October 2021
asynchronous communication: Describes a timely interrupted
communication between an end entity and a PKI component.
synchronous communication: Describes a timely uninterrupted
communication between an end entity and a PKI component.
authenticated self-contained object: Describes an object, which is
cryptographically bound to the EE certificate (IDevID certificate
or LDEVID certificate) of a pledge. The binding is assumed to be
provided through a digital signature of the actual object using
the corresponding private key of the EE certificate.
3. Scope of solution
3.1. Supported environment
This solution is intended to be used in domains with limited support
of on-site PKI services and comprises use cases in which:
* there is no registration authority available in the target domain.
The connectivity to an off-site RA in an operator's network may
only be available temporarily. A local store and forward device
is used for the communication with the off-site services.
* authoritative actions of a LRA are limited and may not comprise
authorization of certification requests of pledges. Final
authorization is done at the RA residing in the operator domain.
* the target deployment domain already has an established
certificate management approach that shall be reused to (e.g., in
brownfield installations).
3.2. Application Examples
The following examples are intended to motivate the support of
different enrollment approaches in general and asynchronous
enrollment specifically, by introducing industrial applications
cases, which could leverage BRSKI as such but also require support of
asynchronous operation as intended with BRSKI-AE.
3.2.1. Rolling stock
Rolling stock or railroad cars contain a variety of sensors,
actuators, and controllers, which communicate within the railroad car
but also exchange information between railroad cars building a train,
or with a backend. These devices are typically unaware of backend
connectivity. Managing certificates may be done during maintenance
cycles of the railroad car, but can already be prepared during
Fries, et al. Expires 28 April 2022 [Page 6]
Internet-Draft BRSKI-AE October 2021
operation. The preparation may comprise the generation of
certification requests by the components which are collected and
forwarded for processing, once the railroad car is connected to the
operator backend. The authorization of the certification request is
then done based on the operator's asset/inventory information in the
backend.
3.2.2. Building automation
In building automation, a use case can be described by a detached
building or the basement of a building equipped with sensor,
actuators, and controllers connected, but with only limited or no
connection to the centralized building management system. This
limited connectivity may be during the installation time but also
during operation time. During the installation in the basement, a
service technician collects the necessary information from the
basement network and provides them to the central building management
system, e.g., using a laptop or even a mobile phone to transport the
information. This information may comprise parameters and settings
required in the operational phase of the sensors/actuators, like a
certificate issued by the operator to authenticate against other
components and services.
The collected information may be provided by a domain registrar
already existing in the installation network. In this case
connectivity to the backend PKI may be facilitated by the service
technician's laptop. Contrary, the information can also be collected
from the pledges directly and provided to a domain registrar deployed
in a different network. In this cases connectivity to the domain
registrar may be facilitated by the service technician's laptop.
3.2.3. Substation automation
In electrical substation automation a control center typically hosts
PKI services to issue certificates for Intelligent Electronic Devices
(IED)s operated in a substation. Communication between the
substation and control center is done through a proxy/gateway/DMZ,
which terminates protocol flows. Note that [NERC-CIP-005-5] requires
inspection of protocols at the boundary of a security perimeter (the
substation in this case). In addition, security management in
substation automation assumes central support of different enrollment
protocols to facilitate the capabilities of IEDs from different
vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies the
mandatory support of two enrollment protocols, SCEP [RFC8894] and EST
[RFC7030] for the infrastructure side, while the IED must only
support one of the two.
Fries, et al. Expires 28 April 2022 [Page 7]
Internet-Draft BRSKI-AE October 2021
3.2.4. Electric vehicle charging infrastructure
For the electric vehicle charging infrastructure protocols have been
defined for the interaction between the electric vehicle (EV) and the
charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as
between the charging point and the charging point operator (e.g.
OCPP [OCPP]). Depending on the authentication model, unilateral or
mutual authentication is required. In both cases the charging point
uses an X.509 certificate to authenticate itself in the context of a
TLS connection between the EV and the charging point. The management
of this certificate depends (beyond others) on the selected backend
connectivity protocol. Specifically, in case of OCPP it is intended
as single communication protocol between the charging point and the
backend carrying all information to control the charging operations
and maintain the charging point itself. This means that the
certificate management is intended to be handled in-band of OCPP.
This requires to be able to encapsulate the certificate management
exchanges in a transport independent way. Authenticated self-
containment will ease this by allowing the transport without a
separate enrollment protocol. This provides a binding of the
exchanges to the identity of the communicating endpoints.
3.2.5. Infrastructure isolation policy
This refers to any case in which network infrastructure is normally
isolated from the Internet as a matter of policy, most likely for
security reasons. In such a case, limited access to external PKI
resources will be allowed in carefully controlled short periods of
time, for example when a batch of new devices are deployed, but
impossible at other times.
3.2.6. Less operational security in the target domain
The registration point performing the authorization of a certificate
request is a critical PKI component and therefore implicates higher
operational security than other components utilizing the issued
certificates for their security features. CAs may also demand higher
security in the registration procedures. Especially the CA/Browser
forum currently increases the security requirements in the
certificate issuance procedures for publicly trusted certificates.
There may be the situation that the target domain does not offer
enough security to operate a registration point and therefore wants
to transfer this service to a backend that offers a higher level of
operational security.
Fries, et al. Expires 28 April 2022 [Page 8]
Internet-Draft BRSKI-AE October 2021
4. Requirement discussion and mapping to solution elements
For the requirements discussion it is assumed that the domain
registrar receiving a certification request as authenticated self-
contained object is not the authorization point for this
certification request. If the domain registrar is the authorization
point and the pledge has a direct connection to the registrar, BRSKI
can be used directly. Note that BRSKI-AE could also be used in this
case.
Based on the intended target environment described in Section 3.1 and
the motivated application examples described in Section 3.2 the
following base requirements are derived to support authenticated
self-contained objects as container carrying the certification
request and further information to support asynchronous operation.
At least the following properties are required:
* Proof of Possession: proves to possess and control the private key
corresponding to the public key contained in the certification
request, typically by adding a signature using the private key.
* Proof of Identity: provides data-origin authentication of a data
object, e.g., a certificate request, utilizing an existing IDevID.
Certificate updates may utilize the certificate that is to be
updated.
Solution examples (not complete) based on existing technology are
provided with the focus on existing IETF documents:
* Certification request objects: Certification requests are
structures protecting only the integrity of the contained data
providing a proof-of-private-key-possession for locally generated
key pairs. Examples for certification requests are:
- PKCS#10 [RFC2986]: Defines a structure for a certification
request. The structure is signed to ensure integrity
protection and proof of possession of the private key of the
requester that corresponds to the contained public key.
- CRMF [RFC4211]: Defines a structure for the certification
request message. The structure supports integrity protection
and proof of possession, through a signature generated over
parts of the structure by using the private key corresponding
to the contained public key. CRMF also supports further proof-
of-possession methods for key pairs not capable to be used for
signing.
Fries, et al. Expires 28 April 2022 [Page 9]
Internet-Draft BRSKI-AE October 2021
Note that the integrity of the certification request is bound to
the public key contained in the certification request by
performing the signature operation with the corresponding private
key. In the considered application examples, this is not
sufficient to provide data origin authentication and needs to be
bound to the existing credential of the pledge (IDevID)
additionally. This binding supports the authorization decision
for the certification request through the provisioning of a proof
of identity. The binding of data origin authentication to the
certification request may be delegated to the protocol used for
certificate management.
* Proof of Identity options: The certification request should be
bound to an existing credential (here IDevID) to enable a proof of
identity and based on it an authorization of the certification
request. The binding may be realized through security options in
an underlying transport protocol if the authorization of the
certification request is done at the next communication hop.
Alternatively, this binding can be done by a wrapping signature
employing an existing credential (initial: IDevID, renewal:
LDevID). This requirement is addressed by existing enrollment
protocols in different ways, for instance:
- EST [RFC7030]: Utilizes PKCS#10 to encode the certification
request. The Certificate Signing Request (CSR) may contain a
binding to the underlying TLS by including the tls-unique value
in the self-signed CSR structure. The tls-unique value is one
result of the TLS handshake. As the TLS handshake is performed
mutually authenticated and the pledge utilized its IDevID for
it, the proof of identity can be provided by the binding to the
TLS session. This is supported in EST using the simpleenroll
endpoint. To avoid the binding to the underlying
authentication in the transport layer, EST offers the support
of a wrapping the CSR with an existing certificate by using
Full PKI Request messages.
- SCEP [RFC8894]: Provides the option to utilize either an
existing secret (password) or an existing certificate to
protect the CSR based on SCEP Secure Message Objects using CMS
wrapping ([RFC5652]). Note that the wrapping using an existing
IDevID credential in SCEP is referred to as renewal. SCEP
therefore does not rely on the security of an underlying
transport.
- CMP [RFC4210] Provides the option to utilize either an existing
secret (password) or an existing certificate to protect the
PKIMessage containing the certification request. The
certification request is encoded utilizing CRMF. PKCS#10 is
Fries, et al. Expires 28 April 2022 [Page 10]
Internet-Draft BRSKI-AE October 2021
optionally supported. The proof of identity of the PKIMessage
containing the certification request can be achieved by using
IDevID credentials to a PKIProtection carrying the actual
signature value. CMP therefore does not rely on the security
of an underlying transport protocol.
- CMC [RFC5272] Provides the option to utilize either an existing
secret (password) or an existing certificate to protect the
certification request (either in CRMF or PKCS#10) based on CMS
[RFC5652]). Here a FullCMCRequest can be used, which allows
signing with an existing IDevID credential to provide a proof
of identity. CMC therefore does not rely on the security of an
underlying transport.
Note that besides the already existing enrollment protocols there is
ongoing work in the ACE WG to define an encapsulation of EST messages
in OSCORE to result in a TLS independent way of protecting EST. This
approach [I-D.selander-ace-coap-est-oscore] may be considered as
further variant.
5. Architectural Overview and Communication Exchanges
To support asynchronous enrollment, the base system architecture
defined in BRSKI [RFC8995] is enhanced to facilitate support of
alternative enrollment protocols. In general, the communication
follows the BRSKI model and utilizes the existing BRSKI architecture
elements. The pledge initiates the communication with the domain
registrar. Necessary enhancements to support authenticated self-
contained objects for certificate enrollment are kept on a minimum to
ensure reuse of already defined architecture elements and
interactions.
For the authenticated self-contained objects used for the
certification request, BRSKI-AE relies on the defined message
wrapping mechanisms of the enrollment protocols stated in Section 4
above.
5.1. Support of off-site PKI service
One assumption of BRSKI-AE is that the authorization of a
certification request is performed based on an authenticated self-
contained object, binding the certification request to the
authentication using the IDevID. This supports interaction with off-
site or off-line PKI (RA/CA) components. In addition, the
authorization of the certification request may not be done by the
domain registrar but by a PKI residing in the backend of the domain
operator (off-site) as described in Section 3.1. Also, the
certification request may be piggybacked by another protocol. This
Fries, et al. Expires 28 April 2022 [Page 11]
Internet-Draft BRSKI-AE October 2021
leads to changes in the placement or enhancements of the logical
elements as shown in Figure 1.
+------------------------+
+--------------Drop Ship--------------->| Vendor Service |
| +------------------------+
| | M anufacturer| |
| | A uthorized |Ownership|
| | S igning |Tracker |
| | A uthority | |
| +--------------+---------+
| ^
| |
V |
+--------+ ......................................... |
| | . . | BRSKI-
| | . +------------+ +------------+ . | MASA
| Pledge | . | Join | | Domain <-----+
| | . | Proxy | | Registrar/ | .
| <-------->............<-------> Enrollment | .
| | . | BRSKI-AE | Proxy | .
| IDevID | . | | +------^-----+ .
| | . +------------+ | .
| | . | .
+--------+ ...............................|.........
"on-site domain" components |
|e.g., RFC 7030,
| RFC 4210, ...
.............................................|.....................
. +---------------------------+ +--------v------------------+ .
. | Public Key Infrastructure |<----+ PKI RA | .
. | PKI CA |---->+ | .
. +---------------------------+ +---------------------------+ .
...................................................................
"off-site domain" components
Figure 1: Architecture overview using off-site PKI components
Fries, et al. Expires 28 April 2022 [Page 12]
Internet-Draft BRSKI-AE October 2021
The architecture overview in Figure 1 utilizes the same logical
elements as BRSKI but with a different placement in the deployment
architecture for some of the elements. The main difference is the
placement of the PKI RA/CA component, which is performing the
authorization decision for the certification request message. It is
placed in the off-site domain of the operator (not the deployment
site directly), which may have no or only temporary connectivity to
the deployment or on-site domain of the pledge. This is to underline
the authorization decision for the certification request in the
backend rather than on-site. The following list describes the
components in the target domain:
* Join Proxy: same functionality as described in BRSKI.
* Domain Registrar / Enrollment Proxy: In general the domain
registrar proxy has a similar functionality regarding the
imprinting of the pledge in the deployment domain to facilitate
the communication of the pledge with the MASA and the PKI.
Different is the authorization of the certification request.
BRSKI-AE allows to perform this in the operator's backend (off-
site), and not directly at the domain registrar.
- Voucher exchange: The voucher exchange with the MASA via the
domain registrar is performed as described in BRSKI [RFC8995].
- Certificate enrollment: For the pledge enrollment the domain
registrar in the deployment domain supports the adoption of the
pledge in the domain based on the voucher request.
Nevertheless, it may not have sufficient information for
authorizing the certification request. If the authorization of
the certification request is done in the off-site domain, the
domain registrar forwards the certification request to the RA
to perform the authorization. Note that this requires, that
the certification request object is enhanced with a proof-of-
identity to allow the authorization based on the bound identity
information of the pledge. As stated above, this can be done
by an additional signature using the IDevID. The domain
registrar here acts as an enrollment proxy or local
registration authority. It is also able to handle the case
having no connection temporarily to an off-site PKI, by storing
the authenticated certification request and forwarding it to
the RA upon reestablished connectivity. As authenticated self-
contained objects are used, it requires an enhancement of the
domain registrar. This is done by supporting alternative
enrollment approaches (protocol options, protocols, encoding)
by enhancing the addressing scheme to communicate with the
domain registrar (see Section 5.1.5).
Fries, et al. Expires 28 April 2022 [Page 13]
Internet-Draft BRSKI-AE October 2021
The following list describes the vendor related components/service
outside the deployment domain:
* MASA: general functionality as described in [RFC8995]. Assumption
is that the interaction with the MASA may be synchronous (voucher
request with nonce) or asynchronous (voucher request without
nonce).
* Ownership tracker: as defined in [RFC8995].
The following list describes the operator related components/service
operated in the backend:
* PKI RA: Performs certificate management functions (validation of
certification requests, interaction with inventory/asset
management for authorization of certification requests, etc.) for
issuing, updating, and revoking certificates for a domain as a
centralized infrastructure for the domain operator. The inventory
(asset) management may be a separate component or integrated into
the RA directly.
* PKI CA: Performs certificate generation by signing the certificate
structure provided in the certification request.
Based on BRSKI and the architectural changes the original protocol
flow is divided into three phases showing commonalities and
differences to the original approach as depicted in the following.
* Discovery phase (same as BRSKI)
* Voucher exchange with deployment domain registrar (same as BRSKI).
* Enrollment phase (changed to support the application of
authenticated self-contained objects).
5.1.1. Behavior of a pledge
The behavior of a pledge as described in [RFC8995] is kept with one
exception. After finishing the imprinting phase (4) the enrollment
phase (5) is performed with a method supporting authenticated self-
contained objects. Using EST with simple-enroll cannot be applied
here, as it binds the pledge authentication with the existing IDevID
to the transport channel (TLS) rather than to the certification
request object directly. This authentication in the transport layer
is not visible / verifiable at the authorization point in the off-
site domain. Section 6 discusses potential enrollment protocols and
options applicable.
Fries, et al. Expires 28 April 2022 [Page 14]
Internet-Draft BRSKI-AE October 2021
5.1.2. Pledge - Registrar discovery and voucher exchange
The discovery phase is applied as specified in [RFC8995].
5.1.3. Registrar - MASA voucher exchange
The voucher exchange is performed as specified in [RFC8995].
5.1.4. Pledge - Registrar - RA/CA certificate enrollment
As stated in Section 4 the enrollment shall be performed using an
authenticated self-contained object providing proof of possession and
proof of identity.
Fries, et al. Expires 28 April 2022 [Page 15]
Internet-Draft BRSKI-AE October 2021
+--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | | Operator |
| | | Join | | Registrar | | RA/CA |
| | | Proxy | | (JRC) | | (OPKI) |
+--------+ +---------+ +------------+ +------------+
/--> | |
[Request of CA Certificates] | |
|---------- CA Certs Request ------------>| |
| [if connection to operator domain is available] |
| |-Request CA Certs ->|
| |<- CA Certs Response|
|<-------- CA Certs Response--------------| |
/--> | |
[Request of Certificate Attributes to be included] |
|---------- Attribute Request ----------->| |
| [if connection to operator domain is available] |
| |Attribute Request ->|
| |<-Attribute Response|
|<--------- Attribute Response -----------| |
/--> | |
[Certification request] | |
|-------------- Cert Request ------------>| |
| [if connection to operator domain is available] |
| |--- Cert Request -->|
| | |
[Optional Certificate waiting indication] | |
/--> | |
|<----- Cert Response (with Waiting) -----| |
|-- Cert Polling (with orig request ID) ->| |
| | |
/--> | |
| |<-- Cert Response --|
| | |
|<-- Cert Response (with Certificate) ----| |
/--> | |
[Certificate confirmation] | |
|-------------- Cert Confirm ------------>| |
| /--> |
| |[optional] |
| |--- Cert Confirm -->|
| |<-- PKI Confirm ----|
|<------------- PKI/Registrar Confirm ----| |
Figure 2: Certificate enrollment
The following list provides an abstract description of the flow
depicted in Figure 2.
Fries, et al. Expires 28 April 2022 [Page 16]
Internet-Draft BRSKI-AE October 2021
* CA Cert Request: The pledge SHOULD request the full distribution
of CA Certificates. This ensures that the pledge has the complete
set of current CA certificates beyond the pinned-domain-cert
(which may be the domain registrar certificate contained in the
voucher).
* CA Cert Response: Contains at least one CA certificate of the
issuing CA.
* Attribute Request: Typically, the automated bootstrapping occurs
without local administrative configuration of the pledge.
Nevertheless, there are cases, in which the pledge may also
include additional attributes specific to the deployment domain
into the certification request. To get these attributes in
advance, the attribute request SHOULD be used.
* Attribute Response: Contains the attributes to be included in the
certification request message.
* Cert Request: Depending on the utilized enrollment protocol, this
certification request contains the authenticated self-contained
object ensuring both, proof-of-possession of the corresponding
private key and proof-of-identity of the requester.
* Cert Response: certification response message containing the
requested certificate and potentially further information like
certificates of intermediary CAs on the certification path.
* Cert Waiting: waiting indication for the pledge to retry after a
given time. For this a request identifier is necessary. This
request identifier may be either part of the enrollment protocol
or build based on the certification request.
* Cert Polling: querying the registrar, if the certificate request
was already processed; can be answered either with another Cert
Waiting, or a Cert Response.
* Cert Confirm: confirmation message from pledge after receiving and
verifying the certificate.
* PKI/Registrar Confirm: confirmation message from PKI/registrar
about reception of the pledge's certificate confirmation.
The generic messages described above can implemented using various
protocols implementing authenticated self-contained objects, as
described in Section 4. Examples are available in Section 6.
Fries, et al. Expires 28 April 2022 [Page 17]
Internet-Draft BRSKI-AE October 2021
5.1.5. Addressing Scheme Enhancements
BRSKI-AE provides enhancements to the addressing scheme defined in
[RFC8995] to accommodate the additional handling of authenticated
self-contained objects for the certification request. As this is
supported by different enrollment protocols, they can be directly
employed (see also Section 6).
The addressing scheme in BRSKI for client certificate request and CA
certificate distribution function during the enrollment uses the
definition from EST [RFC7030], here on the example on simple enroll:
"/.well-known/est/simpleenroll" This approach is generalized to the
following notation: "/.well-known/enrollment-protocol/request" in
which enrollment-protocol may be an already existing protocol or a
newly defined approach. Note that enrollment is considered here as a
sequence of at least a certification request and a certification
response. In case of existing enrollment protocols the following
notation is used proving compatibility to BRSKI:
* enrollment-protocol: references either EST [RFC7030] as in BRSKI
or CMP, CMC, SCEP, or newly defined approaches as alternatives.
Note: additional endpoints (well-known URI) at the registrar may
need to be defined by the utilized enrollment protocol.
* request: depending on the utilized enrollment protocol, the
request describes the required operation at the registrar side.
Enrollment protocols are expected to define the request endpoints
as done by existing protocols (see also Section 6).
5.2. Domain registrar support of different enrollment options
Well-known URIs for different endpoints on the domain registrar are
already defined as part of the base BRSKI specification. In
addition, alternative enrollment endpoints may be supported at the
domain registrar. The pledge will recognize if its supported
enrollment option is supported by the domain registrar by sending a
request to its preferred enrollment endpoint.
The following provides an illustrative example for a domain registrar
supporting different options for EST as well as CMP to be used in
BRSKI-AE. The listing contains the supported endpoints for the
bootstrapping, to which the pledge may connect. This includes the
voucher handling as well as the enrollment endpoints. The CMP
related enrollment endpoints are defined as well-known URI in CMP