idnits 2.17.1 draft-ietf-acme-star-delegation-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 : ---------------------------------------------------------------------------- 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 (December 13, 2018) is 1954 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) == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-16 == Outdated reference: A later version (-10) exists of draft-ietf-acme-caa-05 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-04 ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: June 16, 2019 A. Pastor Perales 6 Telefonica I+D 7 T. Fossati 8 Nokia 9 December 13, 2018 11 An ACME Profile for Generating Delegated STAR Certificates 12 draft-ietf-acme-star-delegation-00 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 June 16, 2019. 44 Copyright Notice 46 Copyright (c) 2018 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Conventions used in this document . . . . . . . . . . . . 4 64 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 6 68 2.3.1. Order Object on the NDC-IdO side . . . . . . . . . . 6 69 2.3.2. Order Object on the IdO-CA side . . . . . . . . . . . 9 70 2.3.3. Capability Discovery . . . . . . . . . . . . . . . . 9 71 2.3.4. On Cancelation . . . . . . . . . . . . . . . . . . . 9 72 3. CDNI Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1. Multiple Parallel Delegates . . . . . . . . . . . . . . . 9 74 3.2. Chained Delegation . . . . . . . . . . . . . . . . . . . 10 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 4.1. New fields in the "meta" Object within a Directory Object 10 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 5.1. Restricting CDNs to the Delegation Mechanism . . . . . . 10 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 7.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 84 A.1. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 13 85 A.2. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 13 86 A.3. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 This document is a companion document to [I-D.ietf-acme-star]. To 92 avoid duplication, we give here a bare-bones description of the 93 motivation for this solution. For more details and further use 94 cases, please refer to the introductory sections of 95 [I-D.ietf-acme-star]. 97 An Identifier Owner (IdO), that we can associate in the primary use 98 case to a content provider (also referred to as Domain Name Owner, 99 DNO), has agreements in place with one or more NDC (Name Delegation 100 Consumer) to use and attest its identity. In the primary use case, 101 we consider a CDN provider contracted to serve the IdO content over 102 HTTPS. The CDN terminates the HTTPS connection at one of its edge 103 cache servers and needs to present its clients (browsers, mobile 104 apps, set-top-boxes) a certificate whose name matches the authority 105 of the URL that is requested, i.e., that of the IdO. Understandably, 106 most IdOs balk at sharing their long-term private keys with another 107 organization and, equally, delegates would rather not have to handle 108 other parties' long-term secrets. 110 This document describes a profile of the ACME protocol 111 [I-D.ietf-acme-acme] that allows the NDC to request the IdO, acting 112 as a profiled ACME server, a certificate for a delegated identity - 113 i.e., one belonging to the IdO. The IdO then uses the ACME protocol 114 (with the extensions described in [I-D.ietf-acme-star]) to request 115 issuance of a STAR certificate for the same delegated identity. The 116 generated short-term certificate is automatically renewed by the ACME 117 Certification Authority (CA), periodically fetched by the NDC and 118 used to terminate HTTPS connections in lieu of the IdO. The IdO can 119 end the delegation at any time by simply instructing the CA to stop 120 the automatic renewal and letting the certificate expire shortly 121 thereafter. 123 In case the delegated identity is a domain name, this document also 124 provides a way for the NDC to inform the IdO about the CNAME mappings 125 that need to be installed in the IdO's DNS zone to enable the 126 aliasing of the delegated name, thus allowing the complete name 127 delegation workflow to be handled using a single interface. 129 1.1. Terminology 131 IdO Identifier Owner, the owner of an identifier (e.g., a domain 132 name) that needs to be delegated. 133 DNO Domain Name Owner, a specific kind of IdO whose identifier is a 134 domain name 135 NDC Name Delegation Consumer, the entity to which the domain name is 136 delegated for a limited time. This is a CDN in the primary use 137 case (in fact, readers may note the symmetry of the two acronyms). 138 CDN Content Delivery Network, a widely distributed network that 139 serves the domain's web content to a wide audience at high 140 performance. 141 STAR Short-Term, Automatically Renewed X.509 certificates. 142 ACME The IETF Automated Certificate Management Environment, a 143 certificate management protocol. 144 CA A Certificate Authority that implements the ACME protocol. 146 1.2. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in 151 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 2. Protocol Flow 156 This section presents the protocol flow. For completeness, we 157 include the ACME profile proposed in this draft as well as the 158 extended ACME protocol described in [I-D.ietf-acme-star]. 160 2.1. Preconditions 162 The protocol assumes the following preconditions are met: 164 o The IdO exposes an ACME server interface to the NDC(s) comprising 165 the account management interface; 166 o The NDC has registered an ACME account with the IdO; 167 o NDC and IdO have agreed on a "CSR template" to use, including at a 168 minimum: subject name (e.g., "somesite.example.com"), requested 169 algorithms, key length, key usage. The NDC is required to use 170 this template for every CSR created under the same delegation; 171 o IdO has registered an ACME account with the Certificate Authority 172 (CA) 174 Note that even if the IdO implements the ACME server role, it is not 175 acting as a CA: in fact, from the point of view of the certificate 176 issuance process, the IdO only works as a "policing" forwarder of the 177 NDC's key-pair and is responsible for completing the identity 178 verification process towards the ACME CA. 180 2.2. Overview 182 The interaction between the NDC and the IdO is governed by the 183 profiled ACME workflow detailed in Section 2.3. The interaction 184 between the IdO and the CA is ruled by ACME STAR 185 [I-D.ietf-acme-star]. 187 The outline of the combined protocol is as follow (Figure 1): 189 o NDC sends an Order for the delegated identifier to IdO; 190 o IdO creates an Order resource in state "ready" with a "finalize" 191 URL; 192 o NDC immediately sends a finalize request (which includes the CSR) 193 to the IdO; 195 o IdO verifies the CSR according to the agreed CSR template; 196 o If the CSR verification fails, the Order is moved to an "invalid" 197 state and everything stops; 198 o If the CSR verification is successful, IdO moves the Order to 199 state "processing", and sends an Order' (using its own account) 200 for the delegated identifier to the ACME STAR CA; 201 o If the ACME STAR protocol fails, Order' moves to "invalid" and the 202 same state is reflected in the NDC Order; 203 o If the ACME STAR run is successful (i.e., Order' is "valid"), IdO 204 copies the "star-certificate" URL from Order' to Order and moves 205 its state "valid". 207 The NDC can now download, install and use the certificate bearing the 208 name delegated by the IdO. 210 Note that, because the identity validation is suppressed, the NDC 211 sends the finalize request, including the CSR, to the IdO immediately 212 after the Order has been acknowledged. The IdO must buffer a (valid) 213 CSR until the Validation phase completes successfully. 215 NDC IdO CA 216 Client Server Client Server 218 Order 219 Signature -------> 221 [ No identity validation ] 223 CSR 224 Signature -------> 226 Order' 227 Signature -------> 228 <------- Required 229 Authorizations 231 Responses 232 Signature -------> 234 <~~~~~~~~Validation~~~~~~~~> 236 CSR 237 Signature -------> 239 <~~~~~~Await issuance~~~~~~> <~~~~~~Await issuance~~~~~~> 241 <------------------------------------ Certificate 243 Figure 1: End to end flow 245 2.3. Delegated Identity Profile 247 2.3.1. Order Object on the NDC-IdO side 249 The Order object created by the NDC: 251 o MUST contain identifiers with the new "delegated" field set to 252 true; 253 o MUST NOT contain the notBefore and notAfter fields; 254 o MAY contain any of the "recurrent-*" fields listed in 255 Section 3.1.1 of [I-D.ietf-acme-star]; 256 o In case the identifier type is "dns", it MAY contain a "cname" 257 field with the alias of the identifier in the NDC domain. This 258 field is used by the IdO to create the DNS aliasing needed to 259 redirect the resolvers to the delegated entity. 261 POST /acme/new-order HTTP/1.1 262 Host: acme.dno.example 263 Content-Type: application/jose+json 265 { 266 "protected": base64url({ 267 "alg": "ES256", 268 "kid": "https://acme.dno.example/acme/acct/evOfKhNU60wg", 269 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 270 "url": "https://acme.dno.example/acme/new-order" 271 }), 272 "payload": base64url({ 273 "identifiers": [ 274 { 275 "type": "dns", 276 "value": "abc.ndc.dno.example.", 277 "delegated": true, 278 "cname": "abc.ndc.example." 279 } 280 ], 281 }), 282 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 283 } 285 The Order object that is created on the IdO: 287 o MUST start in the "ready" state; 288 o MUST contain an "authorizations" array with zero elements; 289 o MUST NOT contain the "notBefore" and "notAfter" fields. 291 { 292 "status": "ready", 293 "expires": "2016-01-01T00:00:00Z", 295 "identifiers": [ 296 { 297 "type": "dns", 298 "value": "abc.ndc.dno.example.", 299 "delegated": true, 300 "cname": "abc.ndc.example." 301 } 302 ], 304 "authorizations": [], 306 "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize" 307 } 309 The IdO SHOULD copy any "recurrent-*" field from the NDC request into 310 the related STAR request to the ACME CA. 312 When the validation of the identifiers has been successfully 313 completed and the certificate has been issued by the CA, the IdO: 315 o MUST move its Order resource status to "valid"; 316 o MUST copy the "star-certificate" field from the STAR Order; 318 The latter indirectly includes (via the NotBefore and NotAfter HTTP 319 headers) the renewal timers needed by the NDC to inform its 320 certificate reload logic. 322 { 323 "status": "valid", 324 "expires": "2016-01-01T00:00:00Z", 326 "identifiers": [ 327 { 328 "type": "dns", 329 "value": "abc.ndc.dno.example.", 330 "delegated": true, 331 "cname": "abc.ndc.example." 332 } 333 ], 335 "authorizations": [], 337 "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize", 339 "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" 340 } 342 If an "identifier" object of type "dns" was included, the IdO MUST 343 validate the specified CNAME at this point in the flow. The NDC and 344 IdO may have a pre-established list of valid CNAME values. At the 345 minimum, the IdO MUST verify that both DNS names are syntactically 346 valid. 348 Following this validation, the IdO can add the CNAME records to its 349 zone: 351 abc.ndc.dno.example. CNAME abc.ndc.example. 353 2.3.2. Order Object on the IdO-CA side 355 When sending the Order to the ACME CA, the IdO SHOULD strip the 356 "delegated" and "cname" attributes sent by the NDC (Section 2.3.1). 357 The IdO MUST add the necessary STAR extensions to the Order. In 358 addition, to allow the NDC to download the certificate using 359 unauthenticated GET, the IdO MUST add the recurrent-certificate-get 360 attribute and set it to true. 362 2.3.3. Capability Discovery 364 In order to help a client to discover support for this profile, the 365 directory object of an ACME server MUST contain the following 366 attribute inside the "meta" field: 368 o star-delegation-enabled: boolean flag indicating support for the 369 profile specified in this memo. An ACME server that supports this 370 delegation profile MUST include this key, and MUST set it to true. 372 2.3.4. On Cancelation 374 It is worth noting that cancelation of the ACME STAR certificate is a 375 prerogative of the IdO. The NDC does not own the relevant account 376 key on the ACME CA, therefore it can't issue a cancelation request 377 for the STAR cert. Potentially, since it holds the STAR cert private 378 key, it could request the revocation of a single STAR certificate. 379 However, STAR explicitly disables the revokeCert interface. 381 3. CDNI Use Cases 383 Members of the IETF CDNI (Content Delivery Network Interconnection) 384 working group are interested in delegating authority over web content 385 to CDNs. Their requirements are described in a draft 386 [I-D.fieau-cdni-https-delegation] that considers several solutions 387 addressing different delegation requirements. This section discusses 388 two of these particular requirements in the context of the STAR 389 delegation workflow. 391 3.1. Multiple Parallel Delegates 393 In some cases the content owner (IdO) would like to delegate 394 authority over a web site to multiple NDCs (CDNs). This could happen 395 if the IdO has agreements in place with different regional CDNs for 396 different geographical regions, or if a "backup" CDN is used to 397 handle overflow traffic by temporarily altering some of the CNAME 398 mappings in place. The STAR delegation flow enables this use case 399 naturally, since each CDN can authenticate separately to the IdO (via 400 its own separate account) specifying its CSR, and the IdO is free to 401 allow or deny each certificate request according to its own policy. 403 3.2. Chained Delegation 405 In other cases, a content owner (IdO) delegates some domains to a 406 large CDN (uCDN), which in turn delegates to a smaller regional CDN, 407 dCDN. The DNO has a contractual relationship with uCDN, and uCDN has 408 a similar relationship with dCDN. However IdO may not even know 409 about dCDN. 411 The STAR protocol does not prevent this use case, although there is 412 no special support for it: uCDN could forward requests from dCDN to 413 DNO, and forward responses back to dCDN. Whether such proxying is 414 allowed is governed by policy and contracts between the parties. 416 One thing that might be necessary at the interface between uCDN and 417 dCDN is a mechanism by which the uCDN can advertise: 419 o The namespace that is made available to the dCDN to mint its 420 delegated names; 421 o The policy for creating the key material (allowed algorithms, 422 minimum key lengths, key usage, etc.) that the dCDN needs to 423 satisfy. 425 4. IANA Considerations 427 [[RFC Editor: please replace XXXX below by the RFC number.]] 429 4.1. New fields in the "meta" Object within a Directory Object 431 This document adds the following entries to the ACME Directory 432 Metadata Fields: 434 +-------------------------+------------+-----------+ 435 | Field Name | Field Type | Reference | 436 +-------------------------+------------+-----------+ 437 | star-delegation-enabled | boolean | RFC XXXX | 438 +-------------------------+------------+-----------+ 440 5. Security Considerations 442 5.1. Restricting CDNs to the Delegation Mechanism 444 When a web site is delegated to a CDN, the CDN can in principle 445 modify the web site at will, create and remove pages. This means 446 that a malicious or breached CDN can pass the ACME (as well as common 447 non-ACME) HTTPS-based validation challenges and generate a 448 certificate for the site. This is true regardless of whether the 449 CNAME mechanisms defined in the current document is used or not. 451 In some cases, this is the desired behavior: the domain owner trusts 452 the CDN to have full control of the cryptographic credentials for the 453 site. The current document however assumes that the domain owner 454 only wants to delegate restricted control, and wishes to retain the 455 capability to cancel the CDN's credentials at a short notice. 457 To restrict certificate delegation only to the protocol defined here: 459 o The domain owner MUST make sure that the CDN cannot modify the DNS 460 records for the domain. The domain owner should ensure it is the 461 only entity authorized to modify the DNS zone. Typically, it 462 establishes a CNAME resource record from a subdomain into a CDN- 463 managed domain. 464 o The domain owner MUST use a CAA record [RFC6844] to restrict 465 certificate issuance for the domain to specific CAs that comply 466 with ACME. 467 o The domain owner MUST use the ACME-specific CAA mechanism 468 [I-D.ietf-acme-caa] to restrict issuance to a specific account key 469 which is controlled by it, and MUST require "dns-01" as the sole 470 validation method. 472 6. Acknowledgments 474 This work is partially supported by the European Commission under 475 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 476 for a Middleboxed Internet (MAMI). This support does not imply 477 endorsement. 479 7. References 481 7.1. Normative References 483 [I-D.ietf-acme-acme] 484 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 485 Kasten, "Automatic Certificate Management Environment 486 (ACME)", draft-ietf-acme-acme-16 (work in progress), 487 October 2018. 489 [I-D.ietf-acme-caa] 490 Landau, H., "CAA Record Extensions for Account URI and 491 ACME Method Binding", draft-ietf-acme-caa-05 (work in 492 progress), June 2018. 494 [I-D.ietf-acme-star] 495 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 496 Fossati, "Support for Short-Term, Automatically-Renewed 497 (STAR) Certificates in Automated Certificate Management 498 Environment (ACME)", draft-ietf-acme-star-04 (work in 499 progress), October 2018. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 507 Authority Authorization (CAA) Resource Record", RFC 6844, 508 DOI 10.17487/RFC6844, January 2013, 509 . 511 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 512 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 513 May 2017, . 515 7.2. Informative References 517 [I-D.fieau-cdni-https-delegation] 518 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 519 CDNI", draft-fieau-cdni-https-delegation-02 (work in 520 progress), July 2017. 522 Appendix A. Document History 524 [[Note to RFC Editor: please remove before publication.]] 526 A.1. draft-ietf-acme-star-delegation-00 528 o Republished as a working group draft. 530 A.2. draft-sheffer-acme-star-delegation-01 532 o Added security considerations about disallowing CDNs from issuing 533 certificates for a delegated domain. 535 A.3. draft-sheffer-acme-star-delegation-00 537 o Initial version, some text extracted from draft-sheffer-acme-star- 538 requests-02 540 Authors' Addresses 542 Yaron Sheffer 543 Intuit 545 EMail: yaronf.ietf@gmail.com 547 Diego Lopez 548 Telefonica I+D 550 EMail: diego.r.lopez@telefonica.com 552 Antonio Agustin Pastor Perales 553 Telefonica I+D 555 EMail: antonio.pastorperales@telefonica.com 557 Thomas Fossati 558 Nokia 560 EMail: thomas.fossati@nokia.com