idnits 2.17.1 draft-ietf-acme-star-delegation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 March 2020) is 1504 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) ** Downref: Normative reference to an Informational draft: draft-handrews-json-schema (ref. 'I-D.handrews-json-schema') ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-05 == Outdated reference: A later version (-13) exists of draft-ietf-cdni-interfaces-https-delegation-02 == Outdated reference: A later version (-04) exists of draft-ietf-stir-cert-delegation-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Standards Track D. Lopez 5 Expires: 9 September 2020 A. Pastor Perales 6 Telefonica I+D 7 T. Fossati 8 ARM 9 8 March 2020 11 An ACME Profile for Generating Delegated STAR Certificates 12 draft-ietf-acme-star-delegation-03 14 Abstract 16 This memo proposes a profile of the ACME protocol that allows the 17 owner of an identifier (e.g., a domain name) to delegate to a third 18 party access to a certificate associated with said identifier. A 19 primary use case is that of a CDN (the third party) terminating TLS 20 sessions on behalf of a content provider (the owner of a domain 21 name). The presented mechanism allows the owner of the identifier to 22 retain control over the delegation and revoke it at any time by 23 cancelling the associated STAR certificate renewal with the ACME CA. 24 Another key property of this mechanism is it does not require any 25 modification to the deployed TLS ecosystem. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 9 September 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Conventions used in this document . . . . . . . . . . . . 4 63 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 6 67 2.3.1. Order Object on the NDC-IdO side . . . . . . . . . . 7 68 2.3.2. Order Object on the IdO-CA side . . . . . . . . . . . 9 69 2.3.3. Capability Discovery . . . . . . . . . . . . . . . . 9 70 2.3.4. On Cancellation . . . . . . . . . . . . . . . . . . . 10 71 2.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 10 72 3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 11 74 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 13 78 4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 13 79 4.2. STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 5.1. New Fields in the "auto-renewal" Object within a 82 Directory Metadata Object . . . . . . . . . . . . . . . . 17 83 5.2. New Fields for Identifiers . . . . . . . . . . . . . . . 18 84 5.3. CSR Template Registry . . . . . . . . . . . . . . . . . . 18 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 6.1. Restricting CDNs to the Delegation Mechanism . . . . . . 18 87 6.2. TBC . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 8.2. Informative References . . . . . . . . . . . . . . . . . 20 92 Appendix A. Document History . . . . . . . . . . . . . . . . . . 21 93 A.1. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 21 94 A.2. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 21 95 A.3. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 21 96 A.4. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 21 97 A.5. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 21 98 A.6. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 21 99 Appendix B. CSR Template Schema . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 This document is a companion document to [I-D.ietf-acme-star]. To 105 avoid duplication, we give here a bare-bones description of the 106 motivation for this solution. For more details and further use 107 cases, please refer to the introductory sections of 108 [I-D.ietf-acme-star]. 110 An Identifier Owner (IdO), that we can associate in the primary use 111 case to a content provider (also referred to as Domain Name Owner, 112 DNO), has agreements in place with one or more NDC (Name Delegation 113 Consumer) to use and attest its identity. In the primary use case, 114 we consider a CDN provider contracted to serve the IdO content over 115 HTTPS. The CDN terminates the HTTPS connection at one of its edge 116 cache servers and needs to present its clients (browsers, mobile 117 apps, set-top-boxes) a certificate whose name matches the authority 118 of the URL that is requested, i.e., that of the IdO. Understandably, 119 most IdOs balk at sharing their long-term private keys with another 120 organization and, equally, delegates would rather not have to handle 121 other parties' long-term secrets. 123 Other relevant use cases are discussed in Section 4. 125 This document describes a profile of the ACME protocol [RFC8555] that 126 allows the NDC to request the IdO, acting as a profiled ACME server, 127 a certificate for a delegated identity - i.e., one belonging to the 128 IdO. The IdO then uses the ACME protocol (with the extensions 129 described in [I-D.ietf-acme-star]) to request issuance of a STAR 130 certificate for the same delegated identity. The generated short- 131 term certificate is automatically renewed by the ACME Certification 132 Authority (CA), periodically fetched by the NDC and used to terminate 133 HTTPS connections in lieu of the IdO. The IdO can end the delegation 134 at any time by simply instructing the CA to stop the automatic 135 renewal and letting the certificate expire shortly thereafter. 137 In case the delegated identity is a domain name, this document also 138 provides a way for the NDC to inform the IdO about the CNAME mappings 139 that need to be installed in the IdO's DNS zone to enable the 140 aliasing of the delegated name, thus allowing the complete name 141 delegation workflow to be handled using a single interface. 143 1.1. Terminology 144 IdO Identifier Owner, the owner of an identifier (e.g., a domain 145 name) that needs to be delegated. 146 DNO Domain Name Owner, a specific kind of IdO whose identifier is a 147 domain name 148 NDC Name Delegation Consumer, the entity to which the domain name is 149 delegated for a limited time. This is a CDN in the primary use 150 case (in fact, readers may note the symmetry of the two acronyms). 151 CDN Content Delivery Network, a widely distributed network that 152 serves the domain's web content to a wide audience at high 153 performance. 154 STAR Short-Term, Automatically Renewed X.509 certificates. 155 ACME The IETF Automated Certificate Management Environment, a 156 certificate management protocol. 157 CA A Certificate Authority that implements the ACME protocol. 159 1.2. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 2. Protocol Flow 169 This section presents the protocol flow. For completeness, we 170 include the ACME profile proposed in this draft as well as the 171 extended ACME protocol described in [I-D.ietf-acme-star]. 173 2.1. Preconditions 175 The protocol assumes the following preconditions are met: 177 * The IdO exposes an ACME server interface to the NDC(s) comprising 178 the account management interface; 179 * The NDC has registered an ACME account with the IdO; 180 * NDC and IdO have agreed on a "CSR template" to use, including at a 181 minimum: subject name (e.g., "somesite.example.com"), requested 182 algorithms and key length, key usage, extensions (e.g., 183 TNAuthList). The NDC is required to use this template for every 184 CSR created under the same delegation; 185 * IdO has registered an ACME account with the Certificate Authority 186 (CA) 188 Note that even if the IdO implements the ACME server role, it is not 189 acting as a CA: in fact, from the point of view of the certificate 190 issuance process, the IdO only works as a "policing" forwarder of the 191 NDC's key-pair and is responsible for completing the identity 192 verification process towards the ACME CA. 194 2.2. Overview 196 The interaction between the NDC and the IdO is governed by the 197 profiled ACME workflow detailed in Section 2.3. The interaction 198 between the IdO and the CA is ruled by ACME STAR [I-D.ietf-acme-star] 199 as well as any other ACME extension that applies (e.g., 200 [I-D.ietf-acme-authority-token-tnauthlist] for STIR). 202 The outline of the combined protocol is as follow (Figure 1): 204 * NDC sends an Order for the delegated identifier to IdO; 205 * IdO creates an Order resource in state "ready" with a "finalize" 206 URL; 207 * NDC immediately sends a finalize request (which includes the CSR) 208 to the IdO; 209 * IdO verifies the CSR according to the agreed upon CSR template; 210 * If the CSR verification fails, the Order is moved to an "invalid" 211 state and everything stops; 212 * If the CSR verification is successful, IdO moves the Order to 213 state "processing", and sends an Order' (using its own account) 214 for the delegated identifier to the ACME STAR CA; 215 * If the ACME STAR protocol fails, Order' moves to "invalid" and the 216 same state is reflected in the NDC Order; 217 * If the ACME STAR run is successful (i.e., Order' is "valid"), IdO 218 copies the "star-certificate" URL from Order' to Order and moves 219 its state to "valid". 221 The NDC can now download, install and use the short-term certificate 222 bearing the name delegated by the IdO. This sequence of actions is 223 repeated until the STAR certificate expires or the IdO decides to 224 cancel the automatic renewal process with the ACME STAR CA. 226 Note that, because the identity validation is suppressed, the NDC 227 sends the finalize request, including the CSR, to the IdO immediately 228 after the Order has been acknowledged. The IdO must buffer a (valid) 229 CSR until the Validation phase completes successfully. 231 .------. .---------------. .------. 232 | NDC | | IdO | | CA | 233 +--------+ +--------+--------+ +--------+ 234 | Client | | Server | Client | | Server | 235 '---+----' '----+---+---+----' '----+---' 236 | | | | 237 | Order | | | 238 | Signature | | | 239 o------------------->| | | 240 | | | | 241 | [ No identity ] | | | 242 | [ validation ] | | | 243 | | | | 244 | CSR | | | 245 | Signature | | | 246 o------------------->| | | 247 | Acknowledgement | | Order' | 248 |<-------------------o | Signature | 249 | | o------------------->| 250 | | | Required | 251 | | | Authorizations | 252 | | |<-------------------o 253 | | | Responses | 254 | | | Signature | 255 | | o------------------->| 256 | | | | 257 | | |<~~~~Validation~~~~>| 258 | | | | 259 | | | CSR | 260 | | | Signature | 261 | | o------------------->| 262 | | | Acknowledgement | 263 | | |<-------------------o 264 | | | | 265 |<~~Await issuance~->| |<~~Await issuance~~>| 266 | | 267 | (unauthenticated) GET STAR certificate | 268 o------------------------------------------------>| 269 | Certificate #1 | 270 |<------------------------------------------------o 271 | (unauthenticated) GET STAR certificate | 272 o------------------------------------------------>| 273 | Certificate #2 | 274 |<------------------------------------------------o 275 | [...] | 276 | (unauthenticated) GET STAR certificate | 277 o------------------------------------------------>| 278 | Certificate #n | 279 |<------------------------------------------------o 281 Figure 1: End to end STAR delegation flow 283 2.3. Delegated Identity Profile 284 2.3.1. Order Object on the NDC-IdO side 286 The Order object created by the NDC: 288 * MUST contain identifiers with the new "delegated" field set to 289 true; 290 * MUST NOT contain the notBefore and notAfter fields; 291 * MAY contain an "auto-renewal" object and inside it, any of the 292 fields listed in Section 3.1.1 of [I-D.ietf-acme-star]; 293 * In case the identifier type is "dns", it MAY contain a "cname" 294 field with the alias of the identifier in the NDC domain. This 295 field is used by the IdO to create the DNS aliasing needed to 296 redirect the resolvers to the delegated entity. 298 POST /acme/new-order HTTP/1.1 299 Host: acme.dno.example 300 Content-Type: application/jose+json 302 { 303 "protected": base64url({ 304 "alg": "ES256", 305 "kid": "https://acme.dno.example/acme/acct/evOfKhNU60wg", 306 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 307 "url": "https://acme.dno.example/acme/new-order" 308 }), 309 "payload": base64url({ 310 "identifiers": [ 311 { 312 "type": "dns", 313 "value": "abc.ndc.dno.example.", 314 "delegated": true, 315 "cname": "abc.ndc.example." 316 } 317 ], 318 }), 319 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 320 } 322 The Order object that is created on the IdO: 324 * MUST start in the "ready" state; 325 * MUST contain an "authorizations" array with zero elements; 326 * MUST NOT contain the "notBefore" and "notAfter" fields. 328 { 329 "status": "ready", 330 "expires": "2016-01-01T00:00:00Z", 332 "identifiers": [ 333 { 334 "type": "dns", 335 "value": "abc.ndc.dno.example.", 336 "delegated": true, 337 "cname": "abc.ndc.example." 338 } 339 ], 341 "authorizations": [], 343 "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize" 344 } 346 The IdO SHOULD copy the "auto-renewal" object (if it exists) from the 347 NDC request into the related STAR request to the ACME CA. 349 When the validation of the identifiers has been successfully 350 completed and the certificate has been issued by the CA, the IdO: 352 * MUST move its Order resource status to "valid"; 353 * MUST copy the "star-certificate" field from the STAR Order; 355 The latter indirectly includes (via the NotBefore and NotAfter HTTP 356 headers) the renewal timers needed by the NDC to inform its 357 certificate reload logic. 359 { 360 "status": "valid", 361 "expires": "2016-01-01T00:00:00Z", 363 "identifiers": [ 364 { 365 "type": "dns", 366 "value": "abc.ndc.dno.example.", 367 "delegated": true, 368 "cname": "abc.ndc.example." 369 } 370 ], 372 "authorizations": [], 374 "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize", 376 "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" 377 } 379 If an "identifier" object of type "dns" was included, the IdO MUST 380 validate the specified CNAME at this point in the flow. The NDC and 381 IdO may have a pre-established list of valid CNAME values. At the 382 minimum, the IdO MUST verify that both DNS names are syntactically 383 valid. 385 Following this validation, the IdO can add the CNAME records to its 386 zone: 388 abc.ndc.dno.example. CNAME abc.ndc.example. 390 2.3.2. Order Object on the IdO-CA side 392 When sending the Order to the ACME CA, the IdO SHOULD strip the 393 "delegated" and "cname" attributes sent by the NDC (Section 2.3.1). 394 The IdO MUST add the necessary STAR extensions to the Order. In 395 addition, to allow the NDC to download the certificate using 396 unauthenticated GET, the IdO MUST add the allow-certificate-get 397 attribute and set it to true. This implies that an "auto-renewal" 398 object must be included in the Order. 400 2.3.3. Capability Discovery 402 In order to help a client to discover support for this profile, the 403 directory object of an ACME server MUST contain the following 404 attribute inside the "auto-renewal" object in the "meta" field: 406 * delegation-enabled: boolean flag indicating support for the 407 profile specified in this memo. An ACME server that supports this 408 delegation profile MUST include this key, and MUST set it to true. 410 2.3.4. On Cancellation 412 It is worth noting that cancellation of the ACME STAR certificate is 413 a prerogative of the IdO. The NDC does not own the relevant account 414 key on the ACME CA, therefore it can't issue a cancellation request 415 for the STAR cert. Potentially, since it holds the STAR 416 certificate's private key, it could request the revocation of a 417 single STAR certificate. However, STAR explicitly disables the 418 revokeCert interface. 420 2.4. Proxy Behavior 422 There are cases where the ACME Delegation flow should be proxied, 423 such as the use case described in Section 4.1.2. This section 424 describes the behavior of such proxies. 426 An ACME Delegation server can decide, on a per-identity case, whether 427 to act as a proxy into another ACME Delegation server, or to behave 428 as an IdO and obtain a certificate directly. The determining factor 429 is whether the server can successfully be authorized by the ACME 430 Server for the identity associated with the certificate request. 432 The identities supported by each server and the disposition for each 433 of them are preconfigured. 435 Following is the proxy's behavior for each of the messages exchanged 436 in the ACME Delegation process: 438 * New-order request: 439 - The complete "identifiers" object MUST be copied as-is. 440 - Similarly, the "auto-renewal" object MUST be copied as-is. 441 * New-order response: 442 - The "status", "expires", "authorizations", "identifiers" and 443 "auto-renewal" attributes/objects MUST be copied as-is. 444 - The "finalize" URL is rewritten, so that the "finalize" request 445 will be made to the proxy. 446 - Similarly, the Location header is rewritten. 447 * Get Order response: 448 - The "status", "expires", "authorizations", "identifiers" and 449 "auto-renewal" attributes/objects MUST be copied as-is. 450 - Similarly, the "star-certificate" URL MUST be copied as-is. 451 - The "finalize" URL is rewritten, so that the "finalize" request 452 will be made to the proxy. 453 - The "Location" header must be rewritten. 455 * Finalize request: 456 - The CSR MUST be copied as-is. 457 * Finalize response: 458 - Both the Location header and the "finalize" URLs are rewritten. 460 We note that all the above messages are authenticated, and therefore 461 each proxy must be able to authenticate any subordinate server. 463 3. CSR Template 465 The CSR template is used to express and constrain the shape of the 466 CSR that the NDC uses to request the certificate. The CSR is used 467 for every certificate created under the same delegation. Its 468 validation by the IdO is a critical element in the security of the 469 whole delegation mechanism. 471 Instead of defining every possible CSR attribute, this document takes 472 a minimalist approach by declaring only the minimum attribute set and 473 deferring the registration of further, more specific, attributes to 474 future documents. 476 3.1. Template Syntax 478 The template is a JSON document. Each field denotes one of: 480 * A mandatory field, where the template specifies the literal value 481 of that field. This is denoted by a literal string, such as 482 "client1.ndc.dno.example.com". 483 * A mandatory field, where the content of the field is defined by 484 the client. This is denoted by "**". 485 * An optional field, where the client decides whether the field is 486 included in the CSR and what its value is. This is denoted by 487 "*". 489 The NDC MUST NOT include in the CSR any fields that are not specified 490 in the template, and in particular MUST NOT add any extensions unless 491 those were previously negotiated out of band with the IdO. 493 The mapping between X.509 CSR fields and the template will be defined 494 in a future revision of this document. 496 When the CSR is received by the IdO, it MUST verify that the CSR is 497 consistent with the template that the IdO sent earlier. The IdO MAY 498 enforce additional constraints, e.g. by restricting field lengths. 500 3.2. Example 502 The CSR template in Figure 2 represents one possible CSR template 503 governing the delegation exchanges provided in the rest of this 504 document. 506 { 507 "keyTypes": [ 508 { 509 "PublicKeyType": "RSA", 510 "PublicKeyLength": 4096, 511 "SignatureType": "sha256WithRSAEncryption" 512 } 513 ], 514 "subject": { 515 "country": "CA", 516 "stateOrProvince": "**", 517 "locality": "**", 518 "commonName": "**" 519 }, 520 "extensions": { 521 "subjectAltName": { 522 "DNS": [ 523 "client1.ndc.dno.example" 524 ], 525 "IP": [ 526 "1.2.3.4", 527 "13::17" 528 ] 529 }, 530 "keyUsage": [ 531 "digitalSignature" 532 ], 533 "extendedKeyUsage": [ 534 "serverAuth", 535 "timeStamping" 536 ] 537 } 538 } 540 Figure 2: Example CSR template 542 The template syntax is defined in Appendix B. 544 4. Further Use Cases 545 4.1. CDNI 547 [I-D.ietf-cdni-interfaces-https-delegation] discusses several 548 solutions addressing different delegation requirements for the CDNI 549 (CDN Interconnection) environment. This section discusses two of the 550 stated requirements in the context of the STAR delegation workflow. 552 4.1.1. Multiple Parallel Delegates 554 In some cases the content owner (IdO) would like to delegate 555 authority over a web site to multiple NDCs (CDNs). This could happen 556 if the IdO has agreements in place with different regional CDNs for 557 different geographical regions, or if a "backup" CDN is used to 558 handle overflow traffic by temporarily altering some of the CNAME 559 mappings in place. The STAR delegation flow enables this use case 560 naturally, since each CDN can authenticate separately to the IdO (via 561 its own separate account) specifying its CSR, and the IdO is free to 562 allow or deny each certificate request according to its own policy. 564 4.1.2. Chained Delegation 566 In other cases, a content owner (IdO) delegates some domains to a 567 large CDN (uCDN), which in turn delegates to a smaller regional CDN, 568 dCDN. The DNO has a contractual relationship with uCDN, and uCDN has 569 a similar relationship with dCDN. However IdO may not even know 570 about dCDN. 572 If needed, the STAR protocol can be chained to support this use case: 573 uCDN could forward requests from dCDN to DNO, and forward responses 574 back to dCDN. Whether such proxying is allowed is governed by policy 575 and contracts between the parties. 577 A mechanism is necessary at the interface between uCDN and dCDN by 578 which the uCDN can advertise: 580 * The namespace that is made available to the dCDN to mint its 581 delegated names; 582 * The policy for creating the key material (allowed algorithms, 583 minimum key lengths, key usage, etc.) that the dCDN needs to 584 satisfy. 586 Note that such mechanism is provided by the CSR template. 588 4.1.2.1. Two-Level Delegation in CDNI 590 A User Agent (browser or set-top-box) wants to fetch the video 591 resource at the following URI: "https://video.cp.example/movie". 592 Redirection between Content Provider, upstream, and downstream CDNs 593 is arranged as a CNAME-based aliasing chain as illustrated in 594 Figure 3. 596 .------------. 597 video.cp.example ? | .-----. | 598 .---------------------------------->| | | 599 | (a) | | DNS | CP | 600 | .-------------------------------+ | | 601 | | CNAME video.ucdn.example | '-----' | 602 | | '------------' 603 | | 604 | | 605 .-----------|---v--. .------------. 606 | .-----.-+-----. | video.ucdn.example ? | .-----. | 607 | | | +----------------------------->| | | 608 | UA | TLS | DNS | | (b) | | DNS | uCDN | 609 | | | |<-----------------------------+ | | 610 | '--+--'-----+-' | CNAME video.dcdn.example | '-----' | 611 '------|----^---|--' '------------' 612 | | | 613 | | | 614 | | | .------------. 615 | | | video.dcdn.example ? | .-----. | 616 | | '------------------------------>| | | 617 | | (c) | | DNS | | 618 | '-----------------------------------+ | | 619 | A 192.0.2.1 | +-----+ dCDN | 620 | | | | | 621 '--------------------------------------->| TLS | | 622 SNI: video.cp.example | | | | 623 | '-----' | 624 '------------' 626 Figure 3: DNS Redirection 628 Unlike HTTP based redirection, where the original URL is supplanted 629 by the one found in the Location header of the 302 response, DNS 630 redirection is completely transparent to the User Agent. As a 631 result, the TLS connection to the dCDN edge is done with an SNI equal 632 to the "host" in the original URI - in the example, 633 "video.cp.example". So, in order to successfully complete the 634 handshake, the landing dCDN node has to be configured with a 635 certificate whose SAN matches "video.cp.example", i.e., a Content 636 Provider's name. 638 Figure 4 illustrates the cascaded delegation flow that allows dCDN to 639 obtain a STAR certificate that bears a name belonging to the Content 640 Provider with a private key that is only known to the dCDN. 642 .--------------------. 643 | .------.------. | 644 | | STAR | ACME |<-------------. 645 .------->| CP | dele | STAR | | | 646 | | | srv | cli +-----. | 647 | | '---+--'------' | | 6 648 | '---------|------^---' 5 | 649 | | | | .--|-------. 650 | | | | | .-+----. | 651 | 7 | '---->| ACME | | 652 | | | | | STAR | C | 653 0 | 4 | +------| A | 654 | | | | | HTTP | | 655 | | | | '----+-' | 656 | | .-' '--^--|----' 657 | .--------------v--|--. | | 658 | | .------.----+-. | | 10 659 | | | | STAR | | | | 660 '-->| uCDN | CDNI | dele | | | | 661 | | | fwd | | | | 662 | '----+-'-+----' | | | 663 '-------^--|---|--^--' | | 664 | | | | | | 665 | 2 8 | | | 666 1 | | 3 | | 667 | | | | 9 | 668 .-------|--v---v--|---------. | | 669 | .-+----.----+-.------. | | | 670 | | | STAR | +------------' | 671 | dCDN | CDNI | dele | HTTP | | | 672 | | | cli | |<--------------' 673 | '------'------'------' | 674 '---------------------------' 676 Figure 4: Two levels delegation in CDNI 678 TBD bootstrap, see https://github.com/yaronf/I-D/issues/47 680 1. dCDN requests CDNI path metadata to uCDN; 681 2. uCDN replies with, among other CDNI things, the STAR delegation 682 configuration, which includes the delegated Content Provider's 683 name; 684 3. dCDN creates a key-pair and the CSR with the delegated name. It 685 then places an order for the delegated name to uCDN; 686 4. uCDN forwards the received order to the Content Provider (CP); 687 5. CP creates an order for a STAR certificate and sends it to the 688 ACME CA. The order also requests unauthenticated access to the 689 certificate resource; 690 6. After all authorizations complete successfully, the STAR 691 certificate is issued; 692 7. CP notifies uCDN that the STAR cert is available at the order's 693 star-certificate URL; 694 8. uCDN forwards the information to dCDN. At this point the ACME 695 signalling is complete; 696 9. dCDN requests the STAR cert using unauthenticated GET from the 697 ACME CA; 698 10. the CA returns the certificate. Now dCDN is fully configured to 699 handle HTTPS traffic in-lieu of the Content Provider. 701 Note that 9. and 10. repeat until the delegation expires or is 702 terminated. 704 4.2. STIR 706 As a second use case, we consider the delegation of credentials in 707 the STIR ecosystem [I-D.ietf-stir-cert-delegation]. 709 In the STIR "delegated" mode, a service provider SP2 - the NDC - 710 needs to sign PASSPorT's [RFC8225] for telephone numbers (e.g., 711 TN=+123) belonging to another service provider, SP1 - the IdO. In 712 order to do that, SP2 needs a STIR certificate, and private key, that 713 includes TN=+123 in the TNAuthList [RFC8226] cert extension. 715 In details (Figure 5): 717 1. SP1 and SP2 agree on the configuration of the delegation - in 718 particular, the CSR template that applies; 719 2. SP2 generates a private/public key-pair and sends a CSR to SP1 720 requesting creation of a certificate with: SP1 name, SP2 public 721 key, and a TNAuthList extension with the list of TNs that SP1 722 delegates to SP2. (Note that the CSR sent by SP2 to SP1 needs to 723 be validated against the CSR template agreed upon in step 1.); 724 3. SP1 sends an Order for the CSR to the ACME STAR CA; 725 4. Subsequently, after the required TNAuthList authorizations are 726 successfully completed, the ACME STAR CA moves the Order to a 727 "valid" state; at the same time the star-certificate endpoint is 728 populated. 730 5. The Order contents are forwarded from SP1 to SP2 by means of the 731 paired "delegation" Order. 732 6. SP2 dereferences the star-certificate URL in the Order to fetch 733 the rolling STAR certificate bearing the delegated identifiers. 735 .-------------------. 736 | .------.------. | 737 | | STAR | STAR |<--------------. 738 .-->| SP1 | dele | dele | | | 739 | | | srv | cli +-----. | 740 | | '----+-'------' | | 4 741 | '------^--|---------' 3 | 742 | | | | .----|-----. 743 | | 5 | | .---+--. | 744 | | | '--->| ACME | | 745 | | | | | STAR | C | 746 1 | | | +------| A | 747 | | | .--->| HTTP | | 748 | 2 | | | '---+--' | 749 | | | | '----|-----' 750 | .------|--v---------. 6 | 751 | | .-+----.------. | | 7 752 | | | STAR | +-----' | 753 '-->| SP2 | dele | HTTP | | | 754 | | cli | |<--------------' 755 | '----+-'-+----' | 756 '-------------------' 758 Figure 5: Delegation in STIR 760 As shown, the STAR delegation profile described in this document 761 applies straightforwardly, the only extra requirement being the 762 ability to instruct the NDC about the allowed TNAuthList values. 763 This can be achieved by a simple extension to the CSR template. 765 5. IANA Considerations 767 [[RFC Editor: please replace XXXX below by the RFC number.]] 769 5.1. New Fields in the "auto-renewal" Object within a Directory 770 Metadata Object 772 This document adds the following entries to the ACME Directory 773 Metadata Fields: 775 +--------------------+------------+-----------+ 776 | Field Name | Field Type | Reference | 777 +====================+============+===========+ 778 | delegation-enabled | boolean | RFC XXXX | 779 +--------------------+------------+-----------+ 781 Table 1 783 5.2. New Fields for Identifiers 785 * "delegated", TBD. 787 5.3. CSR Template Registry 789 TODO 791 6. Security Considerations 793 6.1. Restricting CDNs to the Delegation Mechanism 795 When a web site is delegated to a CDN, the CDN can in principle 796 modify the web site at will, create and remove pages. This means 797 that a malicious or breached CDN can pass the ACME (as well as common 798 non-ACME) HTTPS-based validation challenges and generate a 799 certificate for the site. This is true regardless of whether the 800 CNAME mechanisms defined in the current document is used or not. 802 In some cases, this is the desired behavior: the domain owner trusts 803 the CDN to have full control of the cryptographic credentials for the 804 site. The current document however assumes that the domain owner 805 only wants to delegate restricted control, and wishes to retain the 806 capability to cancel the CDN's credentials at a short notice. 808 Following is the proposed solution where the IdO wishes to ensure 809 that a rogue CDN cannot issue unauthorized certificates: 811 * The domain owner makes sure that the CDN cannot modify the DNS 812 records for the domain. The domain owner should ensure it is the 813 only entity authorized to modify the DNS zone. Typically, it 814 establishes a CNAME resource record from a subdomain into a CDN- 815 managed domain. 816 * The domain owner uses a CAA record [RFC6844] to restrict 817 certificate issuance for the domain to specific CAs that comply 818 with ACME and are known to implement [RFC8657]. 819 * The domain owner uses the ACME-specific CAA mechanism [RFC8657] to 820 restrict issuance to a specific account key which is controlled by 821 it, and MUST require "dns-01" as the sole validation method. 823 We note that the above solution may need to be tweaked depending on 824 the exact capabilities and authorisation flows supported by the 825 selected CAs. 827 6.2. TBC 829 * CSR validation 830 * CNAME mappings 831 * Composition with ACME STAR 832 * Composition with other ACME extensions 833 * Channel security 835 7. Acknowledgments 837 This work is partially supported by the European Commission under 838 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 839 for a Middleboxed Internet (MAMI). This support does not imply 840 endorsement. 842 8. References 844 8.1. Normative References 846 [I-D.handrews-json-schema] 847 Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON 848 Schema: A Media Type for Describing JSON Documents", Work 849 in Progress, Internet-Draft, draft-handrews-json-schema- 850 02, 17 September 2019, 851 . 854 [I-D.ietf-acme-star] 855 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 856 Fossati, "Support for Short-Term, Automatically-Renewed 857 (STAR) Certificates in Automated Certificate Management 858 Environment (ACME)", Work in Progress, Internet-Draft, 859 draft-ietf-acme-star-11, 24 October 2019, 860 . 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, 865 DOI 10.17487/RFC2119, March 1997, 866 . 868 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 869 Authority Authorization (CAA) Resource Record", RFC 6844, 870 DOI 10.17487/RFC6844, January 2013, 871 . 873 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 874 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 875 May 2017, . 877 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 878 Kasten, "Automatic Certificate Management Environment 879 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 880 . 882 [RFC8657] Landau, H., "Certification Authority Authorization (CAA) 883 Record Extensions for Account URI and Automatic 884 Certificate Management Environment (ACME) Method Binding", 885 RFC 8657, DOI 10.17487/RFC8657, November 2019, 886 . 888 8.2. Informative References 890 [I-D.ietf-acme-authority-token-tnauthlist] 891 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 892 "TNAuthList profile of ACME Authority Token", Work in 893 Progress, Internet-Draft, draft-ietf-acme-authority-token- 894 tnauthlist-05, 4 November 2019, 895 . 898 [I-D.ietf-cdni-interfaces-https-delegation] 899 Fieau, F., Emile, S., and S. Mishra, "CDNI extensions for 900 HTTPS delegation", Work in Progress, Internet-Draft, 901 draft-ietf-cdni-interfaces-https-delegation-02, 4 November 902 2019, 903 . 906 [I-D.ietf-stir-cert-delegation] 907 Peterson, J., "STIR Certificate Delegation", Work in 908 Progress, Internet-Draft, draft-ietf-stir-cert-delegation- 909 01, 4 November 2019, 910 . 913 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 914 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 915 . 917 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 918 Credentials: Certificates", RFC 8226, 919 DOI 10.17487/RFC8226, February 2018, 920 . 922 Appendix A. Document History 924 [[Note to RFC Editor: please remove before publication.]] 926 A.1. draft-ietf-acme-star-delegation-03 928 * Consistency with the latest changes in the base ACME STAR 929 document, e.g. star-delegation-enabled capability renamed and 930 moved. 931 * Proxy use cases (recursive delegation) and the definition of proxy 932 behavior. 933 * More detailed analysis of the CDNI and STIR use cases, including 934 sequence diagrams. 936 A.2. draft-ietf-acme-star-delegation-02 938 * Security considerations: review by Ryan Sleevi. 939 * CSR template simplified: instead of being a JSON Schema document 940 itself, it is now a simple JSON document which validates to a JSON 941 Schema. 943 A.3. draft-ietf-acme-star-delegation-01 945 * Refinement of the CDNI use case. 946 * Addition of the CSR template (partial, more work required). 947 * Further security considerations (work in progress). 949 A.4. draft-ietf-acme-star-delegation-00 951 * Republished as a working group draft. 953 A.5. draft-sheffer-acme-star-delegation-01 955 * Added security considerations about disallowing CDNs from issuing 956 certificates for a delegated domain. 958 A.6. draft-sheffer-acme-star-delegation-00 960 * Initial version, some text extracted from draft-sheffer-acme-star- 961 requests-02 963 Appendix B. CSR Template Schema 965 Following is a JSON Schema definition of the CSR template. The 966 syntax used is that of draft 7 of JSON Schema, which may not be the 967 latest version of the corresponding Internet Draft 968 [I-D.handrews-json-schema] at the time of publication. 970 While the CSR template must follow the syntax defined here, neither 971 the IdO nor the NDC are expected to validate it at run-time. 973 { 974 "title": "JSON Schema for the STAR Delegation CSR template", 975 "$schema": "http://json-schema.org/draft-07/schema#", 976 "$id": "http://ietf.org/acme/drafts/star-delegation/csr-template", 977 "$def": { 978 "distinguished-name": { 979 "$id": "#distinguished-name", 980 "type": "object", 981 "properties": { 982 "country": { 983 "type": "string" 984 }, 985 "stateOrProvince": { 986 "type": "string" 987 }, 988 "locality": { 989 "type": "string" 990 }, 991 "organization": { 992 "type": "string" 993 }, 994 "organizationalUnit": { 995 "type": "string" 996 }, 997 "emailAddress": { 998 "type": "string" 999 }, 1000 "commonName": { 1001 "type": "string" 1002 } 1003 }, 1004 "additionalProperties": false 1005 }, 1006 "rsaKeyType": { 1007 "$id": "#rsaKeyType", 1008 "type": "object", 1009 "properties": { 1010 "PublicKeyType": { 1011 "type": "string", 1012 "const": "RSA" 1013 }, 1014 "PublicKeyLength": { 1015 "type": "integer" 1016 }, 1017 "SignatureType": { 1018 "type": "string", 1019 "enum": [ 1020 "sha256WithRSAEncryption" 1021 ] 1022 } 1023 }, 1024 "additionalProperties": false 1025 }, 1026 "ecKeyTYpe": { 1027 "$id": "#ecKeyType", 1028 "type": "object", 1029 "properties": { 1030 "PublicKeyType": { 1031 "type": "string", 1032 "const": "ecPublicKey" 1033 }, 1034 "Curve": { 1035 "type": "string", 1036 "enum": [ 1037 "secp521r1" 1038 ] 1039 }, 1040 "SignatureType": { 1041 "type": "string", 1042 "enum": [ 1043 "ecdsa-with-SHA256" 1044 ] 1045 } 1046 }, 1047 "additionalProperties": false 1048 } 1049 }, 1050 "type": "object", 1051 "properties": { 1052 "keyTypes": { 1053 "type": "array", 1054 "items": { 1055 "oneOf": [ 1056 { 1057 "$ref": "#rsaKeyType" 1058 }, 1059 { 1060 "$ref": "#ecKeyType" 1061 } 1062 ] 1063 } 1064 }, 1065 "subject": { 1066 "$ref": "#distinguished-name" 1067 }, 1068 "extensions": { 1069 "type": "object", 1070 "properties": { 1071 "keyUsage": { 1072 "type": "array", 1073 "items": { 1074 "type": "string", 1075 "enum": [ 1076 "digitalSignature", 1077 "nonRepudiation", 1078 "keyEncipherment", 1079 "dataEncipherment", 1080 "keyAgreement", 1081 "keyCertSign", 1082 "cRLSign", 1083 "encipherOnly", 1084 "decipherOnly" 1085 ] 1086 } 1087 }, 1088 "extendedKeyUsage": { 1089 "type": "array", 1090 "items": { 1091 "type": "string", 1092 "enum": [ 1093 "serverAuth", 1094 "clientAuth", 1095 "codeSigning", 1096 "emailProtection", 1097 "timeStamping", 1098 "OCSPSigning" 1099 ] 1100 } 1101 }, 1102 "subjectAltName": { 1103 "type": "object", 1104 "properties": { 1105 "DNS": { 1106 "type": "array", 1107 "items": { 1108 "type": "string", 1109 "format": "hostname" 1110 } 1111 }, 1112 "IP": { 1113 "type": "array", 1114 "items": { 1115 "oneOf": [ 1116 { 1117 "type": "string", 1118 "format": "ipv4" 1119 }, 1120 { 1121 "type": "string", 1122 "format": "ipv6" 1123 } 1124 ] 1125 } 1126 }, 1127 "Email": { 1128 "type": "array", 1129 "items": { 1130 "type": "string", 1131 "format": "email" 1132 } 1133 } 1134 }, 1135 "additionalProperties": false 1136 } 1137 }, 1138 "additionalProperties": false 1139 } 1140 }, 1141 "additionalProperties": false 1142 } 1144 Authors' Addresses 1146 Yaron Sheffer 1147 Intuit 1149 Email: yaronf.ietf@gmail.com 1151 Diego Lopez 1152 Telefonica I+D 1153 Email: diego.r.lopez@telefonica.com 1155 Antonio Agustin Pastor Perales 1156 Telefonica I+D 1158 Email: antonio.pastorperales@telefonica.com 1160 Thomas Fossati 1161 ARM 1163 Email: thomas.fossati@arm.com