idnits 2.17.1 draft-friel-anima-brski-cloud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '...nes how a pledge MAY contact a well kn...' RFC 2119 keyword, line 154: '... The pledge MUST use an Implicit Trust Anchor database (see [RFC7030])...' RFC 2119 keyword, line 156: '... [RFC6125]. The pledge MUST NOT establish a provisional TLS...' RFC 2119 keyword, line 159: '... cloud registrar MUST validate the ide...' RFC 2119 keyword, line 161: '...nt. The cloud registrar MAY include a...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2019) is 1683 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IEEE802.1AR' is defined on line 450, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-26 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-08 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Shekh-Yusef 5 Expires: March 13, 2020 Avaya 6 M. Richardson 7 Sandelman Software Works 8 September 10, 2019 10 BRSKI Cloud Registrar 11 draft-friel-anima-brski-cloud-00 13 Abstract 15 This document specifies the behaviour of a BRSKI Cloud Registrar, and 16 how a pledge can interact with a BRSKI Cloud Registrar when 17 bootstrapping. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 13, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Initial Voucher Request . . . . . . . . . . . . . . . . . . . 4 56 3.1. Cloud Registrar Discovery . . . . . . . . . . . . . . . . 4 57 3.2. Pledge - Cloud Registrar TLS Establishment Details . . . 4 58 3.3. Pledge Requests Voucher from the Cloud Registrar . . . . 4 59 4. Cloud Registrar Voucher Request Operation . . . . . . . . . . 4 60 4.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . . . 5 61 5. Voucher Request Redirected to Local Domain Registrar . . . . 5 62 5.1. Pledge handling of Redirect . . . . . . . . . . . . . . . 5 63 6. Voucher Request Handled by Cloud Registrar . . . . . . . . . 6 64 7. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Voucher Request Redirected to Local Domain Registrar . . 6 66 7.2. Voucher Request Handled by Cloud Registrar . . . . . . . 7 67 7.2.1. Option 1: EST enroll completed against cloud 68 registrar . . . . . . . . . . . . . . . . . . . . . . 7 69 7.2.2. Option 2: EST redirect by cloud registrar . . . . . . 8 70 7.2.3. Option 3: Voucher includes EST domain . . . . . . . . 9 71 8. Pledge Certificate Identity Considerations . . . . . . . . . 10 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 11. Informative References . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 80 [I-D.ietf-anima-bootstrapping-keyinfra] specifies automated 81 bootstrapping of an Autonomic Control Plane. BRSKI Section 2.7 82 describes how a pledge "MAY contact a well known URI of a cloud 83 registrar if a local registrar cannot be discovered or if the 84 pledge's target use cases do not include a local registrar". 86 This document further specifies use of a BRSKI cloud registrar and 87 clarifies operations that are not sufficiently specified in BRSKI. 89 Two high level deployment models are documented here: 91 o Local Domain Registrar Discovery: the cloud registrar is used by 92 the pledge to discover the local domain registrar. The cloud 93 registrar redirects the pledge to the local domain registrar, and 94 the pledge completes bootstrap against the local domain registrar. 96 o Cloud Registrar Based Boostrap: there is no local domain registrar 97 and the pledge completes boostrap using the cloud registrar. As 98 part of boostrap, the cloud registrar may need to tell the client 99 the domain to use for accessing services. 101 2. Architecture 103 The high level architecture is illustrated in Figure 1. The pledge 104 connects to the cloud registrar during bootstrap. The cloud 105 registrar may redirect the pledge to a local registrar in order to 106 complete bootstrap against the local registrar. If the cloud 107 registrar handles the bootstrap process itself without redirecting 108 the pledge to a local registrar, the cloud registrar may need to 109 inform the pledge what domain to use for accessing services once 110 bootstrap is complete. 112 Finally, when bootstrapping against a local registrar, the registrar 113 may interact with a backend CA to assist in issuing certificates to 114 the pledge. The mechanisms and protocols by which the registrar 115 interacts with the CA are transparent to the pledge and are out-of- 116 scope of this document. 118 The architecture illustrates shows the cloud registrar and MASA as 119 being logically separate entities. The two functions could of course 120 be integrated into a single service. 122 +--------+ +-----------+ 123 | Pledge |---------------------------------------->| Cloud | 124 +--------+ | Registrar | 125 | +-----------+ 126 | 127 | +-----------+ +-----------+ 128 +---------------->| Local |--------------->| MASA | 129 | | Registrar | +-----------+ 130 | +-----------+ 131 | | +-----------+ 132 | +--------------------->| CA | 133 | +-----------+ 134 | 135 | +-----------+ 136 +---------------->| Services | 137 +-----------+ 139 Figure 1 141 3. Initial Voucher Request 143 3.1. Cloud Registrar Discovery 145 BRSKI defines how a pledge MAY contact a well known URI of a cloud 146 registrar if a local registrar cannot be discovered. Additionally, 147 certain pledge types may never attempt to discover a local registrar 148 and may automatically bootstrap against a cloud registrar. The 149 details of the URI are manufacturer specific, with BRSKI giving the 150 example "brski-registrar.manufacturer.example.com". 152 3.2. Pledge - Cloud Registrar TLS Establishment Details 154 The pledge MUST use an Implicit Trust Anchor database (see [RFC7030]) 155 to authenticate the cloud registrar service as described in 156 [RFC6125]. The pledge MUST NOT establish a provisional TLS 157 connection (see BRSKI section 5.1) with the cloud registrar. 159 The cloud registrar MUST validate the identity of the pledge by 160 sending a TLS CertificateRequest message to the pledge during TLS 161 session establishment. The cloud registrar MAY include a 162 certificate_authorities field in the message to specify the set of 163 allowed IDevID issuing CAs that pledges may use when establishing 164 connections with the cloud registrar. 166 The cloud registrar MAY only allow connections from pledges that have 167 an IDevID that is signed by one of a specific set of CAs, e.g. 168 IDevIDs issued by certain manufacturers. 170 The cloud registrar MAY allow pledges to connect using self-signed 171 identity certificates or using Raw Public Key [RFC7250] certificates. 173 3.3. Pledge Requests Voucher from the Cloud Registrar 175 After the pledge has established a full TLS connection with the cloud 176 registrar and has verified the cloud registrar PKI identity, the 177 pledge generates a voucher request message as outlined in BRSKI 178 section 5.2, and sends the voucher request message to the cloud 179 registrar. 181 4. Cloud Registrar Voucher Request Operation 183 When the cloud registrar has verified the identity of the pledge, 184 determined the pledge ownership and has received the voucher request, 185 there are two main options for handling the request. 187 o the cloud registrar can redirect the voucher request to a local 188 domain registrar 190 o the cloud registrar can handle the voucher request directly by 191 either issuing a voucher or declining the request 193 4.1. Pledge Ownership Lookup 195 The cloud registrar needs some suitable mechanism for knowing the 196 correct owner of a connecting pledge based on the presented identity 197 certificate. For example, if the pledge establishes TLS using an 198 IDevID that is signed by a known manufacturing CA, the registrar 199 could extract the serial number from the IDevID and use this to 200 lookup a database of pledge IDevID serial numbers to owners. 202 Alternatively, if the cloud registrar allows pledges to connect using 203 self-signed certificates, the registrar could use the thumbprint of 204 the self-signed certificate to lookup a database of pledge self- 205 signed certificate thumbprints to owners. 207 The mechanism by which the cloud registrar determines pledge 208 ownership is out-of-scope of this document. 210 5. Voucher Request Redirected to Local Domain Registrar 212 Once the cloud registar has determined pledge ownership, the cloud 213 registrar may redirect the pledge to the owner's local domain 214 registrar in order to complete bootstrap. Ownership registration 215 will require the owner to register their local domain. The mechanism 216 by which pledge owners register their domain with the cloud registrar 217 is out-of-scope of this document. 219 The cloud registrar replies to the voucher request with a suitable 220 HTTP 3xx response code as per [I-D.ietf-httpbis-bcp56bis], including 221 the owner's local domain in the HTTP Location header. 223 5.1. Pledge handling of Redirect 225 The pledge should complete BRSKI bootstrap as per standard BRSKI 226 operation after following the HTTP redirect. The pledge should 227 establish a provisional TLS connection with specified local domain 228 registrar. The pledge should not use its Implicit Trust Anchor 229 database for validating the local domain registrar identity. The 230 pledge should send a voucher request message via the local domain 231 registrar. When the pledge downloads a voucher, it can validate the 232 TLS connection to the local domain registrar and continue with 233 enrollment and bootstrap as per standard BRSKI operation. 235 6. Voucher Request Handled by Cloud Registrar 237 If the cloud registrar issues a voucher, it returns the voucher in a 238 HTTP response with a suitable 2xx response code as per 239 [I-D.ietf-httpbis-bcp56bis]. 241 [[ TODO ]] There are a few options here: 243 o Option 1: the pledge completes EST enroll against the cloud 244 registrar. Once EST enrol is complete, we need a mechanism to 245 tell the pledge what its service domain is. This could be by 246 including a service domain in the voucher. 248 o Option 2: the pledge attempts EST enrol against the cloud 249 registrar and the cloud registrar responds with a 3xx redirecting 250 the pledge to the local domain RA in order to complete cert 251 enrollment. The pledge assumes that services are off the local 252 domain. This does not require adding an FQDN to the voucher. 254 o Option 3: we enhance the voucher definition to include local RA 255 domain info, and the pledge implicitly knows that it if received a 256 voucher from the cloud registrar, and that voucher included a 257 local domain FQDN, the pledge knows to do EST enroll against the 258 local domain. i.e. it got a 200OK from the cloud registrar, and 259 knows to send the next HTTP request to the EST domain specified in 260 the voucher. The pledge assumes that services are off the local 261 domain specified in the voucher. 263 7. Protocol Details 265 [[ TODO ]] Missing detailed BRSKI steps e.g. CSR attributes, 266 logging, etc. 268 7.1. Voucher Request Redirected to Local Domain Registrar 269 +--------+ +-----------+ +----------+ 270 | Pledge | | Local | | Cloud RA | 271 | | | Registrar | | / MASA | 272 +--------+ +-----------+ +----------+ 273 | | 274 | 1. Full TLS | 275 |<----------------------------------------------->| 276 | | 277 | 2. Voucher Request | 278 |------------------------------------------------>| 279 | | 280 | 3. 3xx Location: localra.example.com | 281 |<------------------------------------------------| 282 | | 283 | 4. Provisional TLS | | 284 |<-------------------->| | 285 | | | 286 | 5. Voucher Request | | 287 |--------------------->| 6. Voucher Request | 288 | |------------------------->| 289 | | | 290 | | 7. Voucher Response | 291 | |<-------------------------| 292 | 8. Voucher Response | | 293 |<---------------------| | 294 | | | 295 | 9. Validate TLS | | 296 |<-------------------->| | 297 | | | 298 | 10. etc. | | 299 |--------------------->| | 301 7.2. Voucher Request Handled by Cloud Registrar 303 [[ TODO: it is TBD which of the following three options should be 304 used. Possibly 1 or 2 of them, maybe all 3. It is possible that 305 some options will be explicitly NOT recommended. There are standards 306 implications too as two of the options require including a DNS-ID in 307 a Voucher. ]] 309 7.2.1. Option 1: EST enroll completed against cloud registrar 311 The Voucher includes the service domain to use after EST enroll is 312 complete. 314 +--------+ +-----------+ +----------+ 315 | Pledge | | Local | | Cloud RA | 316 | | | Service | | / MASA | 317 +--------+ +-----------+ +----------+ 318 | | 319 | 1. Full TLS | 320 |<----------------------------------------------->| 321 | | 322 | 2. Voucher Request | 323 |------------------------------------------------>| 324 | | 325 | 3. Voucher Response {service:fqdn} | 326 |<------------------------------------------------| 327 | | 328 | 4. EST enroll | 329 |------------------------------------------------>| 330 | | 331 | 5. Certificate | 332 |<------------------------------------------------| 333 | | 334 | 6. Full TLS | | 335 |<-------------------->| | 336 | | | 337 | 7. Service Access | | 338 |--------------------->| | 340 7.2.2. Option 2: EST redirect by cloud registrar 342 As trust is already established via the Voucher, the pledge does a 343 full TLS handshake against the local RA. 345 +--------+ +-----------+ +----------+ 346 | Pledge | | Local | | Cloud RA | 347 | | | Registrar | | / MASA | 348 +--------+ +-----------+ +----------+ 349 | | 350 | 1. Full TLS | 351 |<----------------------------------------------->| 352 | | 353 | 2. Voucher Request | 354 |------------------------------------------------>| 355 | | 356 | 3. Voucher Response | 357 |<------------------------------------------------| 358 | | 359 | 4. EST enroll | 360 |------------------------------------------------>| 361 | | 362 | 5. 3xx Location: localra.example.com | 363 |<------------------------------------------------| 364 | | 365 | 6. Full TLS | | 366 |<-------------------->| | 367 | | | 368 | 7. EST Enrol | | 369 |--------------------->| | 370 | | | 371 | 8. Certificate | | 372 |<---------------------| | 373 | | | 374 | 9. etc. | | 375 |--------------------->| | 377 7.2.3. Option 3: Voucher includes EST domain 379 The Voucher includes the EST domain to use for EST enroll. It is 380 assumed services are accessed at that domain too. As trust is 381 already established via the Voucher, the pledge does a full TLS 382 handshake against the local RA. 384 +--------+ +-----------+ +----------+ 385 | Pledge | | Local | | Cloud RA | 386 | | | Registrar | | / MASA | 387 +--------+ +-----------+ +----------+ 388 | | 389 | 1. Full TLS | 390 |<----------------------------------------------->| 391 | | 392 | 2. Voucher Request | 393 |------------------------------------------------>| 394 | | 395 | 3. Voucher Response {localra:fqdn} | 396 |<------------------------------------------------| 397 | | 398 | 4. Full TLS | | 399 |<-------------------->| | 400 | | | 401 | 5. EST Enrol | | 402 |--------------------->| | 403 | | | 404 | 6. Certificate | | 405 |<---------------------| | 406 | | | 407 | 7. etc. | | 408 |--------------------->| | 410 8. Pledge Certificate Identity Considerations 412 BRSKI section 5.9.2 specifies that the pledge MUST send a CSR 413 Attributes request to the registrar. The registrar MAY use this 414 mechanism to instruct the pledge about the identities it should 415 include in the CSR request it sends as part of enrollment. The 416 registrar may use this mechanism to tell the pledge what Subject or 417 Subject Alternative Name identity information to include in its CSR 418 request. This can be useful if the Subject must have a specific 419 value in order to complete enrollment with the CA. 421 For example, the pledge may only be aware of its IDevID Subject which 422 includes a manufacturer serial number, but must include a specific 423 fully qualified domain name in the CSR in order to complete domain 424 ownership proofs required by the CA. As another example, the 425 registrar may deem the manufacturer serial number in an IDevID as 426 personally identifiable information, and may want to specify a new 427 random opaque identifier that the pledge should use in its CSR. 429 9. IANA Considerations 431 [[ TODO ]] 433 10. Security Considerations 435 [[ TODO ]] 437 11. Informative References 439 [I-D.ietf-anima-bootstrapping-keyinfra] 440 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 441 and K. Watsen, "Bootstrapping Remote Secure Key 442 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 443 keyinfra-26 (work in progress), August 2019. 445 [I-D.ietf-httpbis-bcp56bis] 446 Nottingham, M., "Building Protocols with HTTP", draft- 447 ietf-httpbis-bcp56bis-08 (work in progress), November 448 2018. 450 [IEEE802.1AR] 451 IEEE, ., "Secure Device Identity", 2017. 453 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 454 Verification of Domain-Based Application Service Identity 455 within Internet Public Key Infrastructure Using X.509 456 (PKIX) Certificates in the Context of Transport Layer 457 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 458 2011, . 460 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 461 "Enrollment over Secure Transport", RFC 7030, 462 DOI 10.17487/RFC7030, October 2013, 463 . 465 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 466 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 467 Transport Layer Security (TLS) and Datagram Transport 468 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 469 June 2014, . 471 Authors' Addresses 473 Owen Friel 474 Cisco 476 Email: ofriel@cisco.com 477 Rifaat Shekh-Yusef 478 Avaya 480 Email: rifaat.ietf@gmail.com 482 Michael Richardson 483 Sandelman Software Works 485 Email: mcr+ietf@sandelman.ca