idnits 2.17.1 draft-ietf-anima-brski-cloud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 55 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 April 2021) is 1087 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 728, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 2 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: 30 October 2021 Auth0 6 M. Richardson 7 Sandelman Software Works 8 28 April 2021 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-00 13 Abstract 15 This document specifies the behaviour of a BRSKI Cloud Registrar, and 16 how a pledge can interact with a BRSKI Cloud Registrar when 17 bootstrapping. 19 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 30 October 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Interested Parties . . . . . . . . . . . . . . . . . . . 5 62 2.2. Network Connectivity . . . . . . . . . . . . . . . . . . 6 63 2.3. Pledge Certificate Identity Considerations . . . . . . . 6 64 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Pledge Requests Voucher from Cloud Registrar . . . . . . 6 66 3.1.1. Cloud Registrar Discovery . . . . . . . . . . . . . . 6 67 3.1.2. Pledge - Cloud Registrar TLS Establishment Details . 7 68 3.1.3. Pledge Issues Voucher Request . . . . . . . . . . . . 7 69 3.2. Cloud Registrar Handles Voucher Request . . . . . . . . . 7 70 3.2.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . 8 71 3.2.2. Cloud Registrar Redirects to Owner Registrar . . . . 8 72 3.2.3. Cloud Registrar Issues Voucher . . . . . . . . . . . 8 73 3.3. Pledge Handles Cloud Registrar Response . . . . . . . . . 9 74 3.3.1. Redirect Response . . . . . . . . . . . . . . . . . . 9 75 3.3.2. Voucher Response . . . . . . . . . . . . . . . . . . 9 76 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 77 4.1. Voucher Request Redirected to Local Domain Registrar . . 9 78 4.2. Voucher Request Handled by Cloud Registrar . . . . . . . 11 79 5. YANG extension for Voucher based redirect . . . . . . . . . . 13 80 5.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.2. YANG Voucher . . . . . . . . . . . . . . . . . . . . . . 14 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 8.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 92 [I-D.ietf-anima-bootstrapping-keyinfra] specifies automated 93 bootstrapping of an Autonomic Control Plane. BRSKI Section 2.7 94 describes how a pledge "MAY contact a well known URI of a cloud 95 registrar if a local registrar cannot be discovered or if the 96 pledge's target use cases do not include a local registrar". 98 This document further specifies use of a BRSKI cloud registrar and 99 clarifies operations that are not sufficiently specified in BRSKI. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 This document uses the terms Pledge, Registrar, MASA, and Voucher 110 from [I-D.ietf-anima-bootstrapping-keyinfra] and [RFC8366]. 112 * Local Domain: The domain where the pledge is physically located 113 and bootstrapping from. This may be different to the pledge 114 owner's domain. 116 * Owner Domain: The domain that the pledge needs to discover and 117 bootstrap with. 119 * Cloud Registrar: The default Registrar that is deployed at a URI 120 that is well known to the pledge. 122 * Owner Registrar: The Registrar that is operated by the Owner, or 123 the Owner's delegate. There may not be an Owner Registrar in all 124 deployment scenarios. 126 * Local Domain Registrar: The Registrar discovered on the Local 127 Domain. There may not be a Local Domain Registrar in all 128 deployment scenarios. 130 1.2. Target Use Cases 132 Two high level use cases are documented here. There are more details 133 provided in sections Section 4.1 and Section 4.2. While both use 134 cases aid with incremental deployment of BRSKI infrastructure, for 135 many smaller sites (such as teleworkers) no further infrastructure 136 are expected. 138 The pledge is not expected to know which of these two situations it 139 is in. The pledge determines this based upon signals that it 140 receives from the Cloud Registrar. The Cloud Registrar is expected 141 to make the determination based upon the identity presented by the 142 pledge. 144 While a Cloud Registrar will typically handle all the devices of a 145 particular product line from a particular manufacturer there are no 146 restrictions on how the Cloud Registrar is horizontally (many sites) 147 or vertically (more equipment at one site) scaled. It is also 148 entirely possible that all devices sold by through a particular VAR 149 might be preloaded with a configuration that changes the Cloud 150 Registrar URL to point to a VAR. Such an effort would require 151 unboxing each device in a controlled environment, but the 152 provisioning could occur using a regular BRSKI or SZTP [RFC8572] 153 process. 155 1.2.1. Owner Registrar Discovery 157 A pledge is bootstrapping from a remote location with no local domain 158 registrar (specifically: with no local infrastructure to provide for 159 automated discovery), and needs to discover its owner registrar. The 160 cloud registrar is used by the pledge to discover the owner 161 registrar. The cloud registrar redirects the pledge to the owner 162 registrar, and the pledge completes bootstrap against the owner 163 registrar. 165 A typical example is an enduser deploying a pledge in a home or small 166 branch office, where the pledge belongs to the enduser's employer. 167 There is no local domain registrar, and the pledge needs to discover 168 and bootstrap with the employer's registrar which is deployed in 169 headquarters. 171 1.2.2. Bootstrapping with no Owner Registrar 173 A pledge is bootstrapping where the owner organization does not yet 174 have an owner registrar deployed. The cloud registrer issues a 175 voucher, and the pledge completes trust bootstrap using the cloud 176 registrar. The voucher issued by the cloud includes domain 177 information for the owner's EST [RFC7030] service the pledge should 178 use for certificate enrollment. 180 In one use case, an organization has an EST service deployed, but 181 does not have yet a BRSKI capable Registrar service deployed. The 182 pledge is deployed in the organizations domain, but does not discover 183 a local domain, or owner, registrar. The pledge uses the cloud 184 registrar to bootstrap, and the cloud registrar provides a voucher 185 that includes instructions on finding the organization's EST service. 187 2. Architecture 189 The high level architecture is illustrated in Figure 1. 191 The pledge connects to the cloud registrar during bootstrap. 193 The cloud registrar may redirect the pledge to an owner registrar in 194 order to complete bootstrap against the owner registrar. 196 If the cloud registrar issues a voucher itself without redirecting 197 the pledge to an owner registrar, the cloud registrar will inform the 198 pledge what domain to use for accessing EST services in the voucher 199 response. 201 Finally, when bootstrapping against an owner registrar, this 202 registrar may interact with a backend CA to assist in issuing 203 certificates to the pledge. The mechanisms and protocols by which 204 the registrar interacts with the CA are transparent to the pledge and 205 are out-of-scope of this document. 207 The architecture shows the cloud registrar and MASA as being 208 logically separate entities. The two functions could of course be 209 integrated into a single service. 211 TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. 212 Cloud Registrar returns VOUCHER pinning Owner Register. 214 |<--------------OWNER------------------------>| MANUFACTURER 216 On-site Cloud 217 +--------+ +-----------+ 218 | Pledge |---------------------------------------->| Cloud | 219 +--------+ | Registrar | 220 | +---+ +----+ 221 | |??| 222 | +-----------+ +---+ +----+ 223 +---------------->| Owner |--------------->| MASA | 224 | VR-sign(N) | Registrar |sign(VR-sign(N))+-----------+ 225 | +-----------+ 226 | | +-----------+ 227 | +--->| CA | 228 | +-----------+ 229 | 230 | +-----------+ 231 +---------------->| Services | 232 +-----------+ 234 Figure 1: High Level Architecture 236 2.1. Interested Parties 238 1. OEM - Equipment manufacturer. Operate the MASA. 240 2. Network operator. Operate the Owner Registrar. Often operated 241 by end owner (company), or by outsourced IT entity. 243 3. Network integrator. They operate a Cloud Registrar. 245 2.2. Network Connectivity 247 The assumption is that the pledge already has network connectivity 248 prior to connecting to the cloud registrar. The pledge must have an 249 IP address, must be able to make DNS queries, and must be able to 250 send HTTP requests to the cloud registrar. The pledge operator has 251 already connected the pledge to the network, and the mechanism by 252 which this has happened is out of scope of this document. 254 2.3. Pledge Certificate Identity Considerations 256 BRSKI section 5.9.2 specifies that the pledge MUST send a CSR 257 Attributes request to the registrar. The registrar MAY use this 258 mechanism to instruct the pledge about the identities it should 259 include in the CSR request it sends as part of enrollment. The 260 registrar may use this mechanism to tell the pledge what Subject or 261 Subject Alternative Name identity information to include in its CSR 262 request. This can be useful if the Subject must have a specific 263 value in order to complete enrollment with the CA. 265 For example, the pledge may only be aware of its IDevID Subject which 266 includes a manufacturer serial number, but must include a specific 267 fully qualified domain name in the CSR in order to complete domain 268 ownership proofs required by the CA. 270 As another example, the registrar may deem the manufacturer serial 271 number in an IDevID as personally identifiable information, and may 272 want to specify a new random opaque identifier that the pledge should 273 use in its CSR. 275 3. Protocol Operation 277 3.1. Pledge Requests Voucher from Cloud Registrar 279 3.1.1. Cloud Registrar Discovery 281 BRSKI defines how a pledge MAY contact a well known URI of a cloud 282 registrar if a local domain registrar cannot be discovered. 283 Additionally, certain pledge types may never attempt to discover a 284 local domain registrar and may automatically bootstrap against a 285 cloud registrar. 287 The details of the URI are manufacturer specific, with BRSKI giving 288 the example "brski-registrar.manufacturer.example.com". 290 The Pledge SHOULD be provided with the entire URL of the Cloud 291 Registrar, including the path component, which is typically "/.well- 292 known/brski/requestvoucher", but may be another value. 294 3.1.2. Pledge - Cloud Registrar TLS Establishment Details 296 The pledge MUST use an Implicit Trust Anchor database (see [RFC7030]) 297 to authenticate the cloud registrar service. The Pledge can be done 298 with pre-loaded trust-anchors that are used to validate the TLS 299 connection. This can be using a public Web PKI trust anchors using 300 [RFC6125] DNS-ID mechanisms, a pinned certification authority, or 301 even a pinned raw public key. This is a local implementation 302 decision. 304 The pledge MUST NOT establish a provisional TLS connection (see BRSKI 305 section 5.1) with the cloud registrar. 307 The cloud registrar MUST validate the identity of the pledge by 308 sending a TLS CertificateRequest message to the pledge during TLS 309 session establishment. The cloud registrar MAY include a 310 certificate_authorities field in the message to specify the set of 311 allowed IDevID issuing CAs that pledges may use when establishing 312 connections with the cloud registrar. 314 The cloud registrar MAY only allow connections from pledges that have 315 an IDevID that is signed by one of a specific set of CAs, e.g. 316 IDevIDs issued by certain manufacturers. 318 The cloud registrar MAY allow pledges to connect using self-signed 319 identity certificates or using Raw Public Key [RFC7250] certificates. 321 3.1.3. Pledge Issues Voucher Request 323 After the pledge has established a full TLS connection with the cloud 324 registrar and has verified the cloud registrar PKI identity, the 325 pledge generates a voucher request message as outlined in BRSKI 326 section 5.2, and sends the voucher request message to the cloud 327 registrar. 329 3.2. Cloud Registrar Handles Voucher Request 331 The cloud registrar must determine pledge ownership. Once ownership 332 is determined, or if no owner can be determined, then the registrar 333 may: 335 * return a suitable 4xx or 5xx error response to the pledge if the 336 registrar is unwilling or unable to handle the voucher request 338 * redirect the pledge to an owner register via 307 response code 340 * issue a voucher and return a 200 response code 342 3.2.1. Pledge Ownership Lookup 344 The cloud registrar needs some suitable mechanism for knowing the 345 correct owner of a connecting pledge based on the presented identity 346 certificate. For example, if the pledge establishes TLS using an 347 IDevID that is signed by a known manufacturing CA, the registrar 348 could extract the serial number from the IDevID and use this to 349 lookup a database of pledge IDevID serial numbers to owners. 351 Alternatively, if the cloud registrar allows pledges to connect using 352 self-signed certificates, the registrar could use the thumbprint of 353 the self-signed certificate to lookup a database of pledge self- 354 signed certificate thumbprints to owners. 356 The mechanism by which the cloud registrar determines pledge 357 ownership is out-of-scope of this document. 359 3.2.2. Cloud Registrar Redirects to Owner Registrar 361 Once the cloud registar has determined pledge ownership, the cloud 362 registrar may redirect the pledge to the owner registrar in order to 363 complete bootstrap. Ownership registration will require the owner to 364 register their local domain. The mechanism by which pledge owners 365 register their domain with the cloud registrar is out-of-scope of 366 this document. 368 The cloud registrar replies to the voucher request with a suitable 369 HTTP 307 response code, including the owner's local domain in the 370 HTTP Location header. 372 3.2.3. Cloud Registrar Issues Voucher 374 If the cloud registrar issues a voucher, it returns the voucher in a 375 HTTP response with a 200 response code. 377 The cloud registrar MAY issue a 202 response code if it is willing to 378 issue a voucher, but will take some time to prepare the voucher. 380 The voucher MUST include the "est-domain" field as defined below. 381 This tells the pledge where the domain of the EST service to use for 382 completing certificate enrollment. 384 The voucher MAY include the "additional-configuration" field.. This 385 points the pledge to a URI where application specific additional 386 configuration information may be retrieved. Pledge and Registrar 387 behavior for handling and specifying the "additional-configuration" 388 field is out-of-scope of this document. 390 3.3. Pledge Handles Cloud Registrar Response 392 3.3.1. Redirect Response 394 The cloud registrar returned a 307 response to the voucher request. 395 The pledge should complete BRSKI bootstrap as per standard BRSKI 396 operation after following the HTTP redirect. The pledge should 397 establish a provisional TLS connection with specified local domain 398 registrar. The pledge should not use its Implicit Trust Anchor 399 database for validating the local domain registrar identity. The 400 pledge should send a voucher request message via the local domain 401 registrar. When the pledge downloads a voucher, it can validate the 402 TLS connection to the local domain registrar and continue with 403 enrollment and bootstrap as per standard BRSKI operation. 405 3.3.2. Voucher Response 407 The cloud registrar returned a voucher to the pledge. The pledge 408 should perform voucher verification as per standard BRSKI operation. 409 The pledge should verify the voucher signature using the 410 manufacturer-installed trust anchor(s), should verify the serial 411 number in teh voucher, and must verify any nonce information in the 412 voucher. 414 The pledge should extract the "est-domain" field from the voucher, 415 and should continue with EST enrollment as per standard BRSKI 416 operation. 418 4. Protocol Details 420 4.1. Voucher Request Redirected to Local Domain Registrar 422 This flow illlustrates the Owner Registrar Discovery flow. A pledge 423 is bootstrapping in a remote location with no local domain registrar. 424 The assumption is that the owner registrar domain is accessible and 425 the pledge can establish a network connection with the owner 426 registrar. This may require that the owner network firewall exposes 427 the registrar on the public internet. 429 +--------+ +----------+ 430 | Pledge | | Cloud RA | 431 | | | | 432 +--------+ +----------+ 433 | | 434 | 1. Mutual-authenticated TLS | 435 |<----------------------------------------------->| 436 | | 437 | 2. Voucher Request | 438 |------------------------------------------------>| 439 | | 440 | 3. 307 Location: owner-ra.example.com | 441 |<------------------------------------------------| 442 | 443 | +-----------+ +---------+ 444 | | Owner | | MASA | 445 | | Registrar | | | 446 | +-----------+ +---------+ 447 | 4. Provisional TLS | | 448 |<-------------------->| | 449 | | | 450 | 5. Voucher Request | | 451 |--------------------->| 6. Voucher Request | 452 | |------------------------->| 453 | | | 454 | | 7. Voucher Response | 455 | |<-------------------------| 456 | 8. Voucher Response | | 457 |<---------------------| | 458 | | | 459 | 9. Validate TLS | | 460 |<-------------------->| | 461 | | | 462 | 10. etc. | | 463 |--------------------->| | 465 The process starts, in step 1, when the Pledge establishes a Mutual 466 TLS channel with the Cloud RA using artifacts created during the 467 manufacturing process of the Pledge. 469 In step 2, the Pledge sends a voucher request to the Cloud RA. 471 The Cloud RA completes pledge ownership lookup as outlined in 472 Section 3.2.1, and determines the owner registrar domain. In step 3, 473 the Cloud RA redirects the pledge to the owner registrar domain. 475 Steps 4 and onwards follow the standard BRSKI flow. The pledge 476 establishes a provisional TLS connection with the owner registrar, 477 and sends a voucher request to the owner registrar. The registar 478 forwards the voucher request to the MASA. Assuming the MASA issues a 479 voucher, then the pledge validates the TLS connection with the 480 registrar using the pinned-domain-cert from the voucher and completes 481 the BRSKI flow. 483 4.2. Voucher Request Handled by Cloud Registrar 485 The Voucher includes the EST domain to use for EST enroll. It is 486 assumed services are accessed at that domain too. As trust is 487 already established via the Voucher, the pledge does a full TLS 488 handshake against the local RA indicated by the voucher response. 490 The returned voucher contains an attribute, "est-domain", defined in 491 Section 5 below. The pledge is directed to continue enrollment using 492 the EST registrar found at that URI. The pledge uses the pinned- 493 domain-cert from the voucher to authenticate the EST registrar. 495 +--------+ +----------+ 496 | Pledge | | Cloud RA | 497 | | | / MASA | 498 +--------+ +----------+ 499 | | 500 | 1. Mutual TLS | 501 |<----------------------------------------------->| 502 | | 503 | 2. Voucher Request | 504 |------------------------------------------------>| 505 | | 506 | 3. Voucher Response {est-domain:fqdn} | 507 |<------------------------------------------------| 508 | | 509 | +----------+ | 510 | | RFC7030 | | 511 | | EST | | 512 | | Registrar| | 513 | +----------+ | 514 | | | 515 | 4. Full TLS | | 516 |<-------------------->| | 517 | | 518 | 3a. /voucher_status POST success | 519 |------------------------------------------------>| 520 | ON FAILURE 3b. /voucher_status POST | 521 | | 522 | 5. EST Enrol | | 523 |--------------------->| | 524 | | | 525 | 6. Certificate | | 526 |<---------------------| | 527 | | | 528 | 7. /enrollstatus | | 529 |--------------------->| | 531 The process starts, in step 1, when the Pledge establishes a Mutual 532 TLS channel with the Cloud RA/MASA using artifacts created during the 533 manufacturing process of the Pledge. In step 2, the Pledge sends a 534 voucher request to the Cloud RA/MASA, and in response the Pledge 535 receives an [RFC8366] format voucher from the Cloud RA/MASA that 536 includes its assigned EST domain in the est-domain attribute. 538 At this stage, the Pledge should be able to establish a TLS channel 539 with the EST Registrar. The connection may involve crossing the 540 Internet requiring a DNS lookup on the provided name. It may also be 541 a local address that includes an IP address literal including both 542 [RFC1918] and IPv6 Unique Local Address. The EST Registrar is 543 validated using the pinned-domain-cert value provided in the voucher 544 as described in section 5.6.2 of 545 [I-D.ietf-anima-bootstrapping-keyinfra]. This involves treating the 546 artifact provided in the pinned-domain-cert as a trust anchor, and 547 attempting to validate the EST Registrar from this anchor only. 549 There is a case where the pinned-domain-cert is the identical End- 550 Entity (EE) Certificate as the EST Registrar. It also explicitly 551 includes the case where the EST Registrar has a self-signed EE 552 Certificate, but it may also be an EE certificate that is part of a 553 larger PKI. If the certificate is not a self-signed or EE 554 certificate, then the Pledge SHOULD apply [RFC6125] DNS-ID validation 555 on the certificate against the URL provided in the est-domain 556 attribute. If the est-domain was provided by with an IP address 557 literal, then it is unlikely that it can be validated, and in that 558 case, it is expected that either a self-signed certificate or an EE 559 certificate will be pinned. 561 The Pledge also has the details it needs to be able to create the CSR 562 request to send to the RA based on the details provided in the 563 voucher. 565 In step 4, the Pledge establishes a TLS channel with the Cloud RA/ 566 MASA, and optionally the pledge should send a request, steps 3.a and 567 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to 568 establish a secure TLS channel with the EST Registrar. 570 The Pledge then follows that, in step 5, with an EST Enroll request 571 with the CSR and obtains the requested certificate. The Pledge must 572 validate that the issued certificate has the expected identifier 573 obtained from the Cloud RA/MASA in step 3. 575 5. YANG extension for Voucher based redirect 577 An extension to the [RFC8366] voucher is needed for the case where 578 the client will be redirected to a local EST Registrar. 580 5.1. YANG Tree 581 module: ietf-redirected-voucher 583 grouping voucher-redirected-grouping 584 +-- voucher 585 +-- created-on yang:date-and-time 586 +-- expires-on? yang:date-and-time 587 +-- assertion enumeration 588 +-- serial-number string 589 +-- idevid-issuer? binary 590 +-- pinned-domain-cert binary 591 +-- domain-cert-revocation-checks? boolean 592 +-- nonce? binary 593 +-- last-renewal-date? yang:date-and-time 594 +-- est-domain? ietf:uri 595 +-- additional-configuration? ietf:uri 597 5.2. YANG Voucher 599 file "ietf-redirected-voucher@2020-09-23.yang" 600 module ietf-redirected-voucher { 601 yang-version 1.1; 603 namespace 604 "urn:ietf:params:xml:ns:yang:ietf-redirected-voucher"; 605 prefix "redirected"; 607 import ietf-restconf { 608 prefix rc; 609 description 610 "This import statement is only present to access 611 the yang-data extension defined in RFC 8040."; 612 reference "RFC 8040: RESTCONF Protocol"; 613 } 615 import ietf-inet-types { 616 prefix ietf; 617 reference "RFC 6991: Common YANG Data Types"; 618 } 620 import ietf-voucher { 621 prefix "v"; 622 } 624 organization 625 "IETF ANIMA Working Group"; 627 contact 628 "WG Web: 629 WG List: 630 Author: Michael Richardson 631 632 Author: Owen Friel 633 634 Author: Rifaat Shekh-Yusef 635 "; 636 description 637 "This module extendes the base RFC8366 voucher format to include a redirect 638 to an EST server to which enrollment should continue. 640 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 641 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 642 and 'OPTIONAL' in the module text are to be interpreted as 643 described in BCP14, RFC 2119, and RFC8174."; 645 revision "2020-09-23" { 646 description 647 "Initial version"; 648 reference 649 "RFC XXXX: Voucher Profile for Cloud redirected Devices"; 650 } 652 rc:yang-data voucher-redirected-artifact { 653 // YANG data template for a voucher. 654 uses voucher-redirected-grouping; 655 } 657 // Grouping defined for future usage 658 grouping voucher-redirected-grouping { 659 description 660 "Grouping to allow reuse/extensions in future work."; 662 uses v:voucher-artifact-grouping { 664 augment "voucher" { 665 description "Base the constrained voucher 666 upon the regular one"; 667 leaf est-domain { 668 type ietf:uri; 669 description 670 "The est-domain is a URL to which the Pledge should continue 671 doing enrollment rather than with the Cloud Registrar."; 672 } 673 leaf additional-configuration { 674 type ietf:uri; 675 description 676 "The additional-configuration attribute contains a URL to which the Pledge can retrieve additional configuration 677 information. The contents of this URL are vendor specific. This is intended to do things like configure 678 a VoIP phone to point to the correct hosted PBX, for example."; 679 } 680 } 681 } 682 } 683 } 684 686 6. IANA Considerations 688 TODO:MCR - Will need to add IETF YANG registration from templates. [[ 689 TODO ]] 691 7. Security Considerations 693 [[ TODO ]] 695 8. References 697 8.1. Normative References 699 [I-D.ietf-anima-bootstrapping-keyinfra] 700 Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. 701 H., and K. Watsen, "Bootstrapping Remote Secure Key 702 Infrastructures (BRSKI)", Work in Progress, Internet- 703 Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 704 November 2020, . 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, 709 DOI 10.17487/RFC2119, March 1997, 710 . 712 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 713 "Enrollment over Secure Transport", RFC 7030, 714 DOI 10.17487/RFC7030, October 2013, 715 . 717 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 718 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 719 May 2017, . 721 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 722 "A Voucher Artifact for Bootstrapping Protocols", 723 RFC 8366, DOI 10.17487/RFC8366, May 2018, 724 . 726 8.2. Informative References 728 [IEEE802.1AR] 729 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 730 2018, . 733 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 734 J., and E. Lear, "Address Allocation for Private 735 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 736 February 1996, . 738 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 739 Verification of Domain-Based Application Service Identity 740 within Internet Public Key Infrastructure Using X.509 741 (PKIX) Certificates in the Context of Transport Layer 742 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 743 2011, . 745 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 746 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 747 Transport Layer Security (TLS) and Datagram Transport 748 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 749 June 2014, . 751 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 752 Touch Provisioning (SZTP)", RFC 8572, 753 DOI 10.17487/RFC8572, April 2019, 754 . 756 Authors' Addresses 758 Owen Friel 759 Cisco 761 Email: ofriel@cisco.com 763 Rifaat Shekh-Yusef 764 Auth0 766 Email: rifaat.s.ietf@gmail.com 768 Michael Richardson 769 Sandelman Software Works 771 Email: mcr+ietf@sandelman.ca