Network Working Group Y. Sheffer
Internet-Draft Intuit
Intended status: Standards Track May 12, 2016
Expires: November 13, 2016

Delegating TLS Certificates to a CDN
draft-sheffer-lurk-cert-delegation-00

Abstract

An organization that owns web content often prefers to delegate hosting of this content to a Content Delivery Network (CDN). To serve HTTP content securely, it needs to be protected with TLS. This document proposes a way for the CDN to request constrained certificates so that it can serve web content on behalf of the content owner, without having the owner’s long term certificate.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 13, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

Content owners frequently prefer a Content Delivery Network (CDN) to host their content. CDNs typically have very large networks, and are designed to serve content to a global audience with a high aggregate bandwidth.

To protect this traffic, the CDN uses HTTPS and presents a certificate that usually bears the content owner’s name. However, many content owners balk at sharing their long-term private keys with another organization.

This document proposes a way for the CDN to obtain short-term credentials (an end-entity certificate along with the associated private key), allowing the content owner to revoke this authority at short notice.

We note that there are other solutions to this problem:

1.1. Conventions used in this document

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

2. Overview

We define the interaction between the CDN and the content owner, where the CDN requests a short-term certificate periodically, and the content owner obtains it on the CDN’s behalf and returns it to the CDN.

We expect the content owner to use the ACME protocol to obtain a short-term certificate, but this is not strictly required by the protocol.

2.1. Advantages

3. LURK Operations

This section lists the REST APIs that the content owner needs to provide to the CDN.

3.1. Request a Certificate

POST /.well-known/lurk/certificate/1234 HTTP/1.1
Content-Type: application/json

{
    "password":"fb2831d6607124286a7b439f2f09793a"
}

There is no negotiation of key type (RSA or ECDSA), key length or validity dates, and the client and server must coordinate these details in advance. Similarly, the server MUST be able to determine the FQDN to be included in the certificate based on the authenticated client’s identity.

The URI contains a request ID, which MAY be sequential or generated randomly by the client.

The given password MUST be randomly generated and SHOULD have at least 128-bits of entropy.

The server responds with one of:

3.2. Poll for a Certificate

GET /.well-known/lurk/certificate/1234 HTTP/1.1

The server responds with one of:

Access to these resources MUST be protected by TLS.

Both requests MUST be authenticated, using one of the following methods:

The client cannot assume that the sever will cache the certificate beyond a few seconds after it is first fetched.

4. Security Considerations

This section presents additional considerations beyond those strictly required by the protocol.

4.1. Certificate Details

4.2. Revocation

When the content owner decides it no longer trusts the CDN, the content owner MUST:

4.3. Restricting CDNs to the Delegation Mechanism

Currently there are no standard methods for the content owner to ensure that the CDN cannot issue a certificate through mechanisms other than the one described here, for the URLs under the CDN’s control. The best solution currently being worked on would consist of several related configuration steps:

This solution is recommended in general, even if an alternative to the mechanism described here (e.g. [I-D.cairns-tls-session-key-interface]) is used.

5. References

5.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC7292] Moriarty, K., Nystrom, M., Parkinson, S., Rusch, A. and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014.

5.2. Informative References

[I-D.cairns-tls-session-key-interface] Cairns, K., Mattsson, J., Skog, R. and D. Migault, "Session Key Interface (SKI) for TLS and DTLS", Internet-Draft draft-cairns-tls-session-key-interface-01, October 2015.
[I-D.ietf-acme-acme] Barnes, R., Hoffman-Andrews, J. and J. Kasten, "Automatic Certificate Management Environment (ACME)", Internet-Draft draft-ietf-acme-acme-02, March 2016.
[I-D.landau-acme-caa] Landau, H., "ACME Account Key Binding via CAA Records", Internet-Draft draft-landau-acme-caa-00, April 2016.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, DOI 10.17487/RFC6844, January 2013.

Appendix A. Document History

A.1. draft-sheffer-lurk-cert-delegation-00

Initial version.

Author's Address

Yaron Sheffer Intuit EMail: yaronf.ietf@gmail.com