idnits 2.17.1 draft-ietf-acme-star-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2017) is 2505 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-06 == Outdated reference: A later version (-10) exists of draft-ietf-acme-caa-01 -- Obsolete informational reference (is this intentional?): RFC 6844 (Obsoleted by RFC 8659) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Standards Track D. Lopez 5 Expires: December 18, 2017 O. Gonzalez de Dios 6 A. Pastor Perales 7 Telefonica I+D 8 T. Fossati 9 Nokia 10 June 16, 2017 12 Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate 13 Authority over Web Sites 14 draft-ietf-acme-star-00 16 Abstract 18 This memo proposes an ACME extension to enable the issuance of short- 19 term and automatically renewed certificates. This allows a domain 20 name owner to delegate the use of certificates to another party, 21 while retaining the capability to cancel this delegation at any time 22 with no need to rely on certificate revocation mechanisms. 24 [RFC Editor: please remove before publication] 26 While the draft is being developed, the editor's version can be found 27 at https://github.com/yaronf/I-D/tree/master/STAR. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 18, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction: A Solution for the HTTPS CDN Use Case . . . . . 3 64 1.1. Cloud Use Case . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Conventions used in this document . . . . . . . . . . . . 4 67 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. ACME Extensions between Proxy and Server . . . . . . . . 7 73 3.1.1. Extending the Order Resource . . . . . . . . . . . . 7 74 3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 8 75 3.2. Indicating Support of Recurrent Orders . . . . . . . . . 8 76 3.3. ACME Authorization . . . . . . . . . . . . . . . . . . . 8 77 3.4. Fetching the Certificates . . . . . . . . . . . . . . . . 9 78 4. Operational Considerations . . . . . . . . . . . . . . . . . 9 79 4.1. Certificate Transparency (CT) Logs . . . . . . . . . . . 9 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 5.1. Restricting CDNs to the Delegation Mechanism . . . . . . 9 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 7.2. Informative References . . . . . . . . . . . . . . . . . 10 86 Appendix A. Document History . . . . . . . . . . . . . . . . . . 12 87 A.1. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 12 88 A.2. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 12 89 A.3. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 12 90 A.4. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 12 91 A.5. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction: A Solution for the HTTPS CDN Use Case 96 A content provider (referred to in this document as Domain Name 97 Owner, DNO) has agreements in place with one or more Content Delivery 98 Networks (CDNs) that are contracted to serve its content over HTTPS. 99 The CDN terminates the HTTPS connection at one of its edge cache 100 servers and needs to present its clients (browsers, set-top-boxes) a 101 certificate whose name matches the authority of the URL that is 102 requested, i.e. that of the DNO. However, many DNOs balk at sharing 103 their long-term private keys with another organization and, equally, 104 CDN providers would rather not have to handle other parties' long- 105 term secrets. This problem has been discussed at the IETF under the 106 LURK (limited use of remote keys) title. 108 This document proposes a solution to the above problem that involves 109 the use of short-term certificates with a DNO's name on them, and a 110 scheme for handling the naming delegation from the DNO to the CDN. 111 The generated short-term credentials are automatically renewed by an 112 ACME Certification Authority (CA) [I-D.ietf-acme-acme] and routinely 113 rotated by the CDN on its edge cache servers. The DNO can end the 114 delegation at any time by simply instructing the CA to stop the 115 automatic renewal and let the certificate expire shortly thereafter. 117 Using short-term certificates makes revocation cheap and effective 118 [Topalovic] [I-D.iab-web-pki-problems] in case of key compromise or 119 of termination of the delegation; seamless certificate issuance and 120 renewal enable the level of workflow automation that is expected in 121 today's cloud environments. Also, compared to other keyless-TLS 122 solutions [I-D.cairns-tls-session-key-interface] 123 [I-D.erb-lurk-rsalg], the proposed approach doesn't suffer from 124 scalability issues or increase in connection setup latency, while 125 requiring virtually no changes to existing COTS caching software used 126 by the CDN. 128 This document describes the ACME extension. A companion document [I- 129 D.sheffer-acme-star-request] describes how the CDN can request the 130 DNO to initiate the protocol with the ACME server. 132 1.1. Cloud Use Case 134 A similar use case is that of cloud infrastructure components, such 135 as load balancers and Web Application Firewalls (WAF). These 136 components are typically provisioned with the DNO's certificate, and 137 similarly to the CDN use case, many organizations would prefer to 138 manage the private key only on their own cloud-based or on-premise 139 hosts, often on Hardware Security Modules (HSMs). 141 Here again, the STAR solution allows the DNO to delegate authority 142 over the domain to the cloud provider, with the ability to revoke 143 this authority at any time. 145 1.2. Terminology 147 DNO Domain Name Owner, the owner of a domain that needs to be 148 delegated. 149 NDC Name Delegation Consumer, the entity to which the domain name is 150 delegated for a limited time. This is often a CDN (in fact, 151 readers may note the similarity of the two acronyms). 152 CDN Content Delivery Network, a widely distributed network that 153 serves the domain's web content to a wide audience at high 154 performance. 155 STAR Short-Term, Automatically Renewed X.509 certificates. 156 ACME The IETF Automated Certificate Management Environment, a 157 certificate management protocol. 158 CA A Certificate Authority that implements the ACME protocol. 160 1.3. Conventions used in this document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in 165 [RFC2119]. 167 2. Protocol Flow 169 For clarity, we describe how the proposed ACME extension can be used 170 in a system that consists of an NDC, an ACME Client (the DNO) and an 171 ACME Server. Only the latter part (ACME Client to ACME Server) is in 172 scope of this document. 174 The protocol flow can be split into two: a STAR interface, used by 175 NDC and DNO to agree on the name delegation, and the extended ACME 176 interface, used by DNO to obtain the short-term and automatically 177 renewed certificate from the CA, which is eventually consumed by the 178 NDC. The latter is also used to terminate the delegation, if so 179 needed. 181 Communication between the NDC and the DNO (the STAR interface) is out 182 of scope of this document. It may take the form described in [I- 183 D.sheffer-acme-star-request], some other online protocol, or may even 184 be through manual generation of the CSR. 186 The following subsections describe the three main phases of the 187 protocol: 189 o Bootstrap: the DNO asks an ACME CA to create a corresponding 190 short-term and auto-renewed (STAR) certificate, possibly on a 191 request from an NDC which is out of scope for this document; 192 o Auto-renewal: the ACME CA periodically re-issues the short-term 193 certificate and posts it to a public URL (Section 2.2); 194 o Termination: the DNO (indirectly) stops name delegation by 195 explicitly requesting the ACME CA to discontinue the automatic 196 renewal of the certificate (Section 2.3). 198 This diagram presents the entities involved in the protocol and their 199 interactions during the different phases. 201 +-----------------+ 202 | STAR Proxy | 203 | (DNO) | 204 Bootstrap +-----------------+ Bootstrap 205 +---------->+ STAR | ACME +-----------+ 206 | | Server | Client | Terminate | 207 | +--------+--------+ | 208 | v 209 +--------+ +--------+ 210 | STAR | Refresh | ACME | 211 | Client +------------------------------->| Server | 212 | (NDC) | | (CA) | 213 +--------+ +--------+ 215 2.1. Bootstrap 217 The DNO, in its role as an ACME client, requests the CA to issue a 218 STAR certificate, i.e., one that: 220 o Has a short validity (e.g., 24 to 72 hours); 221 o Is automatically renewed by the CA for a certain period of time; 222 o Is downloadable from a (highly available) public link without 223 requiring any special authorization. 225 Other than that, the ACME protocol flows as normal between DNO and 226 CA, in particular DNO is responsible for satisfying the requested 227 ACME challenges until the CA is willing to issue the requested 228 certificate. Per normal ACME processing, the DNO is given back an 229 Order ID for the issued STAR certificate to be used in subsequent 230 interaction with the CA (e.g., if the certificate needs to be 231 terminated.) 233 The bootstrap phase ends when the DNO obtains the OK from the ACME 234 CA. 236 2.2. Refresh 238 The CA automatically re-issues the certificate (using the same CSR) 239 before it expires and publishes it to the URL that the NDC has come 240 to know at the end of the bootstrap phase. The NDC downloads and 241 installs it. This process goes on until either: 243 o DNO terminates the delegation, or 244 o Automatic renewal expires. 246 STAR ACME/STAR 247 Client Server 248 | Retrieve cert | [...] 249 |<--------------------->| | 250 | +------. / 251 | | | / 252 | | Automatic renewal : 253 | | | \ 254 | |<-----' \ 255 | Retrieve cert | | 256 |<--------------------->| 72 hours 257 | | | 258 | +------. / 259 | | | / 260 | | Automatic renewal : 261 | | | \ 262 | |<-----' \ 263 | Retrieve cert | | 264 |<--------------------->| 72 hours 265 | | | 266 | +------. / 267 | | | / 268 | | Automatic renewal : 269 | | | \ 270 | |<-----' \ 271 | | | 272 | [...] | [...] 274 Figure 1: Auto renewal 276 2.3. Termination 278 The DNO may request early termination of the STAR certificate by 279 including the Order ID in a certificate termination request to the 280 ACME interface, defined below. After the CA receives and verifies 281 the request, it shall: 283 o Cancel the automatic renewal process for the STAR certificate; 284 o Change the certificate publication resource to return an error 285 indicating the termination of the delegation to external clients, 286 including the NDC. 288 Note that it is not necessary to explicitly revoke the short-term 289 certificate. 291 STAR STAR ACME/STAR 292 Client Proxy Server 293 | | | 294 | | Terminate Order ID | 295 | +---------------------->| 296 | | +-------. 297 | | | | 298 | | | End auto renewal 299 | | | Remove cert link 300 | | | etc. 301 | | | | 302 | | Done |<------' 303 | |<----------------------+ 304 | | | 305 | | 306 | Retrieve cert | 307 +---------------------------------------------->| 308 | Error: terminated | 309 |<----------------------------------------------+ 310 | | 312 Figure 2: Termination 314 3. Protocol Details 316 This section describes the protocol's details, namely the extensions 317 to the ACME protocol required to issue STAR certificates. 319 3.1. ACME Extensions between Proxy and Server 321 This protocol extends the ACME protocol, to allow for recurrent 322 orders. 324 3.1.1. Extending the Order Resource 326 The Order resource is extended with the following attributes: 328 { 329 "recurrent": true, 330 "recurrent-total-lifetime": 365, // requested lifetime of the 331 // recurrent registration, in days 332 "recurrent-certificate-validity": 7 333 // requested validity of each certificate, in days 334 } 336 These attributes are included in a POST message when creating the 337 order, as part of the "payload" encoded object. They are returned 338 when the order has been created, and the ACME server MAY adjust them 339 at will, according to its local policy. 341 3.1.2. Canceling a Recurrent Order 343 An important property of the recurrent Order is that it can be 344 cancelled by the domain name owner, with no need for certificate 345 revocation. We use the DELETE message to cancel the Order: 347 DELETE /acme/order/1 HTTP/1.1 348 Host: acme-server.example.org 350 Which returns: 352 HTTP/1.1 202 Deleted 354 The server MUST NOT issue any additional certificates for this Order, 355 beyond the certificate that is available for collection at the time 356 of deletion. 358 3.2. Indicating Support of Recurrent Orders 360 ACME supports sending arbitrary extensions when creating an Order, 361 and as a result, there is no need to explicitly indicate support of 362 this extension. The Proxy MUST verify that the "recurrent" attribute 363 was understood, as indicated by the "recurrent" attribute included in 364 the created Order. Since the standard ACME protocol does not allow 365 to explicitly cancel a pending Order (the DELETE operation above is 366 an extension), a Proxy that encounters an non-supporting server will 367 probably let the Order expire instead of following through with the 368 authorization process. 370 3.3. ACME Authorization 372 The DNO MUST restrict the authorizations it requests from the ACME 373 server to only those that cannot be spoofed by a malicious NDC. In 374 most cases the NDC will have strong control of HTTP content under the 375 delegated domain, and therefore HTTPS-based authorization MUST NOT be 376 used. See also Section 5.1. 378 3.4. Fetching the Certificates 380 The certificate is fetched from the certificate endpoint, as per 381 [I-D.ietf-acme-acme], Sec. 7.4.2 "Downloading the Certificate". The 382 server MUST include an Expires header that indicates expiry of the 383 specific certificate. When the certificate expires, the client MAY 384 assume that a newer certificate is already in place. 386 A certificate MUST be replaced by its successor at the latest halfway 387 through its lifetime (the period between its notBefore and notAfter 388 times). 390 4. Operational Considerations 392 4.1. Certificate Transparency (CT) Logs 394 TBD: larger logs and how to deal with them. 396 5. Security Considerations 398 5.1. Restricting CDNs to the Delegation Mechanism 400 Currently there are no standard methods for the DNO to ensure that 401 the CDN cannot issue a certificate through mechanisms other than the 402 one described here, for the URLs under the CDN's control. For 403 example, regardless of the STAR solution, a rogue CDN employee can 404 use the ACME protocol (or proprietary mechanisms used by various CAs) 405 to create a fake certificate for the DNO's content because ACME 406 authorizes its requests using information that may be under the 407 adversary's control. 409 The best solution currently being worked on would consist of several 410 related configuration steps: 412 o Make sure that the CDN cannot modify the DNS records for the 413 domain. Typically this would mean that the content owner 414 establishes a CNAME resource record from a subdomain into a CDN- 415 managed domain. 416 o Restrict certificate issuance for the domain to specific CAs that 417 comply with ACME. This assumes universal deployment of CAA 418 [RFC6844] by CAs, which is not the case yet. We note that the CA/ 419 Browser Forum has recently decided to require CAA checking 420 [CAB-CAA]. 421 o Deploy ACME-specific methods to restrict issuance to a specific 422 authorization key which is controlled by the content owner 424 [I-D.ietf-acme-caa], and/or to specific ACME authorization 425 methods. 427 This solution is recommended in general, even if an alternative to 428 the mechanism described here is used. 430 6. Acknowledgments 432 This work is partially supported by the European Commission under 433 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 434 for a Middleboxed Internet (MAMI). This support does not imply 435 endorsement. 437 7. References 439 7.1. Normative References 441 [I-D.ietf-acme-acme] 442 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 443 Certificate Management Environment (ACME)", draft-ietf- 444 acme-acme-06 (work in progress), March 2017. 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 7.2. Informative References 453 [CAB-CAA] CA/Browser Forum, "Ballot 187 - Make CAA Checking 454 Mandatory", March 2017, . 457 [I-D.cairns-tls-session-key-interface] 458 Cairns, K., Mattsson, J., Skog, R., and D. Migault, 459 "Session Key Interface (SKI) for TLS and DTLS", draft- 460 cairns-tls-session-key-interface-01 (work in progress), 461 October 2015. 463 [I-D.erb-lurk-rsalg] 464 Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", 465 draft-erb-lurk-rsalg-01 (work in progress), May 2016. 467 [I-D.iab-web-pki-problems] 468 Housley, R. and K. O'Donoghue, "Improving the Public Key 469 Infrastructure (PKI) for the World Wide Web", draft-iab- 470 web-pki-problems-05 (work in progress), October 2016. 472 [I-D.ietf-acme-caa] 473 Landau, H., "CAA Record Extensions for Account URI and 474 ACME Method Binding", draft-ietf-acme-caa-01 (work in 475 progress), February 2017. 477 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 478 Authority Authorization (CAA) Resource Record", RFC 6844, 479 DOI 10.17487/RFC6844, January 2013, 480 . 482 [Topalovic] 483 Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. 484 Boneh, "Towards Short-Lived Certificates", 2012, 485 . 487 Appendix A. Document History 489 [[Note to RFC Editor: please remove before publication.]] 491 A.1. draft-ietf-acme-star-00 493 o Initial working group version. 494 o Removed the STAR interface, the protocol between NDC and DNO. 495 What remains is only the extended ACME protocol. 497 A.2. draft-sheffer-acme-star-02 499 o Using a more generic term for the delegation client, NDC. 500 o Added an additional use case: public cloud services. 501 o More detail on ACME authorization. 503 A.3. draft-sheffer-acme-star-01 505 o A terminology section. 506 o Some cleanup. 508 A.4. draft-sheffer-acme-star-00 510 o Renamed draft to prevent confusion with other work in this space. 511 o Added an initial STAR protocol: a REST API. 512 o Discussion of CDNI use cases. 514 A.5. draft-sheffer-acme-star-lurk-00 516 o Initial version. 518 Authors' Addresses 520 Yaron Sheffer 521 Intuit 523 EMail: yaronf.ietf@gmail.com 525 Diego Lopez 526 Telefonica I+D 528 EMail: diego.r.lopez@telefonica.com 529 Oscar Gonzalez de Dios 530 Telefonica I+D 532 EMail: oscar.gonzalezdedios@telefonica.com 534 Antonio Agustin Pastor Perales 535 Telefonica I+D 537 EMail: antonio.pastorperales@telefonica.com 539 Thomas Fossati 540 Nokia 542 EMail: thomas.fossati@nokia.com