-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-friel-anima-brski-cloud.txt
728 lines (449 loc) · 26.6 KB
/
draft-friel-anima-brski-cloud.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
Network Working Group O. Friel
Internet-Draft Cisco
Intended status: Standards Track R. Shekh-Yusef
Expires: May 27, 2020 Avaya
M. Richardson
Sandelman Software Works
November 24, 2019
BRSKI Cloud Registrar
draft-friel-anima-brski-cloud
Abstract
This document specifies the behaviour of a BRSKI Cloud Registrar, and
how a pledge can interact with a BRSKI Cloud Registrar when
bootstrapping.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 27, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Friel, et al. Expires May 27, 2020 [Page 1]
Internet-Draft BRSKI-CLOUD November 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Network Connectivity . . . . . . . . . . . . . . . . . . 4
3. Initial Voucher Request . . . . . . . . . . . . . . . . . . . 4
3.1. Cloud Registrar Discovery . . . . . . . . . . . . . . . . 4
3.2. Pledge - Cloud Registrar TLS Establishment Details . . . 4
3.3. Pledge Requests Voucher from the Cloud Registrar . . . . 5
4. Cloud Registrar Voucher Request Operation . . . . . . . . . . 5
4.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . . . 5
5. Voucher Request Redirected to Local Domain Registrar . . . . 6
5.1. Pledge handling of Redirect . . . . . . . . . . . . . . . 6
6. Voucher Request Handled by Cloud Registrar . . . . . . . . . 6
7. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Voucher Request Redirected to Local Domain Registrar . . 7
7.2. Voucher Request Handled by Cloud Registrar . . . . . . . 8
7.2.1. Option 1: EST enroll completed against cloud
registrar . . . . . . . . . . . . . . . . . . . . . . 8
7.2.2. Option 2: EST redirect by cloud registrar . . . . . . 9
7.2.3. Option 3: Voucher includes EST domain . . . . . . . . 10
8. Pledge Certificate Identity Considerations . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Bootstrapping Remote Secure Key Infrastructures (BRSKI)
[I-D.ietf-anima-bootstrapping-keyinfra] specifies automated
bootstrapping of an Autonomic Control Plane. BRSKI Section 2.7
describes how a pledge "MAY contact a well known URI of a cloud
registrar if a local registrar cannot be discovered or if the
pledge's target use cases do not include a local registrar".
This document further specifies use of a BRSKI cloud registrar and
clarifies operations that are not sufficiently specified in BRSKI.
Two high level deployment models are documented here:
o Local Domain Registrar Discovery: the cloud registrar is used by
the pledge to discover the local domain registrar. The cloud
registrar redirects the pledge to the local domain registrar, and
the pledge completes bootstrap against the local domain registrar.
Friel, et al. Expires May 27, 2020 [Page 2]
Internet-Draft BRSKI-CLOUD November 2019
o Cloud Registrar Based Boostrap: there is no local domain registrar
and the pledge completes boostrap using the cloud registrar. As
part of boostrap, the cloud registrar may need to tell the client
the domain to use for accessing services.
These deployment models facilitate multiple use cases including:
o A pledge is bootstrapping in a remote location and needs to
contact a cloud registrar in order to discover the address of its
local domain.
o A pledge can connect to a manufacturer hosted cloud service or the
same software running on-premise. The systems might not be
discoverable locally.
o A pledge needs to connect to a third-party hosted registrar
service, because there is no local registrar service available.
o A pledge needs to discover the deployment model in use by the
pledge operator, which might include going into some local
configuration mode.
2. Architecture
The high level architecture is illustrated in Figure 1. The pledge
connects to the cloud registrar during bootstrap. The cloud
registrar may redirect the pledge to a local registrar in order to
complete bootstrap against the local registrar. If the cloud
registrar handles the bootstrap process itself without redirecting
the pledge to a local registrar, the cloud registrar may need to
inform the pledge what domain to use for accessing services once
bootstrap is complete.
Finally, when bootstrapping against a local registrar, the registrar
may interact with a backend CA to assist in issuing certificates to
the pledge. The mechanisms and protocols by which the registrar
interacts with the CA are transparent to the pledge and are out-of-
scope of this document.
The architecture illustrates shows the cloud registrar and MASA as
being logically separate entities. The two functions could of course
be integrated into a single service.
Friel, et al. Expires May 27, 2020 [Page 3]
Internet-Draft BRSKI-CLOUD November 2019
+--------+ +-----------+
| Pledge |---------------------------------------->| Cloud |
+--------+ | Registrar |
| +-----------+
|
| +-----------+ +-----------+
+---------------->| Local |--------------->| MASA |
| | Registrar | +-----------+
| +-----------+
| | +-----------+
| +--------------------->| CA |
| +-----------+
|
| +-----------+
+---------------->| Services |
+-----------+
Figure 1
2.1. Network Connectivity
The assumption is that the pledge already has network connectivity
prior to connecting to the cloud registrar. The pledge must have an
IP address, must be able to make DNBS queries, and must be able to
send HTTP requests to the cloud registrar. The pledge operator has
already connected the pledge to the network, and the mechanism by
which this has happened is out of scope of this document.
3. Initial Voucher Request
3.1. Cloud Registrar Discovery
BRSKI defines how a pledge MAY contact a well known URI of a cloud
registrar if a local registrar cannot be discovered. Additionally,
certain pledge types may never attempt to discover a local registrar
and may automatically bootstrap against a cloud registrar. The
details of the URI are manufacturer specific, with BRSKI giving the
example "brski-registrar.manufacturer.example.com".
3.2. Pledge - Cloud Registrar TLS Establishment Details
The pledge MUST use an Implicit Trust Anchor database (see [RFC7030])
to authenticate the cloud registrar service as described in
[RFC6125]. The pledge MUST NOT establish a provisional TLS
connection (see BRSKI section 5.1) with the cloud registrar.
The cloud registrar MUST validate the identity of the pledge by
sending a TLS CertificateRequest message to the pledge during TLS
Friel, et al. Expires May 27, 2020 [Page 4]
Internet-Draft BRSKI-CLOUD November 2019
session establishment. The cloud registrar MAY include a
certificate_authorities field in the message to specify the set of
allowed IDevID issuing CAs that pledges may use when establishing
connections with the cloud registrar.
The cloud registrar MAY only allow connections from pledges that have
an IDevID that is signed by one of a specific set of CAs, e.g.
IDevIDs issued by certain manufacturers.
The cloud registrar MAY allow pledges to connect using self-signed
identity certificates or using Raw Public Key [RFC7250] certificates.
3.3. Pledge Requests Voucher from the Cloud Registrar
After the pledge has established a full TLS connection with the cloud
registrar and has verified the cloud registrar PKI identity, the
pledge generates a voucher request message as outlined in BRSKI
section 5.2, and sends the voucher request message to the cloud
registrar.
4. Cloud Registrar Voucher Request Operation
When the cloud registrar has verified the identity of the pledge,
determined the pledge ownership and has received the voucher request,
there are two main options for handling the request.
o the cloud registrar can redirect the voucher request to a local
domain registrar
o the cloud registrar can handle the voucher request directly by
either issuing a voucher or declining the request
4.1. Pledge Ownership Lookup
The cloud registrar needs some suitable mechanism for knowing the
correct owner of a connecting pledge based on the presented identity
certificate. For example, if the pledge establishes TLS using an
IDevID that is signed by a known manufacturing CA, the registrar
could extract the serial number from the IDevID and use this to
lookup a database of pledge IDevID serial numbers to owners.
Alternatively, if the cloud registrar allows pledges to connect using
self-signed certificates, the registrar could use the thumbprint of
the self-signed certificate to lookup a database of pledge self-
signed certificate thumbprints to owners.
The mechanism by which the cloud registrar determines pledge
ownership is out-of-scope of this document.
Friel, et al. Expires May 27, 2020 [Page 5]
Internet-Draft BRSKI-CLOUD November 2019
5. Voucher Request Redirected to Local Domain Registrar
Once the cloud registar has determined pledge ownership, the cloud
registrar may redirect the pledge to the owner's local domain
registrar in order to complete bootstrap. Ownership registration
will require the owner to register their local domain. The mechanism
by which pledge owners register their domain with the cloud registrar
is out-of-scope of this document.
The cloud registrar replies to the voucher request with a suitable
HTTP 3xx response code as per [I-D.ietf-httpbis-bcp56bis], including
the owner's local domain in the HTTP Location header.
5.1. Pledge handling of Redirect
The pledge should complete BRSKI bootstrap as per standard BRSKI
operation after following the HTTP redirect. The pledge should
establish a provisional TLS connection with specified local domain
registrar. The pledge should not use its Implicit Trust Anchor
database for validating the local domain registrar identity. The
pledge should send a voucher request message via the local domain
registrar. When the pledge downloads a voucher, it can validate the
TLS connection to the local domain registrar and continue with
enrollment and bootstrap as per standard BRSKI operation.
6. Voucher Request Handled by Cloud Registrar
If the cloud registrar issues a voucher, it returns the voucher in a
HTTP response with a suitable 2xx response code as per
[I-D.ietf-httpbis-bcp56bis].
[[ TODO: it is TBD which of the following three options should be
used. Possibly 1 or 2 of them, maybe all 3. It is possible that
some options will be explicitly NOT recommended. There are standards
implications too as two of the options require including a DNS-ID in
a Voucher. ]]
There are a few options here:
o Option 1: the pledge completes EST enroll against the cloud
registrar. Once EST enrol is complete, we need a mechanism to
tell the pledge what its service domain is. This could be by
including a service domain in the voucher.
o Option 2: the pledge attempts EST enrol against the cloud
registrar and the cloud registrar responds with a 3xx redirecting
the pledge to the local domain RA in order to complete cert
Friel, et al. Expires May 27, 2020 [Page 6]
Internet-Draft BRSKI-CLOUD November 2019
enrollment. The pledge assumes that services are off the local
domain. This does not require adding an FQDN to the voucher.
o Option 3: we enhance the voucher definition to include local RA
domain info, and the pledge implicitly knows that it if received a
voucher from the cloud registrar, and that voucher included a
local domain FQDN, the pledge knows to do EST enroll against the
local domain. i.e. it got a 200OK from the cloud registrar, and
knows to send the next HTTP request to the EST domain specified in
the voucher. The pledge assumes that services are off the local
domain specified in the voucher.
7. Protocol Details
[[ TODO ]] Missing detailed BRSKI steps e.g. CSR attributes,
logging, etc.
7.1. Voucher Request Redirected to Local Domain Registrar
Friel, et al. Expires May 27, 2020 [Page 7]
Internet-Draft BRSKI-CLOUD November 2019
+--------+ +-----------+ +----------+
| Pledge | | Local | | Cloud RA |
| | | Registrar | | / MASA |
+--------+ +-----------+ +----------+
| |
| 1. Full TLS |
|<----------------------------------------------->|
| |
| 2. Voucher Request |
|------------------------------------------------>|
| |
| 3. 3xx Location: localra.example.com |
|<------------------------------------------------|
| |
| 4. Provisional TLS | |
|<-------------------->| |
| | |
| 5. Voucher Request | |
|--------------------->| 6. Voucher Request |
| |------------------------->|
| | |
| | 7. Voucher Response |
| |<-------------------------|
| 8. Voucher Response | |
|<---------------------| |
| | |
| 9. Validate TLS | |
|<-------------------->| |
| | |
| 10. etc. | |
|--------------------->| |
7.2. Voucher Request Handled by Cloud Registrar
[[ TODO: it is TBD which of the following three options should be
used. Possibly 1 or 2 of them, maybe all 3. It is possible that
some options will be explicitly NOT recommended. There are standards
implications too as two of the options require including a DNS-ID in
a Voucher. ]]
7.2.1. Option 1: EST enroll completed against cloud registrar
The Voucher includes the service domain to use after EST enroll is
complete.
Friel, et al. Expires May 27, 2020 [Page 8]
Internet-Draft BRSKI-CLOUD November 2019
+--------+ +-----------+ +----------+
| Pledge | | Local | | Cloud RA |
| | | Service | | / MASA |
+--------+ +-----------+ +----------+
| |
| 1. Full TLS |
|<----------------------------------------------->|
| |
| 2. Voucher Request |
|------------------------------------------------>|
| |
| 3. Voucher Response {service:fqdn} |
|<------------------------------------------------|
| |
| 4. EST enroll |
|------------------------------------------------>|
| |
| 5. Certificate |
|<------------------------------------------------|
| |
| 6. Full TLS | |
|<-------------------->| |
| | |
| 7. Service Access | |
|--------------------->| |
7.2.2. Option 2: EST redirect by cloud registrar
As trust is already established via the Voucher, the pledge does a
full TLS handshake against the local RA.
This scenario is useful when there an existing EST server that has
already been deployed, but it lacks BRSKI mechanisms. This is common
in SmartGrid deployments.
Friel, et al. Expires May 27, 2020 [Page 9]
Internet-Draft BRSKI-CLOUD November 2019
+--------+ +-----------+ +----------+
| Pledge | | Local | | Cloud RA |
| | | Registrar | | / MASA |
+--------+ +-----------+ +----------+
| |
| 1. Full TLS |
|<----------------------------------------------->|
| |
| 2. Voucher Request |
|------------------------------------------------>|
| |
| 3. Voucher Response |
|<------------------------------------------------|
| |
| 4. EST enroll |
|------------------------------------------------>|
| |
| 5. 3xx Location: localra.example.com |
|<------------------------------------------------|
| |
| 6. Full TLS | |
|<-------------------->| |
| | |
| 7. EST Enrol | |
|--------------------->| |
| | |
| 8. Certificate | |
|<---------------------| |
| | |
| 9. etc. | |
|--------------------->| |
7.2.3. Option 3: Voucher includes EST domain
The Voucher includes the EST domain to use for EST enroll. It is
assumed services are accessed at that domain too. As trust is
already established via the Voucher, the pledge does a full TLS
handshake against the local RA indicated by the voucher response.
Friel, et al. Expires May 27, 2020 [Page 10]
Internet-Draft BRSKI-CLOUD November 2019
+--------+ +-----------+ +----------+
| Pledge | | Local | | Cloud RA |
| | | Registrar | | / MASA |
+--------+ +-----------+ +----------+
| |
| 1. Full TLS |
|<----------------------------------------------->|
| |
| 2. Voucher Request |
|------------------------------------------------>|
| |
| 3. Voucher Response {localra:fqdn} |
|<------------------------------------------------|
| |
| 4. Full TLS | |
|<-------------------->| |
| | |
| 5. EST Enrol | |
|--------------------->| |
| | |
| 6. Certificate | |
|<---------------------| |
| | |
| 7. etc. | |
|--------------------->| |
8. Pledge Certificate Identity Considerations
BRSKI section 5.9.2 specifies that the pledge MUST send a CSR
Attributes request to the registrar. The registrar MAY use this
mechanism to instruct the pledge about the identities it should
include in the CSR request it sends as part of enrollment. The
registrar may use this mechanism to tell the pledge what Subject or
Subject Alternative Name identity information to include in its CSR
request. This can be useful if the Subject must have a specific
value in order to complete enrollment with the CA.
For example, the pledge may only be aware of its IDevID Subject which
includes a manufacturer serial number, but must include a specific
fully qualified domain name in the CSR in order to complete domain
ownership proofs required by the CA. As another example, the
registrar may deem the manufacturer serial number in an IDevID as
personally identifiable information, and may want to specify a new
random opaque identifier that the pledge should use in its CSR.
Friel, et al. Expires May 27, 2020 [Page 11]
Internet-Draft BRSKI-CLOUD November 2019
9. IANA Considerations
[[ TODO ]]
10. Security Considerations
[[ TODO ]]
11. Informative References
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-29 (work in progress), October 2019.
[I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-09 (work in progress), November
2019.
[IEEE802.1AR]
IEEE, ., "Secure Device Identity", 2017.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, <https://www.rfc-
editor.org/info/rfc7030>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
Authors' Addresses
Owen Friel
Cisco
Email: ofriel@cisco.com
Friel, et al. Expires May 27, 2020 [Page 12]
Internet-Draft BRSKI-CLOUD November 2019
Rifaat Shekh-Yusef
Avaya
Email: rifaat.ietf@gmail.com
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Friel, et al. Expires May 27, 2020 [Page 13]