idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- 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 (17 October 2021) is 921 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 897, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-richardson-t2trg-idevid-considerations-05 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 3 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: 20 April 2022 Auth0 6 M. Richardson 7 Sandelman Software Works 8 17 October 2021 10 BRSKI Cloud Registrar 11 draft-ietf-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 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 20 April 2022. 39 Copyright Notice 41 Copyright (c) 2021 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 Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified 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 registrer 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 organizations domain, but does not discover 190 a local domain, or owner, registrar. The pledge uses the cloud 191 registrar to bootstrap, and the cloud registrar provides a voucher 192 that includes instructions on finding the organization's EST service. 194 2. Architecture 196 The high level architecture is illustrated in Figure 1. 198 The pledge connects to the cloud registrar during bootstrap. 200 The cloud registrar may redirect the pledge to an owner registrar in 201 order to complete bootstrap against the owner registrar. 203 If the cloud registrar issues a voucher itself without redirecting 204 the pledge to an owner registrar, the cloud registrar will inform the 205 pledge what domain to use for accessing EST services in the voucher 206 response. 208 Finally, when bootstrapping against an owner registrar, this 209 registrar may interact with a backend CA to assist in issuing 210 certificates to the pledge. The mechanisms and protocols by which 211 the registrar interacts with the CA are transparent to the pledge and 212 are out-of-scope of this document. 214 The architecture shows the cloud registrar and MASA as being 215 logically separate entities. The two functions could of course be 216 integrated into a single service. 218 TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. 219 Cloud Registrar returns VOUCHER pinning Owner Register. 221 |<--------------OWNER------------------------>| MANUFACTURER 223 On-site Cloud 224 +--------+ +-----------+ 225 | Pledge |---------------------------------------->| Cloud | 226 +--------+ | Registrar | 227 | +---+ +----+ 228 | |??| 229 | +-----------+ +---+ +----+ 230 +---------------->| Owner |--------------->| MASA | 231 | VR-sign(N) | Registrar |sign(VR-sign(N))+-----------+ 232 | +-----------+ 233 | | +-----------+ 234 | +--->| CA | 235 | +-----------+ 236 | 237 | +-----------+ 238 +---------------->| Services | 239 +-----------+ 241 Figure 1: High Level Architecture 243 2.1. Interested Parties 245 1. OEM - Equipment manufacturer. Operate the MASA. 247 2. Network operator. Operate the Owner Registrar. Often operated 248 by end owner (company), or by outsourced IT entity. 250 3. Network integrator. They operate a Cloud Registrar. 252 2.2. Network Connectivity 254 The assumption is that the pledge already has network connectivity 255 prior to connecting to the cloud registrar. The pledge must have an 256 IP address, must be able to make DNS queries, and must be able to 257 send HTTP requests to the cloud registrar. The pledge operator has 258 already connected the pledge to the network, and the mechanism by 259 which this has happened is out of scope of this document. 261 2.3. Pledge Certificate Identity Considerations 263 BRSKI section 5.9.2 specifies that the pledge MUST send a CSR 264 Attributes request to the registrar. The registrar MAY use this 265 mechanism to instruct the pledge about the identities it should 266 include in the CSR request it sends as part of enrollment. The 267 registrar may use this mechanism to tell the pledge what Subject or 268 Subject Alternative Name identity information to include in its CSR 269 request. This can be useful if the Subject must have a specific 270 value in order to complete enrollment with the CA. 272 For example, the pledge may only be aware of its IDevID Subject which 273 includes a manufacturer serial number, but must include a specific 274 fully qualified domain name in the CSR in order to complete domain 275 ownership proofs required by the CA. 277 As another example, the registrar may deem the manufacturer serial 278 number in an IDevID as personally identifiable information, and may 279 want to specify a new random opaque identifier that the pledge should 280 use in its CSR. 282 3. Protocol Operation 284 3.1. Pledge Requests Voucher from Cloud Registrar 286 3.1.1. Cloud Registrar Discovery 288 BRSKI defines how a pledge MAY contact a well known URI of a cloud 289 registrar if a local domain registrar cannot be discovered. 290 Additionally, certain pledge types may never attempt to discover a 291 local domain registrar and may automatically bootstrap against a 292 cloud registrar. 294 The details of the URI are manufacturer specific, with BRSKI giving 295 the example "brski-registrar.manufacturer.example.com". 297 The Pledge SHOULD be provided with the entire URL of the Cloud 298 Registrar, including the path component, which is typically "/.well- 299 known/brski/requestvoucher", but may be another value. 301 3.1.2. Pledge - Cloud Registrar TLS Establishment Details 303 The pledge MUST use an Implicit Trust Anchor database (see [EST]) to 304 authenticate the cloud registrar service. The Pledge can be done 305 with pre-loaded trust-anchors that are used to validate the TLS 306 connection. This can be using a public Web PKI trust anchors using 307 [RFC6125] DNS-ID mechanisms, a pinned certification authority, or 308 even a pinned raw public key. This is a local implementation 309 decision. 311 The pledge MUST NOT establish a provisional TLS connection (see BRSKI 312 section 5.1) with the cloud registrar. 314 The cloud registrar MUST validate the identity of the pledge by 315 sending a TLS CertificateRequest message to the pledge during TLS 316 session establishment. The cloud registrar MAY include a 317 certificate_authorities field in the message to specify the set of 318 allowed IDevID issuing CAs that pledges may use when establishing 319 connections with the cloud registrar. 321 The cloud registrar MAY only allow connections from pledges that have 322 an IDevID that is signed by one of a specific set of CAs, e.g. 323 IDevIDs issued by certain manufacturers. 325 The cloud registrar MAY allow pledges to connect using self-signed 326 identity certificates or using Raw Public Key [RFC7250] certificates. 328 3.1.3. Pledge Issues Voucher Request 330 After the pledge has established a full TLS connection with the cloud 331 registrar and has verified the cloud registrar PKI identity, the 332 pledge generates a voucher request message as outlined in BRSKI 333 section 5.2, and sends the voucher request message to the cloud 334 registrar. 336 3.2. Cloud Registrar Handles Voucher Request 338 The cloud registrar must determine pledge ownership. Once ownership 339 is determined, or if no owner can be determined, then the registrar 340 may: 342 * return a suitable 4xx or 5xx error response to the pledge if the 343 registrar is unwilling or unable to handle the voucher request 345 * redirect the pledge to an owner register via 307 response code 347 * issue a voucher and return a 200 response code 349 3.2.1. Pledge Ownership Lookup 351 The cloud registrar needs some suitable mechanism for knowing the 352 correct owner of a connecting pledge based on the presented identity 353 certificate. For example, if the pledge establishes TLS using an 354 IDevID that is signed by a known manufacturing CA, the registrar 355 could extract the serial number from the IDevID and use this to 356 lookup a database of pledge IDevID serial numbers to owners. 358 Alternatively, if the cloud registrar allows pledges to connect using 359 self-signed certificates, the registrar could use the thumbprint of 360 the self-signed certificate to lookup a database of pledge self- 361 signed certificate thumbprints to owners. 363 The mechanism by which the cloud registrar determines pledge 364 ownership is out-of-scope of this document. 366 3.2.2. Cloud Registrar Redirects to Owner Registrar 368 Once the cloud registar has determined pledge ownership, the cloud 369 registrar may redirect the pledge to the owner registrar in order to 370 complete bootstrap. Ownership registration will require the owner to 371 register their local domain. The mechanism by which pledge owners 372 register their domain with the cloud registrar is out-of-scope of 373 this document. 375 The cloud registrar replies to the voucher request with a suitable 376 HTTP 307 response code, including the owner's local domain in the 377 HTTP Location header. 379 3.2.3. Cloud Registrar Issues Voucher 381 If the cloud registrar issues a voucher, it returns the voucher in a 382 HTTP response with a 200 response code. 384 The cloud registrar MAY issue a 202 response code if it is willing to 385 issue a voucher, but will take some time to prepare the voucher. 387 The voucher MUST include the "est-domain" field as defined below. 388 This tells the pledge where the domain of the EST service to use for 389 completing certificate enrollment. 391 The voucher MAY include the "additional-configuration" field.. This 392 points the pledge to a URI where application specific additional 393 configuration information may be retrieved. Pledge and Registrar 394 behavior for handling and specifying the "additional-configuration" 395 field is out-of-scope of this document. 397 3.3. Pledge Handles Cloud Registrar Response 399 3.3.1. Redirect Response 401 The cloud registrar returned a 307 response to the voucher request. 403 The pledge should restart the process using a new voucher request 404 using the location provided in the HTTP redirect. Note if the pledge 405 is able to validate the new server using a trust anchor found in its 406 Implicit Trust Anchor database, then it MAY accept another 307 407 redirect. The pledge MUST never visit a location that it has already 408 been to. If that happens then the pledge MUST fail the onboarding 409 attempt and go back to the beginning, which includes listening to 410 other sources of onboarding information as specified in [BRSKI] 411 section 4.1 and 5.0. 413 The pledge should establish a provisional TLS connection with 414 specified local domain registrar. The pledge should not use its 415 Implicit Trust Anchor database for validating the local domain 416 registrar identity. The pledge should send a voucher request message 417 via the local domain registrar. When the pledge downloads a voucher, 418 it can validate the TLS connection to the local domain registrar and 419 continue with enrollment and bootstrap as per standard BRSKI 420 operation. 422 3.3.2. Voucher Response 424 The cloud registrar returned a voucher to the pledge. The pledge 425 should perform voucher verification as per standard BRSKI operation. 426 The pledge should verify the voucher signature using the 427 manufacturer-installed trust anchor(s), should verify the serial 428 number in teh voucher, and must verify any nonce information in the 429 voucher. 431 The pledge should extract the "est-domain" field from the voucher, 432 and should continue with EST enrollment as per standard BRSKI 433 operation. 435 4. Protocol Details 437 4.1. Voucher Request Redirected to Local Domain Registrar 439 This flow illlustrates the Owner Registrar Discovery flow. A pledge 440 is bootstrapping in a remote location with no local domain registrar. 441 The assumption is that the owner registrar domain is accessible and 442 the pledge can establish a network connection with the owner 443 registrar. This may require that the owner network firewall exposes 444 the registrar on the public internet. 446 +--------+ +----------+ 447 | Pledge | | Cloud RA | 448 | | | | 449 +--------+ +----------+ 450 | | 451 | 1. Mutual-authenticated TLS | 452 |<----------------------------------------------->| 453 | | 454 | 2. Voucher Request | 455 |------------------------------------------------>| 456 | | 457 | 3. 307 Location: owner-ra.example.com | 458 |<------------------------------------------------| 459 | 460 | +-----------+ +---------+ 461 | | Owner | | MASA | 462 | | Registrar | | | 463 | +-----------+ +---------+ 464 | 4. Provisional TLS | | 465 |<-------------------->| | 466 | | | 467 | 5. Voucher Request | | 468 |--------------------->| 6. Voucher Request | 469 | |------------------------->| 470 | | | 471 | | 7. Voucher Response | 472 | |<-------------------------| 473 | 8. Voucher Response | | 474 |<---------------------| | 475 | | | 476 | 9. Validate TLS | | 477 |<-------------------->| | 478 | | | 479 | 10. etc. | | 480 |--------------------->| | 482 The process starts, in step 1, when the Pledge establishes a Mutual 483 TLS channel with the Cloud RA using artifacts created during the 484 manufacturing process of the Pledge. 486 In step 2, the Pledge sends a voucher request to the Cloud RA. 488 The Cloud RA completes pledge ownership lookup as outlined in 489 Section 3.2.1, and determines the owner registrar domain. In step 3, 490 the Cloud RA redirects the pledge to the owner registrar domain. 492 Steps 4 and onwards follow the standard BRSKI flow. The pledge 493 establishes a provisional TLS connection with the owner registrar, 494 and sends a voucher request to the owner registrar. The registar 495 forwards the voucher request to the MASA. Assuming the MASA issues a 496 voucher, then the pledge validates the TLS connection with the 497 registrar using the pinned-domain-cert from the voucher and completes 498 the BRSKI flow. 500 4.2. Voucher Request Handled by Cloud Registrar 502 The Voucher includes the EST domain to use for EST enroll. It is 503 assumed services are accessed at that domain too. As trust is 504 already established via the Voucher, the pledge does a full TLS 505 handshake against the local RA indicated by the voucher response. 507 The returned voucher contains an attribute, "est-domain", defined in 508 Section 5 below. The pledge is directed to continue enrollment using 509 the EST registrar found at that URI. The pledge uses the pinned- 510 domain-cert from the voucher to authenticate the EST registrar. 512 +--------+ +----------+ 513 | Pledge | | Cloud RA | 514 | | | / MASA | 515 +--------+ +----------+ 516 | | 517 | 1. Mutual TLS | 518 |<----------------------------------------------->| 519 | | 520 | 2. Voucher Request | 521 |------------------------------------------------>| 522 | | 523 | 3. Voucher Response {est-domain:fqdn} | 524 |<------------------------------------------------| 525 | | 526 | +----------+ | 527 | | RFC7030 | | 528 | | EST | | 529 | | Registrar| | 530 | +----------+ | 531 | | | 532 | 4. Full TLS | | 533 |<-------------------->| | 534 | | 535 | 3a. /voucher_status POST success | 536 |------------------------------------------------>| 537 | ON FAILURE 3b. /voucher_status POST | 538 | | 539 | 5. EST Enrol | | 540 |--------------------->| | 541 | | | 542 | 6. Certificate | | 543 |<---------------------| | 544 | | | 545 | 7. /enrollstatus | | 546 |--------------------->| | 548 The process starts, in step 1, when the Pledge establishes a Mutual 549 TLS channel with the Cloud RA/MASA using artifacts created during the 550 manufacturing process of the Pledge. In step 2, the Pledge sends a 551 voucher request to the Cloud RA/MASA, and in response the Pledge 552 receives an [RFC8366] format voucher from the Cloud RA/MASA that 553 includes its assigned EST domain in the est-domain attribute. 555 At this stage, the Pledge should be able to establish a TLS channel 556 with the EST Registrar. The connection may involve crossing the 557 Internet requiring a DNS lookup on the provided name. It may also be 558 a local address that includes an IP address literal including both 559 [RFC1918] and IPv6 Unique Local Address. The EST Registrar is 560 validated using the pinned-domain-cert value provided in the voucher 561 as described in [BRSKI] section 5.6.2. This involves treating the 562 artifact provided in the pinned-domain-cert as a trust anchor, and 563 attempting to validate the EST Registrar from this anchor only. 565 There is a case where the pinned-domain-cert is the identical End- 566 Entity (EE) Certificate as the EST Registrar. It also explicitly 567 includes the case where the EST Registrar has a self-signed EE 568 Certificate, but it may also be an EE certificate that is part of a 569 larger PKI. If the certificate is not a self-signed or EE 570 certificate, then the Pledge SHOULD apply [RFC6125] DNS-ID validation 571 on the certificate against the URL provided in the est-domain 572 attribute. If the est-domain was provided by with an IP address 573 literal, then it is unlikely that it can be validated, and in that 574 case, it is expected that either a self-signed certificate or an EE 575 certificate will be pinned. 577 The Pledge also has the details it needs to be able to create the CSR 578 request to send to the RA based on the details provided in the 579 voucher. 581 In step 4, the Pledge establishes a TLS channel with the Cloud RA/ 582 MASA, and optionally the pledge should send a request, steps 3.a and 583 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to 584 establish a secure TLS channel with the EST Registrar. 586 The Pledge then follows that, in step 5, with an EST Enroll request 587 with the CSR and obtains the requested certificate. The Pledge must 588 validate that the issued certificate has the expected identifier 589 obtained from the Cloud RA/MASA in step 3. 591 5. YANG extension for Voucher based redirect 593 An extension to the [RFC8366] voucher is needed for the case where 594 the client will be redirected to a local EST Registrar. 596 5.1. YANG Tree 597 module: ietf-voucher-redirected 599 grouping voucher-redirected-grouping 600 +-- voucher 601 +-- created-on yang:date-and-time 602 +-- expires-on? yang:date-and-time 603 +-- assertion enumeration 604 +-- serial-number string 605 +-- idevid-issuer? binary 606 +-- pinned-domain-cert binary 607 +-- domain-cert-revocation-checks? boolean 608 +-- nonce? binary 609 +-- last-renewal-date? yang:date-and-time 610 +-- est-domain? ietf:uri 611 +-- additional-configuration? ietf:uri 613 5.2. YANG Voucher 615 file "ietf-voucher-redirected@2020-09-23.yang" 616 module ietf-voucher-redirected { 617 yang-version 1.1; 619 namespace 620 "urn:ietf:params:xml:ns:yang:ietf-voucher-redirected"; 621 prefix "redirected"; 623 import ietf-restconf { 624 prefix rc; 625 description 626 "This import statement is only present to access 627 the yang-data extension defined in RFC 8040."; 628 reference "RFC 8040: RESTCONF Protocol"; 629 } 631 import ietf-inet-types { 632 prefix ietf; 633 reference "RFC 6991: Common YANG Data Types"; 634 } 636 import ietf-voucher { 637 prefix "v"; 638 } 640 organization 641 "IETF ANIMA Working Group"; 643 contact 644 "WG Web: 645 WG List: 646 Author: Michael Richardson 647 648 Author: Owen Friel 649 650 Author: Rifaat Shekh-Yusef 651 "; 652 description 653 "This module extendes the base RFC8366 voucher format to 654 include a redirect to an EST server to which enrollment 655 should continue. 657 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 658 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 659 and 'OPTIONAL' in the module text are to be interpreted as 660 described in BCP14, RFC 2119, and RFC8174."; 662 revision "2020-09-23" { 663 description 664 "Initial version"; 665 reference 666 "RFC XXXX: Voucher Profile for Cloud redirected Devices"; 667 } 669 rc:yang-data voucher-redirected-artifact { 670 // YANG data template for a voucher. 671 uses voucher-redirected-grouping; 672 } 674 // Grouping defined for future usage 675 grouping voucher-redirected-grouping { 676 description 677 "Grouping to allow reuse/extensions in future work."; 679 uses v:voucher-artifact-grouping { 681 augment "voucher" { 682 description "Base the constrained voucher 683 upon the regular one"; 684 leaf est-domain { 685 type ietf:uri; 686 description 687 "The est-domain is a URL to which the Pledge should 688 continue doing enrollment rather than with the 689 Cloud Registrar. 690 The pinned-domain-cert contains a trust-anchor 691 which is to be used to authenticate the server 692 found at this URI. 694 "; 695 } 696 leaf additional-configuration { 697 type ietf:uri; 698 description 699 "The additional-configuration attribute contains a 700 URL to which the Pledge can retrieve additional 701 configuration information. 702 The contents of this URL are vendor specific. 703 This is intended to do things like configure 704 a VoIP phone to point to the correct hosted 705 PBX, for example."; 706 } 707 } 708 } 709 } 710 } 711 713 6. IANA Considerations 715 6.1. The IETF XML Registry 717 This document registers one URI in the IETF XML registry [RFC3688]. 718 Following the format in [RFC3688], the following registration is 719 requested: 721 {: newline="true"} 722 URI: 723 : urn:ietf:params:xml:ns:yang:ietf-voucher-redirected 725 Registrant Contact: 726 : The ANIMA WG of the IETF. 728 XML: 729 : N/A, the requested URI is an XML namespace. 731 6.2. The YANG Module Names Registry 733 This document registers two YANG modules in the YANG Module Names 734 registry [RFC6020]. Following the format defined in [RFC6020], the 735 the following registration is requested: 737 {: newline="true"} 738 name: 739 : ietf-voucher-redirected 741 namespace: 742 : urn:ietf:params:xml:ns:yang:ietf-voucher-redirected 744 prefix: 745 : vch 747 reference: 748 : THIS DOCUMENT 750 7. Security Considerations 752 The Cloud-Registrar described in this document inherits all of the 753 issues that are described in [BRSKI]. This includes dependency upon 754 continued operation of the manufacturer provided MASA, as well as 755 potential complications where a manufacturer might interfere with 756 resale of a device. 758 In addition to the dependency upon the MASA, the successful 759 enrollment of a device using a Cloud Registrar depends upon the 760 correct and continued operation of this new service. This internet 761 accessible service may be operated by the manufacturer and/or by one 762 or more value-added-resellers. All of the considerations for 763 operation of the MASA also apply to operation of the Cloud Registrar. 765 7.1. Issues with Security of HTTP Redirect 767 If the Redirect to Registrar method is used, as described in 768 Section 4.1, there may be a series of 307 redirects. An example of 769 why this might occur is that the manufacturer only knows that it 770 resold the device to a particular value added reseller (VAR), and 771 there may be a chain of such VARs. It is important the pledge avoid 772 being drawn into a loop of redirects. This could happen if a VAR 773 does not think they are authoritative for a particular device. A 774 "helpful" programmer might instead decide to redirect back to the 775 manufacturer in an attempt to restart at the top: perhaps there is 776 another process that updates the manufacturer's database and this 777 process is underway. Instead, the VAR MUST return a 404 error if it 778 can not process the device. This will force the device to stop, 779 timeout, and then try all mechanisms again. 781 There is another case where a connection problem may occur: when the 782 pledge is behind a captive portal or an intelligent home gateway that 783 provides access control on all connections. Captive portals that do 784 not follow the requirements of [RFC8952] section 1 may forcibly 785 redirect HTTPS connections. While this is a deprecated practice as 786 it breaks TLS in a way that most users can not deal with, it is still 787 common in many networks. 789 On the first connection, the incorrect connection will be discovered 790 because the Pledge will be unable to validate the connection to it's 791 cloud registrar via DNS-ID. That is, the certificate returned from 792 the captive portal will not match. 794 At this point a network operator who controls the captive portal, 795 noticing the connection to what seems a legitimate destination (the 796 cloud registrar), may then permit that connection. This enables the 797 first connection to go through. 799 The connection is then redirected to the Registrar, either via 307, 800 or via est-domain in a voucher. If it is a 307 redirect, then a 801 provisional TLS connection will be initiated, and it will succeed. 802 The provisional TLS connection does not do [RFC6125] DNS-ID 803 validation at the beginning of the connection, so a forced 804 redirection to a captive portal system will not be detected. The 805 subsequent BRSKI POST of a voucher will most likely be met by a 404 806 or 500 HTTP code. As the connection is provisional, the pledge will 807 be unable to determine this. 809 It is RECOMMENDED therefore that the pledge look for [RFC8910] 810 attributes in DHCP, and if present, use the [RFC8908] API to learn if 811 it is captive. 813 7.2. Security Updates for the Pledge 815 Unlike many other uses of BRSKI, in the Cloud Registrar case it is 816 assumed that the Pledge has connected to a network on which there is 817 addressing and connectivity, but there is no other local 818 configuration available. 820 There is another advantage to being online: the pledge may be able to 821 contact the manufacturer before onboarding in order to apply the 822 latest firmware updates. This may also include updates to the 823 Implicit list of Trust Anchors. In this way, a Pledge that may have 824 been in a dusty box in a warehouse for a long time can be updated to 825 the latest (exploit-free) firmware before attempting onboarding. 827 7.3. Trust Anchors for Cloud Registrar 829 The Implicit TA database is used to authenticate the Cloud Registrar. 830 This list is built-in by the manufacturer along with a DNS name to 831 which to connect. (The manufacturer could even build in IP addresses 832 as a last resort) 833 The Cloud Registrar does not have have a certificate that can be 834 validated using a public (WebPKI) anchor. The pledge may have any 835 kind of Trust Anchor built in: from full multi-level WebPKI to the 836 single self-signed certificate used by the Cloud Registrar. There 837 are many tradeoffs to having more or less of the PKI present in the 838 Pledge, which is addresses in part in 839 [I-D.richardson-t2trg-idevid-considerations] in sections 3 and 5. 841 7.4. Issues with Redirect via Voucher 843 The second redirect case is handled by returning a special extension 844 in the voucher. The Cloud Registrar actually does all of the voucher 845 processing as specified in [BRSKI]. In this case, the Cloud 846 Registrar may be operated by the same entity as the MASA, and it 847 might even be combined into a single server. Whether or not this is 848 the case, it behaves as if it was separate. 850 It may be the case that one or more 307-Redirects have taken the 851 Pledge from the built-in Cloud Registrar to one operated by a VAR. 853 When the Pledge is directed to the Owner's [EST] Registrar, the 854 Pledge validates the TLS connection with this server using the 855 "pinned-domain-cert" attribute in the voucher. There is no 856 provisional TLS connection, and therefore there are no risks 857 associated with being behind a captive portal. 859 8. References 861 8.1. Normative References 863 [BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 864 and K. Watsen, "Bootstrapping Remote Secure Key 865 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 866 May 2021, . 868 [EST] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 869 "Enrollment over Secure Transport", RFC 7030, 870 DOI 10.17487/RFC7030, October 2013, 871 . 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, 875 DOI 10.17487/RFC2119, March 1997, 876 . 878 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 879 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 880 May 2017, . 882 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 883 "A Voucher Artifact for Bootstrapping Protocols", 884 RFC 8366, DOI 10.17487/RFC8366, May 2018, 885 . 887 8.2. Informative References 889 [I-D.richardson-t2trg-idevid-considerations] 890 Richardson, M., "A Taxonomy of operational security 891 considerations for manufacturer installed keys and Trust 892 Anchors", Work in Progress, Internet-Draft, draft- 893 richardson-t2trg-idevid-considerations-05, 21 June 2021, 894 . 897 [IEEE802.1AR] 898 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 899 2018, . 902 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 903 J., and E. Lear, "Address Allocation for Private 904 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 905 February 1996, . 907 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 908 DOI 10.17487/RFC3688, January 2004, 909 . 911 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 912 the Network Configuration Protocol (NETCONF)", RFC 6020, 913 DOI 10.17487/RFC6020, October 2010, 914 . 916 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 917 Verification of Domain-Based Application Service Identity 918 within Internet Public Key Infrastructure Using X.509 919 (PKIX) Certificates in the Context of Transport Layer 920 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 921 2011, . 923 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 924 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 925 Transport Layer Security (TLS) and Datagram Transport 926 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 927 June 2014, . 929 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 930 Touch Provisioning (SZTP)", RFC 8572, 931 DOI 10.17487/RFC8572, April 2019, 932 . 934 [RFC8908] Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API", 935 RFC 8908, DOI 10.17487/RFC8908, September 2020, 936 . 938 [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in 939 DHCP and Router Advertisements (RAs)", RFC 8910, 940 DOI 10.17487/RFC8910, September 2020, 941 . 943 [RFC8952] Larose, K., Dolson, D., and H. Liu, "Captive Portal 944 Architecture", RFC 8952, DOI 10.17487/RFC8952, November 945 2020, . 947 Authors' Addresses 949 Owen Friel 950 Cisco 952 Email: ofriel@cisco.com 954 Rifaat Shekh-Yusef 955 Auth0 957 Email: rifaat.s.ietf@gmail.com 959 Michael Richardson 960 Sandelman Software Works 962 Email: mcr+ietf@sandelman.ca