idnits 2.17.1 draft-sheffer-lurk-cert-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 : ---------------------------------------------------------------------------- ** 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 (May 12, 2016) is 2906 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 RFC: RFC 7292 == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-02 == Outdated reference: A later version (-01) exists of draft-landau-acme-caa-00 -- Obsolete informational reference (is this intentional?): RFC 6844 (Obsoleted by RFC 8659) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Standards Track May 12, 2016 5 Expires: November 13, 2016 7 Delegating TLS Certificates to a CDN 8 draft-sheffer-lurk-cert-delegation-00 10 Abstract 12 An organization that owns web content often prefers to delegate 13 hosting of this content to a Content Delivery Network (CDN). To 14 serve HTTP content securely, it needs to be protected with TLS. This 15 document proposes a way for the CDN to request constrained 16 certificates so that it can serve web content on behalf of the 17 content owner, without having the owner's long term certificate. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 13, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. LURK Operations . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Request a Certificate . . . . . . . . . . . . . . . . . . 4 59 3.2. Poll for a Certificate . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 4.1. Certificate Details . . . . . . . . . . . . . . . . . . . 5 62 4.2. Revocation . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.3. Restricting CDNs to the Delegation Mechanism . . . . . . 5 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 5.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Appendix A. Document History . . . . . . . . . . . . . . . . . . 8 68 A.1. draft-sheffer-lurk-cert-delegation-00 . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Content owners frequently prefer a Content Delivery Network (CDN) to 74 host their content. CDNs typically have very large networks, and are 75 designed to serve content to a global audience with a high aggregate 76 bandwidth. 78 To protect this traffic, the CDN uses HTTPS and presents a 79 certificate that usually bears the content owner's name. However, 80 many content owners balk at sharing their long-term private keys with 81 another organization. 83 This document proposes a way for the CDN to obtain short-term 84 credentials (an end-entity certificate along with the associated 85 private key), allowing the content owner to revoke this authority at 86 short notice. 88 We note that there are other solutions to this problem: 90 - The CDN could contact the content owner on each TLS handshake and 91 have the content owner take part in completing the TLS handshake. 92 Such a solution is described in e.g. 93 [I-D.cairns-tls-session-key-interface]. 95 - We could extend ACME [I-D.ietf-acme-acme] by allowing the content 96 owner to share an authorization "ticket" with the CDN, the CDN 97 then using it to obtain short-term certificates directly from the 98 ACME server. This alternative is possibly easier to deploy than 99 the one described in this document, but it would require a non- 100 trivial change to the ACME protocol. 102 - The current proposal has the content owner generate the 103 certificate's private key, although the best practice would have 104 the CDN generate it and create a Certificate Signing Request 105 (CSR). Note however that it would be difficult for the content 106 owner to validate the correctness of a CSR, potentially allowing a 107 malicious CDN to obtain fraudulent certificates. 109 1.1. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Overview 117 We define the interaction between the CDN and the content owner, 118 where the CDN requests a short-term certificate periodically, and the 119 content owner obtains it on the CDN's behalf and returns it to the 120 CDN. 122 We expect the content owner to use the ACME protocol to obtain a 123 short-term certificate, but this is not strictly required by the 124 protocol. 126 2.1. Advantages 128 - Compared with solutions that require the CDN to have the content 129 owner sign each handshake, this solution does not require the 130 content owner to set up its own scalable infrastructure. 132 - Moreover, the need to scale the content owner's web service could 133 result in the content owner ending up by sharing the private keys 134 with the CDN and abdicating its responsibility for its own 135 security. 137 3. LURK Operations 139 This section lists the REST APIs that the content owner needs to 140 provide to the CDN. 142 3.1. Request a Certificate 144 POST /.well-known/lurk/certificate/1234 HTTP/1.1 145 Content-Type: application/json 147 { 148 "password":"fb2831d6607124286a7b439f2f09793a" 149 } 151 There is no negotiation of key type (RSA or ECDSA), key length or 152 validity dates, and the client and server must coordinate these 153 details in advance. Similarly, the server MUST be able to determine 154 the FQDN to be included in the certificate based on the authenticated 155 client's identity. 157 The URI contains a request ID, which MAY be sequential or generated 158 randomly by the client. 160 The given password MUST be randomly generated and SHOULD have at 161 least 128-bits of entropy. 163 The server responds with one of: 165 - A "200 OK" status code, and response body containing a PKCS #12 166 [RFC7292] structure (private key and certificate), with the 167 content type: "application/x-pkcs12". The structure is protected 168 by the given password. 170 - A "201 Accepted" status code if the certificate is not yet ready. 171 The CDN should poll the content owner periodically (see below), 172 but not more often than once every 5 seconds. 174 - Other responses if the request is not acceptable or not allowed. 176 3.2. Poll for a Certificate 178 GET /.well-known/lurk/certificate/1234 HTTP/1.1 180 The server responds with one of: 182 - A "200 OK" status code, and response body containing the PKCS #12 183 response, with the content type: "application/x-pkcs12". 185 - A "204 No Content" status code if the certificate is not yet 186 ready. 188 - Other responses if the request is not acceptable or not allowed. 190 Access to these resources MUST be protected by TLS. 192 Both requests MUST be authenticated, using one of the following 193 methods: 195 - Mutual TLS authentication with a client certificate. This is the 196 RECOMMENDED option. 198 - TLS with preshared secret authentication or TLS-SRP. 200 - TLS with HTTP-Basic or Digest authentication. 202 The client cannot assume that the sever will cache the certificate 203 beyond a few seconds after it is first fetched. 205 4. Security Considerations 207 This section presents additional considerations beyond those strictly 208 required by the protocol. 210 4.1. Certificate Details 212 - It is RECOMMENDED to restrict the certificate's scope as much as 213 possible. Specifically, the certificate request SHOULD specify 214 restrictive Key Usage. 216 - The certificate SHOULD NOT be for a wildcard DN. 218 - The RECOMMENDED validity period for certificates provisioned using 219 this mechanism is 3 days, and the certificate SHOULD be valid 220 immediately when it is fetched. 222 4.2. Revocation 224 When the content owner decides it no longer trusts the CDN, the 225 content owner MUST: 227 - Revoke any extant short-term certificates already handed to the 228 CDN. This implies that all such certificates MUST be logged. 230 - Immediately block the certificate issuance operations described 231 above. 233 4.3. Restricting CDNs to the Delegation Mechanism 235 Currently there are no standard methods for the content owner to 236 ensure that the CDN cannot issue a certificate through mechanisms 237 other than the one described here, for the URLs under the CDN's 238 control. The best solution currently being worked on would consist 239 of several related configuration steps: 241 - Make sure that the CDN cannot modify the DNS records for the 242 domain. Typically this would mean that the content owner 243 establishes a CNAME resource record from a subdomain into a CDN- 244 managed domain. 246 - Restrict certificate issuance for the domain to specific CAs that 247 comply with ACME. This assumes universal deployment of CAA 248 [RFC6844] by CAs, which is not the case yet. 250 - Deploy ACME-specific methods to restrict issuance to a specific 251 authorization key which is controlled by the content owner 252 [I-D.landau-acme-caa]. 254 This solution is recommended in general, even if an alternative to 255 the mechanism described here (e.g. 256 [I-D.cairns-tls-session-key-interface]) is used. 258 5. References 260 5.1. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, 265 . 267 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 268 and M. Scott, "PKCS #12: Personal Information Exchange 269 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 270 . 272 5.2. Informative References 274 [I-D.cairns-tls-session-key-interface] 275 Cairns, K., Mattsson, J., Skog, R., and D. Migault, 276 "Session Key Interface (SKI) for TLS and DTLS", draft- 277 cairns-tls-session-key-interface-01 (work in progress), 278 October 2015. 280 [I-D.ietf-acme-acme] 281 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 282 Certificate Management Environment (ACME)", draft-ietf- 283 acme-acme-02 (work in progress), March 2016. 285 [I-D.landau-acme-caa] 286 Landau, H., "ACME Account Key Binding via CAA Records", 287 draft-landau-acme-caa-00 (work in progress), April 2016. 289 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 290 Authority Authorization (CAA) Resource Record", RFC 6844, 291 DOI 10.17487/RFC6844, January 2013, 292 . 294 Appendix A. Document History 296 A.1. draft-sheffer-lurk-cert-delegation-00 298 Initial version. 300 Author's Address 302 Yaron Sheffer 303 Intuit 305 EMail: yaronf.ietf@gmail.com