idnits 2.17.1 draft-ietf-anima-brski-cloud-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 May 2022) is 702 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 913, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-richardson-lamps-rfc7030-csrattrs-02 == Outdated reference: A later version (-09) exists of draft-richardson-t2trg-idevid-considerations-06 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Duplicate reference: RFC7030, mentioned in 'RFC7030', was also mentioned in 'EST'. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: 25 November 2022 Auth0 6 M. Richardson 7 Sandelman Software Works 8 24 May 2022 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-04 13 Abstract 15 This document specifies the behavior of a BRSKI Cloud Registrar, and 16 how a pledge can interact with a BRSKI Cloud Registrar when 17 bootstrapping. 19 RFCED REMOVE: It is being actively worked on at https://github.com/ 20 anima-wg/brski-cloud 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 25 November 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Target Use Cases . . . . . . . . . . . . . . . . . . . . 3 58 1.2.1. Owner Registrar Discovery . . . . . . . . . . . . . . 4 59 1.2.2. Bootstrapping with no Owner Registrar . . . . . . . . 4 60 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Interested Parties . . . . . . . . . . . . . . . . . . . 6 62 2.2. Network Connectivity . . . . . . . . . . . . . . . . . . 6 63 2.3. Pledge Certificate Identity Considerations . . . . . . . 6 64 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Pledge Requests Voucher from Cloud Registrar . . . . . . 7 66 3.1.1. Cloud Registrar Discovery . . . . . . . . . . . . . . 7 67 3.1.2. Pledge - Cloud Registrar TLS Establishment Details . 7 68 3.1.3. Pledge Issues Voucher Request . . . . . . . . . . . . 8 69 3.2. Cloud Registrar Handles Voucher Request . . . . . . . . . 8 70 3.2.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . 8 71 3.2.2. Cloud Registrar Redirects to Owner Registrar . . . . 9 72 3.2.3. Cloud Registrar Issues Voucher . . . . . . . . . . . 9 73 3.3. Pledge Handles Cloud Registrar Response . . . . . . . . . 9 74 3.3.1. Redirect Response . . . . . . . . . . . . . . . . . . 9 75 3.3.2. Voucher Response . . . . . . . . . . . . . . . . . . 10 76 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1. Voucher Request Redirected to Local Domain Registrar . . 10 78 4.2. Voucher Request Handled by Cloud Registrar . . . . . . . 12 79 5. YANG extension for Voucher based redirect . . . . . . . . . . 14 80 5.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.2. YANG Voucher . . . . . . . . . . . . . . . . . . . . . . 15 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 84 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 7.1. Issues with Security of HTTP Redirect . . . . . . . . . . 18 87 7.2. Security Updates for the Pledge . . . . . . . . . . . . . 19 88 7.3. Trust Anchors for Cloud Registrar . . . . . . . . . . . . 19 89 7.4. Issues with Redirect via Voucher . . . . . . . . . . . . 20 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 92 8.2. Informative References . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 95 1. Introduction 97 Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies 98 automated bootstrapping of an Autonomic Control Plane. BRSKI 99 Section 2.7 describes how a pledge "MAY contact a well-known URI of a 100 cloud registrar if a local registrar cannot be discovered or if the 101 pledge's target use cases do not include a local registrar". 103 This document further specifies use of a BRSKI cloud registrar and 104 clarifies operations that are not sufficiently specified in BRSKI. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 This document uses the terms Pledge, Registrar, MASA, and Voucher 115 from [BRSKI] and [RFC8366]. 117 * Local Domain: The domain where the pledge is physically located 118 and bootstrapping from. This may be different to the pledge 119 owner's domain. 121 * Owner Domain: The domain that the pledge needs to discover and 122 bootstrap with. 124 * Cloud Registrar: The default Registrar that is deployed at a URI 125 that is well known to the pledge. 127 * Owner Registrar: The Registrar that is operated by the Owner, or 128 the Owner's delegate. There may not be an Owner Registrar in all 129 deployment scenarios. 131 * Local Domain Registrar: The Registrar discovered on the Local 132 Domain. There may not be a Local Domain Registrar in all 133 deployment scenarios. 135 1.2. Target Use Cases 137 Two high level use cases are documented here. There are more details 138 provided in sections Section 4.1 and Section 4.2. While both use 139 cases aid with incremental deployment of BRSKI infrastructure, for 140 many smaller sites (such as teleworkers) no further infrastructure 141 are expected. 143 The pledge is not expected to know which of these two situations it 144 is in. The pledge determines this based upon signals that it 145 receives from the Cloud Registrar. The Cloud Registrar is expected 146 to make the determination based upon the identity presented by the 147 pledge. 149 While a Cloud Registrar will typically handle all the devices of a 150 particular product line from a particular manufacturer there are no 151 restrictions on how the Cloud Registrar is horizontally (many sites) 152 or vertically (more equipment at one site) scaled. It is also 153 entirely possible that all devices sold by through a particular VAR 154 might be preloaded with a configuration that changes the Cloud 155 Registrar URL to point to a VAR. Such an effort would require 156 unboxing each device in a controlled environment, but the 157 provisioning could occur using a regular BRSKI or SZTP [RFC8572] 158 process. 160 1.2.1. Owner Registrar Discovery 162 A pledge is bootstrapping from a remote location with no local domain 163 registrar (specifically: with no local infrastructure to provide for 164 automated discovery), and needs to discover its owner registrar. The 165 cloud registrar is used by the pledge to discover the owner 166 registrar. The cloud registrar redirects the pledge to the owner 167 registrar, and the pledge completes bootstrap against the owner 168 registrar. 170 A typical example is an enduser deploying a pledge in a home or small 171 branch office, where the pledge belongs to the enduser's employer. 172 There is no local domain registrar, and the pledge needs to discover 173 and bootstrap with the employer's registrar which is deployed in 174 headquarters. For example, an enduser is deploying an IP phone in a 175 home office and the phone needs to register to an IP PBX deployed in 176 their employer's office. 178 1.2.2. Bootstrapping with no Owner Registrar 180 A pledge is bootstrapping where the owner organization does not yet 181 have an owner registrar deployed. The cloud registrar issues a 182 voucher, and the pledge completes trust bootstrap using the cloud 183 registrar. The voucher issued by the cloud includes domain 184 information for the owner's [EST] service the pledge should use for 185 certificate enrollment. 187 In one use case, an organization has an EST service deployed, but 188 does not have yet a BRSKI capable Registrar service deployed. The 189 pledge is deployed in the organization's domain, but does not 190 discover a local domain, or owner, registrar. The pledge uses the 191 cloud registrar to bootstrap, and the cloud registrar provides a 192 voucher that includes instructions on finding the organization's EST 193 service. 195 2. Architecture 197 The high level architecture is illustrated in Figure 1. 199 The pledge connects to the cloud registrar during bootstrap. 201 The cloud registrar may redirect the pledge to an owner registrar in 202 order to complete bootstrap against the owner registrar. 204 If the cloud registrar issues a voucher itself without redirecting 205 the pledge to an owner registrar, the cloud registrar will inform the 206 pledge what domain to use for accessing EST services in the voucher 207 response. 209 Finally, when bootstrapping against an owner registrar, this 210 registrar may interact with a backend CA to assist in issuing 211 certificates to the pledge. The mechanisms and protocols by which 212 the registrar interacts with the CA are transparent to the pledge and 213 are out-of-scope of this document. 215 The architecture shows the cloud registrar and MASA as being 216 logically separate entities. The two functions could of course be 217 integrated into a single service. 219 TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. 220 Cloud Registrar returns VOUCHER pinning Owner Register. 222 |<--------------OWNER------------------------>| MANUFACTURER 224 On-site Cloud 225 +--------+ +-----------+ 226 | Pledge |---------------------------------------->| Cloud | 227 +--------+ | Registrar | 228 | +---+ +----+ 229 | |??| 230 | +-----------+ +---+ +----+ 231 +---------------->| Owner |--------------->| MASA | 232 | VR-sign(N) | Registrar |sign(VR-sign(N))+-----------+ 233 | +-----------+ 234 | | +-----------+ 235 | +--->| CA | 236 | +-----------+ 237 | 238 | +-----------+ 239 +---------------->| Services | 240 +-----------+ 242 Figure 1: High Level Architecture 244 2.1. Interested Parties 246 1. OEM - Equipment manufacturer. Operate the MASA. 248 2. Network operator. Operate the Owner Registrar. Often operated 249 by end owner (company), or by outsourced IT entity. 251 3. Network integrator. They operate a Cloud Registrar. 253 2.2. Network Connectivity 255 The assumption is that the pledge already has network connectivity 256 prior to connecting to the cloud registrar. The pledge must have an 257 IP address, must be able to make DNS queries, and must be able to 258 send HTTP requests to the cloud registrar. The pledge operator has 259 already connected the pledge to the network, and the mechanism by 260 which this has happened is out of scope of this document. 262 2.3. Pledge Certificate Identity Considerations 264 BRSKI section 5.9.2 specifies that the pledge MUST send an EST 265 [RFC7030] CSR Attributes request to the registrar. The registrar MAY 266 use this mechanism to instruct the pledge about the identities it 267 should include in the CSR request it sends as part of enrollment. 268 The registrar may use this mechanism to tell the pledge what Subject 269 or Subject Alternative Name identity information to include in its 270 CSR request. This can be useful if the Subject must have a specific 271 value in order to complete enrollment with the CA. 273 EST [RFC7030] is not clear on how the CSR Attributes response should 274 be structured, and in particular is not clear on how a server can 275 instruct a client to include specific attribute values in its CSR. 276 [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can 277 use CSR Attributes response to specify specific values for attributes 278 that the client should include in its CSR. 280 For example, the pledge may only be aware of its IDevID Subject which 281 includes a manufacturer serial number, but must include a specific 282 fully qualified domain name in the CSR in order to complete domain 283 ownership proofs required by the CA. 285 As another example, the registrar may deem the manufacturer serial 286 number in an IDevID as personally identifiable information, and may 287 want to specify a new random opaque identifier that the pledge should 288 use in its CSR. 290 3. Protocol Operation 292 3.1. Pledge Requests Voucher from Cloud Registrar 294 3.1.1. Cloud Registrar Discovery 296 BRSKI defines how a pledge MAY contact a well-known URI of a cloud 297 registrar if a local domain registrar cannot be discovered. 298 Additionally, certain pledge types may never attempt to discover a 299 local domain registrar and may automatically bootstrap against a 300 cloud registrar. 302 The details of the URI are manufacturer specific, with BRSKI giving 303 the example "brski-registrar.manufacturer.example.com". 305 The Pledge SHOULD be provided with the entire URL of the Cloud 306 Registrar, including the path component, which is typically "/.well- 307 known/brski/requestvoucher", but may be another value. 309 3.1.2. Pledge - Cloud Registrar TLS Establishment Details 311 The pledge MUST use an Implicit Trust Anchor database (see [EST]) to 312 authenticate the cloud registrar service. The Pledge can be done 313 with pre-loaded trust-anchors that are used to validate the TLS 314 connection. This can be using a public Web PKI trust anchors using 315 [RFC6125] DNS-ID mechanisms, a pinned certification authority, or 316 even a pinned raw public key. This is a local implementation 317 decision. 319 The pledge MUST NOT establish a provisional TLS connection (see BRSKI 320 section 5.1) with the cloud registrar. 322 The cloud registrar MUST validate the identity of the pledge by 323 sending a TLS CertificateRequest message to the pledge during TLS 324 session establishment. The cloud registrar MAY include a 325 certificate_authorities field in the message to specify the set of 326 allowed IDevID issuing CAs that pledges may use when establishing 327 connections with the cloud registrar. 329 The cloud registrar MAY only allow connections from pledges that have 330 an IDevID that is signed by one of a specific set of CAs, e.g. 331 IDevIDs issued by certain manufacturers. 333 The cloud registrar MAY allow pledges to connect using self-signed 334 identity certificates or using Raw Public Key [RFC7250] certificates. 336 3.1.3. Pledge Issues Voucher Request 338 After the pledge has established a full TLS connection with the cloud 339 registrar and has verified the cloud registrar PKI identity, the 340 pledge generates a voucher request message as outlined in BRSKI 341 section 5.2, and sends the voucher request message to the cloud 342 registrar. 344 3.2. Cloud Registrar Handles Voucher Request 346 The cloud registrar must determine pledge ownership. Once ownership 347 is determined, or if no owner can be determined, then the registrar 348 may: 350 * return a suitable 4xx or 5xx error response to the pledge if the 351 registrar is unwilling or unable to handle the voucher request 353 * redirect the pledge to an owner register via 307 response code 355 * issue a voucher and return a 200 response code 357 3.2.1. Pledge Ownership Lookup 359 The cloud registrar needs some suitable mechanism for knowing the 360 correct owner of a connecting pledge based on the presented identity 361 certificate. For example, if the pledge establishes TLS using an 362 IDevID that is signed by a known manufacturing CA, the registrar 363 could extract the serial number from the IDevID and use this to 364 lookup a database of pledge IDevID serial numbers to owners. 366 Alternatively, if the cloud registrar allows pledges to connect using 367 self-signed certificates, the registrar could use the thumbprint of 368 the self-signed certificate to lookup a database of pledge self- 369 signed certificate thumbprints to owners. 371 The mechanism by which the cloud registrar determines pledge 372 ownership is out-of-scope of this document. 374 3.2.2. Cloud Registrar Redirects to Owner Registrar 376 Once the cloud registrar has determined pledge ownership, the cloud 377 registrar may redirect the pledge to the owner registrar in order to 378 complete bootstrap. Ownership registration will require the owner to 379 register their local domain. The mechanism by which pledge owners 380 register their domain with the cloud registrar is out-of-scope of 381 this document. 383 The cloud registrar replies to the voucher request with a suitable 384 HTTP 307 response code, including the owner's local domain in the 385 HTTP Location header. 387 3.2.3. Cloud Registrar Issues Voucher 389 If the cloud registrar issues a voucher, it returns the voucher in a 390 HTTP response with a 200 response code. 392 The cloud registrar MAY issue a 202 response code if it is willing to 393 issue a voucher, but will take some time to prepare the voucher. 395 The voucher MUST include the "est-domain" field as defined below. 396 This tells the pledge where the domain of the EST service to use for 397 completing certificate enrollment. 399 The voucher MAY include the "additional-configuration" field. This 400 points the pledge to a URI where application specific additional 401 configuration information may be retrieved. Pledge and Registrar 402 behavior for handling and specifying the "additional-configuration" 403 field is out-of-scope of this document. 405 3.3. Pledge Handles Cloud Registrar Response 407 3.3.1. Redirect Response 409 The cloud registrar returned a 307 response to the voucher request. 411 The pledge should restart the process using a new voucher request 412 using the location provided in the HTTP redirect. Note if the pledge 413 is able to validate the new server using a trust anchor found in its 414 Implicit Trust Anchor database, then it MAY accept another 307 415 redirect. The pledge MUST never visit a location that it has already 416 been to. If that happens then the pledge MUST fail the onboarding 417 attempt and go back to the beginning, which includes listening to 418 other sources of onboarding information as specified in [BRSKI] 419 section 4.1 and 5.0. 421 The pledge should establish a provisional TLS connection with 422 specified local domain registrar. The pledge should not use its 423 Implicit Trust Anchor database for validating the local domain 424 registrar identity. The pledge should send a voucher request message 425 via the local domain registrar. When the pledge downloads a voucher, 426 it can validate the TLS connection to the local domain registrar and 427 continue with enrollment and bootstrap as per standard BRSKI 428 operation. 430 3.3.2. Voucher Response 432 The cloud registrar returned a voucher to the pledge. The pledge 433 should perform voucher verification as per standard BRSKI operation. 434 The pledge should verify the voucher signature using the 435 manufacturer-installed trust anchor(s), should verify the serial 436 number in teh voucher, and must verify any nonce information in the 437 voucher. 439 The pledge should extract the "est-domain" field from the voucher, 440 and should continue with EST enrollment as per standard BRSKI 441 operation. 443 4. Protocol Details 445 4.1. Voucher Request Redirected to Local Domain Registrar 447 This flow illustrates the Owner Registrar Discovery flow. A pledge 448 is bootstrapping in a remote location with no local domain registrar. 449 The assumption is that the owner registrar domain is accessible and 450 the pledge can establish a network connection with the owner 451 registrar. This may require that the owner network firewall exposes 452 the registrar on the public internet. 454 +--------+ +----------+ 455 | Pledge | | Cloud RA | 456 | | | | 457 +--------+ +----------+ 458 | | 459 | 1. Mutual-authenticated TLS | 460 |<----------------------------------------------->| 461 | | 462 | 2. Voucher Request | 463 |------------------------------------------------>| 464 | | 465 | 3. 307 Location: owner-ra.example.com | 466 |<------------------------------------------------| 467 | 468 | +-----------+ +---------+ 469 | | Owner | | MASA | 470 | | Registrar | | | 471 | +-----------+ +---------+ 472 | 4. Provisional TLS | | 473 |<-------------------->| | 474 | | | 475 | 5. Voucher Request | | 476 |--------------------->| 6. Voucher Request | 477 | |------------------------->| 478 | | | 479 | | 7. Voucher Response | 480 | |<-------------------------| 481 | 8. Voucher Response | | 482 |<---------------------| | 483 | | | 484 | 9. Validate TLS | | 485 |<-------------------->| | 486 | | | 487 | 10. etc. | | 488 |--------------------->| | 490 The process starts, in step 1, when the Pledge establishes a Mutual 491 TLS channel with the Cloud RA using artifacts created during the 492 manufacturing process of the Pledge. 494 In step 2, the Pledge sends a voucher request to the Cloud RA. 496 The Cloud RA completes pledge ownership lookup as outlined in 497 Section 3.2.1, and determines the owner registrar domain. In step 3, 498 the Cloud RA redirects the pledge to the owner registrar domain. 500 Steps 4 and onwards follow the standard BRSKI flow. The pledge 501 establishes a provisional TLS connection with the owner registrar, 502 and sends a voucher request to the owner registrar. The registrar 503 forwards the voucher request to the MASA. Assuming the MASA issues a 504 voucher, then the pledge validates the TLS connection with the 505 registrar using the pinned-domain-cert from the voucher and completes 506 the BRSKI flow. 508 4.2. Voucher Request Handled by Cloud Registrar 510 The Voucher includes the EST domain to use for EST enroll. It is 511 assumed services are accessed at that domain too. As trust is 512 already established via the Voucher, the pledge does a full TLS 513 handshake against the local RA indicated by the voucher response. 515 The returned voucher contains an attribute, "est-domain", defined in 516 Section 5 below. The pledge is directed to continue enrollment using 517 the EST registrar found at that URI. The pledge uses the pinned- 518 domain-cert from the voucher to authenticate the EST registrar. 520 +--------+ +----------+ 521 | Pledge | | Cloud RA | 522 | | | / MASA | 523 +--------+ +----------+ 524 | | 525 | 1. Mutual TLS | 526 |<----------------------------------------------->| 527 | | 528 | 2. Voucher Request | 529 |------------------------------------------------>| 530 | | 531 | 3. Voucher Response {est-domain:fqdn} | 532 |<------------------------------------------------| 533 | | 534 | +----------+ | 535 | | RFC7030 | | 536 | | EST | | 537 | | Registrar| | 538 | +----------+ | 539 | | | 540 | 4. Full TLS | | 541 |<-------------------->| | 542 | | 543 | 3a. /voucher_status POST success | 544 |------------------------------------------------>| 545 | ON FAILURE 3b. /voucher_status POST | 546 | | 547 | 5. EST Enrol | | 548 |--------------------->| | 549 | | | 550 | 6. Certificate | | 551 |<---------------------| | 552 | | | 553 | 7. /enrollstatus | | 554 |--------------------->| | 556 The process starts, in step 1, when the Pledge establishes a Mutual 557 TLS channel with the Cloud RA/MASA using artifacts created during the 558 manufacturing process of the Pledge. In step 2, the Pledge sends a 559 voucher request to the Cloud RA/MASA, and in response the Pledge 560 receives an [RFC8366] format voucher from the Cloud RA/MASA that 561 includes its assigned EST domain in the est-domain attribute. 563 At this stage, the Pledge should be able to establish a TLS channel 564 with the EST Registrar. The connection may involve crossing the 565 Internet requiring a DNS lookup on the provided name. It may also be 566 a local address that includes an IP address literal including both 567 [RFC1918] and IPv6 Unique Local Address. The EST Registrar is 568 validated using the pinned-domain-cert value provided in the voucher 569 as described in [BRSKI] section 5.6.2. This involves treating the 570 artifact provided in the pinned-domain-cert as a trust anchor, and 571 attempting to validate the EST Registrar from this anchor only. 573 There is a case where the pinned-domain-cert is the identical End- 574 Entity (EE) Certificate as the EST Registrar. It also explicitly 575 includes the case where the EST Registrar has a self-signed EE 576 Certificate, but it may also be an EE certificate that is part of a 577 larger PKI. If the certificate is not a self-signed or EE 578 certificate, then the Pledge SHOULD apply [RFC6125] DNS-ID validation 579 on the certificate against the URL provided in the est-domain 580 attribute. If the est-domain was provided by with an IP address 581 literal, then it is unlikely that it can be validated, and in that 582 case, it is expected that either a self-signed certificate or an EE 583 certificate will be pinned. 585 The Pledge also has the details it needs to be able to create the CSR 586 request to send to the RA based on the details provided in the 587 voucher. 589 In step 4, the Pledge establishes a TLS channel with the Cloud RA/ 590 MASA, and optionally the pledge should send a request, steps 3.a and 591 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to 592 establish a secure TLS channel with the EST Registrar. 594 The Pledge then follows that, in step 5, with an EST Enroll request 595 with the CSR and obtains the requested certificate. The Pledge must 596 validate that the issued certificate has the expected identifier 597 obtained from the Cloud RA/MASA in step 3. 599 5. YANG extension for Voucher based redirect 601 An extension to the [RFC8366] voucher is needed for the case where 602 the client will be redirected to a local EST Registrar. 604 5.1. YANG Tree 605 module: ietf-voucher-redirected 607 grouping voucher-redirected-grouping 608 +-- voucher 609 +-- created-on yang:date-and-time 610 +-- expires-on? yang:date-and-time 611 +-- assertion enumeration 612 +-- serial-number string 613 +-- idevid-issuer? binary 614 +-- pinned-domain-cert binary 615 +-- domain-cert-revocation-checks? boolean 616 +-- nonce? binary 617 +-- last-renewal-date? yang:date-and-time 618 +-- est-domain? ietf:uri 619 +-- additional-configuration? ietf:uri 621 5.2. YANG Voucher 623 file "ietf-voucher-redirected@2020-09-23.yang" 624 module ietf-voucher-redirected { 625 yang-version 1.1; 627 namespace 628 "urn:ietf:params:xml:ns:yang:ietf-voucher-redirected"; 629 prefix "redirected"; 631 import ietf-restconf { 632 prefix rc; 633 description 634 "This import statement is only present to access 635 the yang-data extension defined in RFC 8040."; 636 reference "RFC 8040: RESTCONF Protocol"; 637 } 639 import ietf-inet-types { 640 prefix ietf; 641 reference "RFC 6991: Common YANG Data Types"; 642 } 644 import ietf-voucher { 645 prefix "v"; 646 } 648 organization 649 "IETF ANIMA Working Group"; 651 contact 652 "WG Web: 653 WG List: 654 Author: Michael Richardson 655 656 Author: Owen Friel 657 658 Author: Rifaat Shekh-Yusef 659 "; 660 description 661 "This module extendes the base RFC8366 voucher format to 662 include a redirect to an EST server to which enrollment 663 should continue. 665 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 666 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 667 and 'OPTIONAL' in the module text are to be interpreted as 668 described in BCP14, RFC 2119, and RFC8174."; 670 revision "2020-09-23" { 671 description 672 "Initial version"; 673 reference 674 "RFC XXXX: Voucher Profile for Cloud redirected Devices"; 675 } 677 rc:yang-data voucher-redirected-artifact { 678 // YANG data template for a voucher. 679 uses voucher-redirected-grouping; 680 } 682 // Grouping defined for future usage 683 grouping voucher-redirected-grouping { 684 description 685 "Grouping to allow reuse/extensions in future work."; 687 uses v:voucher-artifact-grouping { 689 augment "voucher" { 690 description "Base the constrained voucher 691 upon the regular one"; 692 leaf est-domain { 693 type ietf:uri; 694 description 695 "The est-domain is a URL to which the Pledge should 696 continue doing enrollment rather than with the 697 Cloud Registrar. 698 The pinned-domain-cert contains a trust-anchor 699 which is to be used to authenticate the server 700 found at this URI. 702 "; 703 } 704 leaf additional-configuration { 705 type ietf:uri; 706 description 707 "The additional-configuration attribute contains a 708 URL to which the Pledge can retrieve additional 709 configuration information. 710 The contents of this URL are vendor specific. 711 This is intended to do things like configure 712 a VoIP phone to point to the correct hosted 713 PBX, for example."; 714 } 715 } 716 } 717 } 718 } 719 721 6. IANA Considerations 723 6.1. The IETF XML Registry 725 This document registers one URI in the IETF XML registry [RFC3688]. 726 Following the format in [RFC3688], the following registration is 727 requested: 729 {: newline="true"} 730 URI: 731 : urn:ietf:params:xml:ns:yang:ietf-voucher-redirected 733 Registrant Contact: 734 : The ANIMA WG of the IETF. 736 XML: 737 : N/A, the requested URI is an XML namespace. 739 6.2. The YANG Module Names Registry 741 This document registers two YANG modules in the YANG Module Names 742 registry [RFC6020]. Following the format defined in [RFC6020], the 743 the following registration is requested: 745 {: newline="true"} 746 name: 747 : ietf-voucher-redirected 749 namespace: 750 : urn:ietf:params:xml:ns:yang:ietf-voucher-redirected 752 prefix: 753 : vch 755 reference: 756 : THIS DOCUMENT 758 7. Security Considerations 760 The Cloud-Registrar described in this document inherits all of the 761 issues that are described in [BRSKI]. This includes dependency upon 762 continued operation of the manufacturer provided MASA, as well as 763 potential complications where a manufacturer might interfere with 764 resale of a device. 766 In addition to the dependency upon the MASA, the successful 767 enrollment of a device using a Cloud Registrar depends upon the 768 correct and continued operation of this new service. This internet 769 accessible service may be operated by the manufacturer and/or by one 770 or more value-added-resellers. All of the considerations for 771 operation of the MASA also apply to operation of the Cloud Registrar. 773 7.1. Issues with Security of HTTP Redirect 775 If the Redirect to Registrar method is used, as described in 776 Section 4.1, there may be a series of 307 redirects. An example of 777 why this might occur is that the manufacturer only knows that it 778 resold the device to a particular value added reseller (VAR), and 779 there may be a chain of such VARs. It is important the pledge avoid 780 being drawn into a loop of redirects. This could happen if a VAR 781 does not think they are authoritative for a particular device. A 782 "helpful" programmer might instead decide to redirect back to the 783 manufacturer in an attempt to restart at the top: perhaps there is 784 another process that updates the manufacturer's database and this 785 process is underway. Instead, the VAR MUST return a 404 error if it 786 cannot process the device. This will force the device to stop, 787 timeout, and then try all mechanisms again. 789 There is another case where a connection problem may occur: when the 790 pledge is behind a captive portal or an intelligent home gateway that 791 provides access control on all connections. Captive portals that do 792 not follow the requirements of [RFC8952] section 1 may forcibly 793 redirect HTTPS connections. While this is a deprecated practice as 794 it breaks TLS in a way that most users can not deal with, it is still 795 common in many networks. 797 On the first connection, the incorrect connection will be discovered 798 because the Pledge will be unable to validate the connection to its 799 cloud registrar via DNS-ID. That is, the certificate returned from 800 the captive portal will not match. 802 At this point a network operator who controls the captive portal, 803 noticing the connection to what seems a legitimate destination (the 804 cloud registrar), may then permit that connection. This enables the 805 first connection to go through. 807 The connection is then redirected to the Registrar, either via 307, 808 or via est-domain in a voucher. If it is a 307 redirect, then a 809 provisional TLS connection will be initiated, and it will succeed. 810 The provisional TLS connection does not do [RFC6125] DNS-ID 811 validation at the beginning of the connection, so a forced 812 redirection to a captive portal system will not be detected. The 813 subsequent BRSKI POST of a voucher will most likely be met by a 404 814 or 500 HTTP code. As the connection is provisional, the pledge will 815 be unable to determine this. 817 It is RECOMMENDED therefore that the pledge look for [RFC8910] 818 attributes in DHCP, and if present, use the [RFC8908] API to learn if 819 it is captive. 821 7.2. Security Updates for the Pledge 823 Unlike many other uses of BRSKI, in the Cloud Registrar case it is 824 assumed that the Pledge has connected to a network on which there is 825 addressing and connectivity, but there is no other local 826 configuration available. 828 There is another advantage to being online: the pledge may be able to 829 contact the manufacturer before onboarding in order to apply the 830 latest firmware updates. This may also include updates to the 831 Implicit list of Trust Anchors. In this way, a Pledge that may have 832 been in a dusty box in a warehouse for a long time can be updated to 833 the latest (exploit-free) firmware before attempting onboarding. 835 7.3. Trust Anchors for Cloud Registrar 837 The Implicit TA database is used to authenticate the Cloud Registrar. 838 This list is built-in by the manufacturer along with a DNS name to 839 which to connect. (The manufacturer could even build in IP addresses 840 as a last resort) 841 The Cloud Registrar does not have a certificate that can be validated 842 using a public (WebPKI) anchor. The pledge may have any kind of 843 Trust Anchor built in: from full multi-level WebPKI to the single 844 self-signed certificate used by the Cloud Registrar. There are many 845 tradeoffs to having more or less of the PKI present in the Pledge, 846 which is addresses in part in 847 [I-D.richardson-t2trg-idevid-considerations] in sections 3 and 5. 849 7.4. Issues with Redirect via Voucher 851 The second redirect case is handled by returning a special extension 852 in the voucher. The Cloud Registrar actually does all of the voucher 853 processing as specified in [BRSKI]. In this case, the Cloud 854 Registrar may be operated by the same entity as the MASA, and it 855 might even be combined into a single server. Whether or not this is 856 the case, it behaves as if it was separate. 858 It may be the case that one or more 307-Redirects have taken the 859 Pledge from the built-in Cloud Registrar to one operated by a VAR. 861 When the Pledge is directed to the Owner's [EST] Registrar, the 862 Pledge validates the TLS connection with this server using the 863 "pinned-domain-cert" attribute in the voucher. There is no 864 provisional TLS connection, and therefore there are no risks 865 associated with being behind a captive portal. 867 8. References 869 8.1. Normative References 871 [BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 872 and K. Watsen, "Bootstrapping Remote Secure Key 873 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 874 May 2021, . 876 [EST] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 877 "Enrollment over Secure Transport", RFC 7030, 878 DOI 10.17487/RFC7030, October 2013, 879 . 881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 882 Requirement Levels", BCP 14, RFC 2119, 883 DOI 10.17487/RFC2119, March 1997, 884 . 886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 888 May 2017, . 890 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 891 "A Voucher Artifact for Bootstrapping Protocols", 892 RFC 8366, DOI 10.17487/RFC8366, May 2018, 893 . 895 8.2. Informative References 897 [I-D.richardson-lamps-rfc7030-csrattrs] 898 Richardson, M., Friel, O., Oheimb, D. D. V., and D. 899 Harkins, "Clarification of RFC7030 CSR Attributes 900 definition", Work in Progress, Internet-Draft, draft- 901 richardson-lamps-rfc7030-csrattrs-02, 7 March 2022, 902 . 905 [I-D.richardson-t2trg-idevid-considerations] 906 Richardson, M., "A Taxonomy of operational security 907 considerations for manufacturer installed keys and Trust 908 Anchors", Work in Progress, Internet-Draft, draft- 909 richardson-t2trg-idevid-considerations-06, 3 February 910 2022, . 913 [IEEE802.1AR] 914 IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 915 2018, . 918 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 919 J., and E. Lear, "Address Allocation for Private 920 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 921 February 1996, . 923 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 924 DOI 10.17487/RFC3688, January 2004, 925 . 927 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 928 the Network Configuration Protocol (NETCONF)", RFC 6020, 929 DOI 10.17487/RFC6020, October 2010, 930 . 932 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 933 Verification of Domain-Based Application Service Identity 934 within Internet Public Key Infrastructure Using X.509 935 (PKIX) Certificates in the Context of Transport Layer 936 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 937 2011, . 939 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 940 "Enrollment over Secure Transport", RFC 7030, 941 DOI 10.17487/RFC7030, October 2013, 942 . 944 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 945 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 946 Transport Layer Security (TLS) and Datagram Transport 947 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 948 June 2014, . 950 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 951 Touch Provisioning (SZTP)", RFC 8572, 952 DOI 10.17487/RFC8572, April 2019, 953 . 955 [RFC8908] Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API", 956 RFC 8908, DOI 10.17487/RFC8908, September 2020, 957 . 959 [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in 960 DHCP and Router Advertisements (RAs)", RFC 8910, 961 DOI 10.17487/RFC8910, September 2020, 962 . 964 [RFC8952] Larose, K., Dolson, D., and H. Liu, "Captive Portal 965 Architecture", RFC 8952, DOI 10.17487/RFC8952, November 966 2020, . 968 Authors' Addresses 970 Owen Friel 971 Cisco 972 Email: ofriel@cisco.com 974 Rifaat Shekh-Yusef 975 Auth0 976 Email: rifaat.s.ietf@gmail.com 978 Michael Richardson 979 Sandelman Software Works 980 Email: mcr+ietf@sandelman.ca