idnits 2.17.1 draft-friel-anima-brski-cloud-02.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 208: '...nes how a pledge MAY contact a well kn...' RFC 2119 keyword, line 217: '... The pledge MUST use an Implicit Trust Anchor database (see [RFC7030])...' RFC 2119 keyword, line 219: '... [RFC6125]. The pledge MUST NOT establish a provisional TLS...' RFC 2119 keyword, line 222: '... cloud registrar MUST validate the ide...' RFC 2119 keyword, line 224: '...nt. The cloud registrar MAY include a...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 May 2020) is 1456 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 423, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-09 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: 3 November 2020 Avaya 6 M. Richardson 7 Sandelman Software Works 8 2 May 2020 10 BRSKI Cloud Registrar 11 draft-friel-anima-brski-cloud-02 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 3 November 2020. 36 Copyright Notice 38 Copyright (c) 2020 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 (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Target use cases . . . . . . . . . . . . . . . . . . . . 3 54 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Interested Parties . . . . . . . . . . . . . . . . . . . 4 56 2.2. Network Connectivity . . . . . . . . . . . . . . . . . . 5 57 3. Initial Voucher Request . . . . . . . . . . . . . . . . . . . 5 58 3.1. Cloud Registrar Discovery . . . . . . . . . . . . . . . . 5 59 3.2. Pledge - Cloud Registrar TLS Establishment Details . . . 5 60 3.3. Pledge Requests Voucher from the Cloud Registrar . . . . 5 61 4. Cloud Registrar Voucher Request Operation . . . . . . . . . . 6 62 4.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . . . 6 63 5. Voucher Request Redirected to Local Domain Registrar . . . . 6 64 5.1. Pledge handling of Redirect . . . . . . . . . . . . . . . 7 65 6. Voucher Request Handled by Cloud Registrar . . . . . . . . . 7 66 7. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Voucher Request Redirected to Local Domain Registrar . . 7 68 7.2. Voucher Request Handled by Cloud Registrar . . . . . . . 8 69 8. Pledge Certificate Identity Considerations . . . . . . . . . 9 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 11. Informative References . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 78 [I-D.ietf-anima-bootstrapping-keyinfra] specifies automated 79 bootstrapping of an Autonomic Control Plane. BRSKI Section 2.7 80 describes how a pledge "MAY contact a well known URI of a cloud 81 registrar if a local registrar cannot be discovered or if the 82 pledge's target use cases do not include a local registrar". 84 This document further specifies use of a BRSKI cloud registrar and 85 clarifies operations that are not sufficiently specified in BRSKI. 87 Two high level deployment models are documented here: 89 * Local Domain Registrar Discovery: the cloud registrar is used by 90 the pledge to discover the local domain registrar. The cloud 91 registrar redirects the pledge to the local domain registrar, and 92 the pledge completes bootstrap against the local domain registrar. 94 * Cloud Registrar Based Boostrap: there is no local domain registrar 95 and the pledge completes boostrap using the cloud registrar. As 96 part of boostrap, the cloud registrar may need to tell the client 97 the domain to use for accessing services. 99 These deployment models facilitate multiple use cases including: 101 * A pledge is bootstrapping in a remote location and needs to 102 contact a cloud registrar in order to discover the address of its 103 local domain. 105 * A pledge can connect to a manufacturer hosted cloud service or the 106 same software running on-premise. The systems might not be 107 discoverable locally. 109 * A pledge needs to connect to a third-party hosted registrar 110 service, because there is no local registrar service available. 112 * A pledge needs to discover the deployment model in use by the 113 pledge operator, which might include going into some local 114 configuration mode. 116 1.1. Target use cases 118 An end user unboxes a device, and connects it to a local network 119 (using a cable). The device should join a (owner domain) Registrar 120 operated by the end user's organization, which is not physically 121 present on the local network. 123 The end user is at their home office, while the device belongs to 124 their work. Or the end user is at a small satellite office which 125 lacks correctly trained IT personnel. 127 The end user's organization operates an (owner domain) Registrar at 128 their head-quarters, or in a hosted data center. A registrar may 129 also be operated on behalf of the owner through an outsourced IT 130 arrangement. 132 2. Architecture 134 The high level architecture is illustrated in Figure 1. 136 The pledge connects to the cloud registrar during bootstrap. 138 The cloud registrar may redirect the pledge to a local/owner 139 registrar in order to complete bootstrap against the local registrar. 141 If the cloud registrar handles the bootstrap process itself without 142 redirecting the pledge to a local registrar, the cloud registrar may 143 need to inform the pledge what domain to use for accessing services 144 once bootstrap is complete. 146 Finally, when bootstrapping against a local/owner registrar, this 147 registrar may interact with a backend CA to assist in issuing 148 certificates to the pledge. The mechanisms and protocols by which 149 the registrar interacts with the CA are transparent to the pledge and 150 are out-of-scope of this document. 152 The architecture illustrates shows the cloud registrar and MASA as 153 being logically separate entities. The two functions could of course 154 be integrated into a single service. 156 XXX NONCE-less voucher. If the Cloud Registrar issues a voucher 157 directly, while it may include a nonce, because that nonce does not 158 go through the Owner, which means that the MASA has no audit trail 159 that the pledge really connected to the Owner Registrar. 161 TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. 162 Cloud Registrar returns VOUCHER pinning Owner Register. 164 |<--------------OWNER------------------------>| MANUFACTURER 166 On-site Cloud 167 +--------+ +-----------+ 168 | Pledge |---------------------------------------->| Cloud | 169 +--------+ | Registrar | 170 | +---+ +----+ 171 | |??| 172 | +-----------+ +---+ +----+ 173 +---------------->| Owner |--------------->| MASA | 174 | VR-sign(N) | Registrar |sign(VR-sign(N))+-----------+ 175 | +-----------+ 176 | | +-----------+ 177 | +--->| CA | 178 | +-----------+ 179 | 180 | +-----------+ 181 +---------------->| Services | 182 +-----------+ 184 Figure 1: High Level Architecture 186 2.1. Interested Parties 188 1. OEM - Equipment manufacturer. Operate the MASA. 190 2. Network operator. Operate the Local Registrar. Often operated 191 by end owner (company), or by outsourced IT entity. 193 3. Network integrator. They operate ?Cloud Registrar?. 195 2.2. Network Connectivity 197 The assumption is that the pledge already has network connectivity 198 prior to connecting to the cloud registrar. The pledge must have an 199 IP address, must be able to make DNBS queries, and must be able to 200 send HTTP requests to the cloud registrar. The pledge operator has 201 already connected the pledge to the network, and the mechanism by 202 which this has happened is out of scope of this document. 204 3. Initial Voucher Request 206 3.1. Cloud Registrar Discovery 208 BRSKI defines how a pledge MAY contact a well known URI of a cloud 209 registrar if a local registrar cannot be discovered. Additionally, 210 certain pledge types may never attempt to discover a local registrar 211 and may automatically bootstrap against a cloud registrar. The 212 details of the URI are manufacturer specific, with BRSKI giving the 213 example "brski-registrar.manufacturer.example.com". 215 3.2. Pledge - Cloud Registrar TLS Establishment Details 217 The pledge MUST use an Implicit Trust Anchor database (see [RFC7030]) 218 to authenticate the cloud registrar service as described in 219 [RFC6125]. The pledge MUST NOT establish a provisional TLS 220 connection (see BRSKI section 5.1) with the cloud registrar. 222 The cloud registrar MUST validate the identity of the pledge by 223 sending a TLS CertificateRequest message to the pledge during TLS 224 session establishment. The cloud registrar MAY include a 225 certificate_authorities field in the message to specify the set of 226 allowed IDevID issuing CAs that pledges may use when establishing 227 connections with the cloud registrar. 229 The cloud registrar MAY only allow connections from pledges that have 230 an IDevID that is signed by one of a specific set of CAs, e.g. 231 IDevIDs issued by certain manufacturers. 233 The cloud registrar MAY allow pledges to connect using self-signed 234 identity certificates or using Raw Public Key [RFC7250] certificates. 236 3.3. Pledge Requests Voucher from the Cloud Registrar 238 After the pledge has established a full TLS connection with the cloud 239 registrar and has verified the cloud registrar PKI identity, the 240 pledge generates a voucher request message as outlined in BRSKI 241 section 5.2, and sends the voucher request message to the cloud 242 registrar. 244 4. Cloud Registrar Voucher Request Operation 246 When the cloud registrar has verified the identity of the pledge, 247 determined the pledge ownership and has received the voucher request, 248 there are two main options for handling the request. 250 * the cloud registrar can redirect the voucher request to a local 251 domain registrar 253 * the cloud registrar can handle the voucher request directly by 254 either issuing a voucher or declining the request 256 4.1. Pledge Ownership Lookup 258 The cloud registrar needs some suitable mechanism for knowing the 259 correct owner of a connecting pledge based on the presented identity 260 certificate. For example, if the pledge establishes TLS using an 261 IDevID that is signed by a known manufacturing CA, the registrar 262 could extract the serial number from the IDevID and use this to 263 lookup a database of pledge IDevID serial numbers to owners. 265 Alternatively, if the cloud registrar allows pledges to connect using 266 self-signed certificates, the registrar could use the thumbprint of 267 the self-signed certificate to lookup a database of pledge self- 268 signed certificate thumbprints to owners. 270 The mechanism by which the cloud registrar determines pledge 271 ownership is out-of-scope of this document. 273 5. Voucher Request Redirected to Local Domain Registrar 275 Once the cloud registar has determined pledge ownership, the cloud 276 registrar may redirect the pledge to the owner's local domain 277 registrar in order to complete bootstrap. Ownership registration 278 will require the owner to register their local domain. The mechanism 279 by which pledge owners register their domain with the cloud registrar 280 is out-of-scope of this document. 282 The cloud registrar replies to the voucher request with a suitable 283 HTTP 3xx response code as per [I-D.ietf-httpbis-bcp56bis], including 284 the owner's local domain in the HTTP Location header. 286 5.1. Pledge handling of Redirect 288 The pledge should complete BRSKI bootstrap as per standard BRSKI 289 operation after following the HTTP redirect. The pledge should 290 establish a provisional TLS connection with specified local domain 291 registrar. The pledge should not use its Implicit Trust Anchor 292 database for validating the local domain registrar identity. The 293 pledge should send a voucher request message via the local domain 294 registrar. When the pledge downloads a voucher, it can validate the 295 TLS connection to the local domain registrar and continue with 296 enrollment and bootstrap as per standard BRSKI operation. 298 6. Voucher Request Handled by Cloud Registrar 300 If the cloud registrar issues a voucher, it returns the voucher in a 301 HTTP response with a suitable 2xx response code as per 302 [I-D.ietf-httpbis-bcp56bis]. 304 Alternatively, it may redirect to the customers' Registration 305 Authority (RA) with a 307 Temporary Redirect to locate the RA. The 306 client MUST POST its voucher request to the new location. 308 7. Protocol Details 310 [[ TODO ]] Missing detailed BRSKI steps e.g. CSR attributes, 311 logging, etc. 313 7.1. Voucher Request Redirected to Local Domain Registrar 315 This is FLOW ONE. EXPLAIN APPLICABILITY. 317 +--------+ +-----------+ +----------+ 318 | Pledge | | Local | | Cloud RA | 319 | | | Registrar | | | 320 +--------+ +-----------+ +----------+ 321 | | 322 | 1. Mutual-authenticated TLS | 323 |<----------------------------------------------->| 324 | | 325 | 2. Voucher Request | 326 |------------------------------------------------>| 327 | | 328 | 3. 307 Location: localra.example.com | 329 |<------------------------------------------------| 330 | 331 | 4. Provisional TLS | +---------+ 332 |<-------------------->| | MASA | 333 | | +---------+ 334 | 5. Voucher Request | | 335 |--------------------->| 6. Voucher Request | 336 | |------------------------->| 337 | | | 338 | | 7. Voucher Response | 339 | |<-------------------------| 340 | 8. Voucher Response | | 341 |<---------------------| | 342 | | | 343 | 9. Validate TLS | | 344 |<-------------------->| | 345 | | | 346 | 10. etc. | | 347 |--------------------->| | 349 7.2. Voucher Request Handled by Cloud Registrar 351 The Voucher includes the EST domain to use for EST enroll. It is 352 assumed services are accessed at that domain too. As trust is 353 already established via the Voucher, the pledge does a full TLS 354 handshake against the local RA indicated by the voucher response. 356 EXPLAIN APPLICABILITY. NEEDS EXTENSTION to Voucher. 358 +--------+ +----------+ 359 | Pledge | | Cloud RA | 360 | | | / MASA | 361 +--------+ +----------+ 362 | | 363 | 1. Full TLS | 364 |<----------------------------------------------->| 365 | | 366 | 2. Voucher Request | 367 |------------------------------------------------>| 368 | | 369 | 3. Voucher Response {localra:fqdn} | 370 |<------------------------------------------------| 371 | | 372 | +----------+ | 373 | | RFC7030 | | 374 | | EST | | 375 | | Registrar| | 376 | +----------+ | 377 | | | 378 | 4. Full TLS | | 379 |<-------------------->| | 380 | | 381 | 3a. /voucher_status POST success | 382 |------------------------------------------------>| 383 | ON FAILURE 3b. /voucher_status POST | 384 | | 385 | 5. EST Enrol | | 386 |--------------------->| | 387 | | | 388 | 6. Certificate | | 389 |<---------------------| | 390 | | | 391 | 7. /enrollstatus | | 392 |--------------------->| | 394 8. Pledge Certificate Identity Considerations 396 BRSKI section 5.9.2 specifies that the pledge MUST send a CSR 397 Attributes request to the registrar. The registrar MAY use this 398 mechanism to instruct the pledge about the identities it should 399 include in the CSR request it sends as part of enrollment. The 400 registrar may use this mechanism to tell the pledge what Subject or 401 Subject Alternative Name identity information to include in its CSR 402 request. This can be useful if the Subject must have a specific 403 value in order to complete enrollment with the CA. 405 For example, the pledge may only be aware of its IDevID Subject which 406 includes a manufacturer serial number, but must include a specific 407 fully qualified domain name in the CSR in order to complete domain 408 ownership proofs required by the CA. As another example, the 409 registrar may deem the manufacturer serial number in an IDevID as 410 personally identifiable information, and may want to specify a new 411 random opaque identifier that the pledge should use in its CSR. 413 9. IANA Considerations 415 [[ TODO ]] 417 10. Security Considerations 419 [[ TODO ]] 421 11. Informative References 423 [IEEE802.1AR] 424 IEEE, ., "Secure Device Identity", 2017. 426 [I-D.ietf-anima-bootstrapping-keyinfra] 427 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 428 and K. Watsen, "Bootstrapping Remote Secure Key 429 Infrastructures (BRSKI)", Work in Progress, Internet- 430 Draft, draft-ietf-anima-bootstrapping-keyinfra-41, 8 April 431 2020, . 434 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 435 "Enrollment over Secure Transport", RFC 7030, 436 DOI 10.17487/RFC7030, October 2013, 437 . 439 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 440 Verification of Domain-Based Application Service Identity 441 within Internet Public Key Infrastructure Using X.509 442 (PKIX) Certificates in the Context of Transport Layer 443 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 444 2011, . 446 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 447 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 448 Transport Layer Security (TLS) and Datagram Transport 449 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 450 June 2014, . 452 [I-D.ietf-httpbis-bcp56bis] 453 Nottingham, M., "Building Protocols with HTTP", Work in 454 Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09, 455 1 November 2019, . 458 Authors' Addresses 460 Owen Friel 461 Cisco 463 Email: ofriel@cisco.com 465 Rifaat Shekh-Yusef 466 Avaya 468 Email: rifaat.ietf@gmail.com 470 Michael Richardson 471 Sandelman Software Works 473 Email: mcr+ietf@sandelman.ca