| Network Working Group | F. Fieau, Ed. |
| Internet-Draft | E. Stephan |
| Intended status: Standards Track | Orange |
| Expires: May 4, 2017 | S. Mishra |
| Verizon | |
| October 31, 2016 |
HTTPS delegation in CDNI
draft-fieau-cdni-https-delegation-00
This document examines probable solutions for delegating of encrypted content within the context of CDN interconnection. HTTPS delegation allows a delivering party, e.g. a CDN, to deliver content for and on-behalf of an origin server. The HTTPS delegation also expects delivering content without compromising security, integrity and privacy of the user. This document examines Internet Drafts that have been submitted along with their implementation status.
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 May 4, 2017.
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.
Currently, sixty percent of the HTTP traffic of the internet is encrypted, that is, it is transported over TLS [RFC5246]. At the same time, HTTP traffic served by CDNs is on the rise as well. The traffic on CDNs is estimated to increase from forty-five percent in 2015 to seventy-five percent in year 2020 [ciscotraffic].
This document discusses viability of and solution for addressing delegation of HTTP over TLS [RFC2818] traffic within the context of CDN interconnection. HTTPS delegation allows delivering party, e.g. a CDN, to deliver content for and on-behalf of an origin server.
This draft considers three approaches for delegating HTTPS traffic in a CDNI context. These include Limited Use of Remote Keys (LURK), Out-of-Band, Short-Lived Certificates and Sub-Certificates (or delegated credentials). We examine these approaches focusing on the following three issues:
To recap, CDNi goals, the CDNi WG focuses on the relationship between the upstream CDN and the downstream CDN. Therefore, this document examines HTTPS delegation with applicability to CDNi use cases and particularly from an end-to-end perspective including the UA and the Origin.
[I-D.cdni-fieau-lurk-https-delegation] shows 2 use cases related to CDN interconnection based on LURK [I-D.mglt-lurk-tls-use-cases]:
dCDNs have an interface to a Key Server hosted at the uCDN side. It may be typically a case of CDNI regional delivery delegation.
When the UA has been redirected from the uCDN to a dCDN,it initiates a TLS connection with a dCDN cache to get his content. Since dCDN cache does not store the private keys for the requested certificate, it queries the uCDN Key Server (KS) to get credentials to establish the TLS session. Finally the dCDN cache can deliver HTTPS content to the UA using CSP certificate.
This framework makes 2 assumptions:
In this framework the CSP provides a Key Server for the origin domains it is authoritative on to ensure an end-to-end HTTPS delegation, from the Origin to the dCDN which eventually delivers the HTTPS content to the UA. The CSP provides the LURK Key Server and interface.
The CSP delegates the HTTPS content delivery to an uCDN that in turn delegates the HTTPS delivery to a dCDN. The CSP provides the uCDN with a Key Server interface to delegate the content delivery. In that case, the dCDN relies on credentials received from a CSP Key Server (KS) to deliver HTTPS content.
This framework supports 2 options:
This section presents the usage of HTTP Out-of-Band mechanism [I-D.reschke-http-oob-encoding] to deliver HTTPS content in CDNI.
Out-of-Band HTTPS content delivery (OOB) relies on the use of the "out-of-band" value in "Accept-encoding" HTTP header of the request. It indicates that the UA supports downloading the resource from alternative locations than the Origin. To that purpose, when the out-of-band content encoding is set, the Origin server may response with a list of caches where to fetch the requested resource.
Example:
{sr: [{r:"https://ori/path/content1", r:"https://cdn1/path/content1"}]}
+----------+ +----------------+ +-------------+
| UA |--3) GET --->| cache |--4) GET---> |Origin Server|
+----+-----+ content +----------------+ content +----+--------+
| ^ | ^
| |---------- 2) 2OO OK, OOB + resource map-----------+ |
|--------------------- 1) HTTP GET content -------------------+
Figure 1: OOB general principle
Out-of-Band framework involves the following functional entities:
Origin server:
UA:
Cache server:
In CDNI, uCDN may use OOB to direct a UA to dCDN by indicating a resource map where it can fetch contents. In CDNI, an end-to-end delegation allows an Origin delegates HTTPS delivery to uCDN which in turns delegates it to dCDN.
For instance, end-to-end delegation may involve cascaded resource maps. The Origin delegates HTTPS delivery to the uCDN using OOB, and uCDN delegates HTTPS delivery to dCDN through OOB. In that case, the UA requests Origin that sends back a resource map pointing at the uCDN. Then UA requests the uCDN which sends back a resource map (OOB) pointing at dCDN hosted resources.
User Agent dCDN uCDN Origin
| | | |
| GET http://origin/hash1/content | |
+----------------------------------------------------->|
| 200 OK + OOB | |
+<-----------------------------------------------------|
| GET http://ucdn/hash2/content | |
+------------------------------------>| |
| 200 OK + OOB | |
|<------------------------------------+ |
| | | |
|GET http://dcdn/hash2/content | |
+----------------->| | |
| | GET http://ucdn/hash2/content |
| |----------------->| |
| | 200 OK (encrypted content) |
| |<-----------------| |
| 200 OK (encrypted content) | |
|<-----------------+ | |
| | | |
figure 2: OOB with successive resource maps in CDNI
The need to scale is a central requirement to generalize HTTPS content delivery across CDNs. Both [I-D.rescorla-tls-subcerts] and [I-D.sheffer-lurk-cert-delegation] share the same paradigm. They aim to decouple credentials provisioning from content delivery.
The [I-D.sheffer-lurk-cert-delegation] cert architecture adds interactions between the CDN and the Origin and between the Origin and the CA which signs the limited authority delegation;
[I-D.sheffer-lurk-cert-delegation] certificate implementation requires modifications of the UA, the cache and the origin. The [I-D.rescorla-tls-subcerts] proposes an architecture where the TLS server by itself can create a sub-certificate (also referred to as "delegated credentials") based on the original certificate issued to it by the CA. This sub-certificate's scope is only to the credentials issued by the CA corresponding to the original certificate and for the named servers the CA has authorized.
In case of CDNI, it is feasible that the uCDN may issue "delegated_credentials" to a dCDN for any HTTPS content it delegates to dCDN for delivery.
This new "delegated certificate" will have a validity interval along with the public key issued to the Content Service Provider (CSP) or to its surrogate (CDN) by the CA and a list of valid server names.
Both solutions require changes to the user agent. The [I-D.rescorla-tls-subcerts] draft proposes User Agent to send an empty "delegated_credential" extension in its ClientHello.
The proposal outlines an option where a CA can issue subordinate certificate but with a nameConstraints extension with encoded names the TLS server is authorized for in the original certificate. In this approach, the credentials would just be equivalent of end-entity certificates issued under the subordinate certificate. The use of nameConstraints extension, will only work for clients that indicate its support and will not work for clients that do not support nameConstraints.
Based upon the Name Constraints option, the following two possible use cases can be considered for CDNi:
For a use case when the CSP does not authorizes CDN (uCDN) to request CA on its behalf to request private keys and the certificate instead it allows the CDN to request a subordinate certificate on its behalf. In such a case, the CDN (uCDN) can request the CA for a subordinate certificate. Based on this subordinate certificate request, the CA can issue credentials with the nameConstraints extension encoding using the names of servers uCDN would identify in its request to the CA. In this scenario, we assume that CSP and uCDN have a business relationship and an agreement that allows uCDN to request a sub-certificate on behalf of the CSP. However, it is not clear from the [I-D.rescorla-tls-subcerts] draft the scope of request can be cascaded down from one CDN to another CDN, that is, from an uCDN to dCDN. This needs further understanding on scope to request a sub-certificate by one and more dCDN who may or may not have business relationship with the CSP.
When the CSP allows CDN to procure a certificate from the CA on its behalf, the uCDN can then issue a subordinate certificate with the nameConstraints extension encoding for the names of server (identified by dCDN to uCDN) in request for any HTTPS content that uCDN shall delegate to dCDN to serve on its behalf. In this scenario we assume that dCDN provides all information regarding servers that will be used for holding content for which uCDN will issue sub-certificates to the dCDN.
In this option, the [I-D.rescorla-tls-subcerts] draft proposes a method where TLS server as an end-entity certificate holder can issue a sub-certificate. This method however requires changes to how the certificates are issued to an end-entity. A mechanism would be needed to enable end-entity issue a sub-certificate. The [I-D.rescorla-tls-subcerts] draft suggests defining a marker value within an end-entity certificate as an indicator that it can issue sub-certificates. The use of marker shall distinguish an existing end-entity certificate holder who should not issue versus holder (uCDN) of an end-entity certificate with a marker that can issue a sub-certificate. Alternatively, the draft also suggests that a marker can even be the fact that an end-entity certificate to not contain KeyEncipherment KeyUsage (Refer to [RFC5280], section 4.2.1.3). KeyEncipherment bit can be used by older protocols such as SSLv2, therefore, suggestion by authors is that mere absence of this field not only prevents forging of signature but its absence implicitly can also be an indicator and clients can refuse any connections from certificates with with KeyEncipherment KeyUsage field.
When applied to CDNi scenario, we consider following two cases:
In this scenario, CSP does not share private keys and the certificate with the CDN (uCDN), instead the CSP can issues a sub-certificate to the uCDN. It is not clear from the [I-D.rescorla-tls-subcerts] draft if the scope of request can be cascaded down from one CDN to another CDN, that is, from an uCDN to dCDN. This needs further understanding on scope to request a sub-certificate by one and more dCDN who may or may not have business relationship with the CSP.
In this scenario, a CSP allows its CDN provider to request on its behalf the private keys and certificate from the CA. This allows a uCDN as an end-entity certificate holder to issue a sub-certificate for the dCDN. In this case, we assume the dCDN only requires prior business agreements with the uCDN and does not require any business agreements with the CSP.
The [I-D.rescorla-tls-subcerts] draft explores an option to allow creating of new signed objects based on existing X.509 end-entity certificates. The draft requires presence of digitalSignature bit of the KeyUsage ([RFC5280], section 4.2.1.3) in the certificate to create the new signed object. The drafts states that this approach will require defining a new signed object format with encoding for only the semantics needed for generation of new signed objects.
When applied to CDNi scenario, we consider the following two cases:
In a scenario when the CSP does not authorize CDN (uCDN) the use of its private keys and certificate, the CSP will need to issue a signed object for use by uCDN. However, given that the uCDN does not hold the original certificate, it may not be able to create another signed object to cascade to a dCDN. Clarification is needed from the [I-D.rescorla-tls-subcerts] authors on any further mechanism to allow support for cascaded issuance of the sub-certs.
In scenario the CSP authorizes CDN (uCDN) to request private keys and certificate on its behalf from the CA. In this case, we expect that uCDN can create a new signed object based on X.509 end entity certificates using digitalSignature Key usage (RFC5280 section 4.2.1.3)
The [I-D.rescorla-tls-subcerts] draft proposes re-configuring the certificate for use either as an end-entity certificate or to be used for signing sub-certificates. Or, the master certificate can be configured such that it in itself is not directly usable, rather the name-holder to request two certificates. One such certificate can be used for TLS authentication and second for signing credentials.
When applied to CDNi scenario, we consider the following case:
In this scenario, CSP authorizes CDN (uCDN) to request a master certificate. As stated in the [I-D.rescorla-tls-subcerts] draft the master certificate is not directly usable rather the master certificate is issued as the CDN (uCDN) the name-holder. In this scenario, the uCDN can delegate the signed credentials to the dCDN. However, as it is not the intent of [I-D.rescorla-tls-subcerts] to consider CDNi uses, it does not discuss cascaded delegation, therefore, it is not clear if TLS authentication certificate can be conveyed to the dCDN. This will need clarifications from the [I-D.rescorla-tls-subcerts] authors.
[I-D.sheffer-lurk-cert-delegation] specifies an RESP API between the uCDN and the CSP. It proposes a solution which provides the uCDN with short term HTTPS delivery delegation.
Compared to per session key exchange, it decouples the credentials provisioning from the content delivery to limit the burden on the CSP side. It limits signaling to periodic short term certificate requests (CSR) sent from the uCDN to the content owner:
The solution as currently proposed requires periodic requests from the uCDN to procure keys and certificate.
The sub certificates cases describe above apply to Short lived certificates. The CSP would also need to obtain a second certificate with suitable keyUsage values for generating sub certificate. Both Sub apply to a relation of delegation between a dCDN and uCDN.
The draft proposes an second architecture where the uCDN requests directly the sub certificate to the CA using the ACME protocol. It relies on the control by the content owner of URI based certificate issuances based on the ACME protocol, using extensions [I-D.ietf-acme-caa] to DNS CAA [RFC6844].
A LURK interface may provide advantages to HTTPS delegation in CDNI such as:
However, preserving UX performances cannot be guaranteed as additional RTT are needed to fetch the needed session credentials from the Key Server.
OOB may provide advantages to HTTPS delegation in CDNI such as:
However, the use of OOB to ensure HTTPS delegation in CDNI should be clarified in many cases:
1. For instance, an E2E delegation using OOB with DNS redirect would raise a delegation issue where the requested domain doesn't match the URI which may trigger a warning on the UA. As such, delegation is not solved (HARD problem).
The Origin delegates the delivery to uCDN with OOB, next the uCDN delegates HTTPS delivery to a dCDN using DNS.In that case, the UA requests origin that sends back a resource map pointing at uCDN, UA DNS then queries uCDN.com which is resolved to a dCDN server IP, the UA requests contents on dCDN server
2. In another example, an E2E delegation using 302 redirect first and OOB next, would raise a delegation issue where the origin of information is the uCDN, not the Origin.
The Origin delegates HTTPS delivery to uCDN through a 302 redirect, next uCDN delegates HTTPS delivery to dCDN using OOB. In that case, the UA requests Origin who redirects it to the uCDN using 302 HTTP, then UA requests the uCDN which answers OOB content pointing at dCDN, then UA requests content on dCDN.
Finally, some clarifications about OOB draft are needed:
The motivation of [I-D.rescorla-tls-subcerts] draft is to remove dependency between the Origin Server or its surrogates and the CA specifically for enabling the ability to issue credentials (sub-certificates) under the authority of its own certificate and importantly, manage lifetime of the certificates and also have the ability to support any new cryptographic algorithms. The intent for the authors is to give Origin Servers (or their surrogates) operational independence when needing to either limit the life of a certificate or when needing to issue a sub-certificate with limited life. This process may be expeditious over needing to work with the CA for either of the aforementioned changes while still preserving the security and integrity of the content and communications between the origin server or it's and surrogate and the client.
The [I-D.rescorla-tls-subcerts] draft explores several options to allow origin server or its surrogate with capabilities to issue a sub-certificate or delegated credentials with limited authority (authorized name servers and a validity interval). The draft also provides for ways where a client can control issuance of sub-certificates. This control can be exerted by the clients by use of an optional "delegated_credential" extension field in the clientHello. The draft also calls out rules for its use, such as, a server cannot unilaterally send this extension but that it can only send credentials when presented by the clientHello message.
However, as noted in sub-sections, 5.2 and 5.3, the applicability of this draft may be limited in cascaded delegation that is from an up stream CDN to the downstream CDN. Further clarity may be required from the [I-D.rescorla-tls-subcerts] draft authors on ability to cascade sub-certificates. The draft also lists pros and cons for various options it considers in the draft. For brevity, those pros and cons are not listed in this document.
The [I-D.sheffer-lurk-cert-delegation] and the [I-D.rescorla-tls-subcerts] propose approaches where a TLS server, i.e., a uCDN issue certificates or a sub-certificate with limited authority and time without having to share a private key. The approaches avoid any additional infrastructure cost and potential for scaling up the solution. One of the key drawbacks with either approach is additional changes required such as uCDN with content owner and CA for [I-D.sheffer-lurk-cert-delegation]. Additionally, a short-lived certificate creation system must be fully automated, as manual renewal of certificates every few days is not practical. An automated system requires require business relations and agreement between the SP and CDN, and an initial setup. In case of [I-D.rescorla-tls-subcerts], the proposal requires changes to TLS handshake where the client provides an extension in its ClientHello that indicates support for this mechanism.
Generic HTTPS delegations requirements that should be discussed:
At the time being, LURK, OOB and subcerts are in early stage. Currently SLC and subcerts are not available and need to be clarified. However some prototypes already exists for OOB and LURK [I-D.cairns-tls-session-key-interface] [EricssonOOB].
In order to ensure an end-to-end delegation from the Origin to dCDN, a CDNI HTTPS delegation solution may combine several options described in this document.
Currently, no single solution fits the cascaded CDNs approach alone. As such, these solutions could be complementary to allow an end-to-end delegation in CDNI. However, the work on these drafts are in progress or in early stages and needs further work to provide an end-to-end solution.
This document has no IANA considerations.
The entire document is about security.
| [RFC2818] | Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008. |
| [RFC6844] | Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, DOI 10.17487/RFC6844, January 2013. |
| [ciscotraffic] | The Zettabyte Era—Trends and Analysis", 2016. | , "
| [EricssonOOB] | Ericsson BC drafts", 2016. | , "
| [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.cdni-fieau-lurk-https-delegation] | Fieau, F. and S. Emile, "Limited Use of Remote Keys for Interconnected CDNs", Internet-Draft draft-cdni-fieau-lurk-https-delegation-00, July 2016. |
| [I-D.ietf-acme-caa] | Landau, H., "CAA Record Extensions for Account URI and ACME Method Binding", Internet-Draft draft-ietf-acme-caa-00, October 2016. |
| [I-D.ietf-httpbis-encryption-encoding] | Thomson, M., "Encrypted Content-Encoding for HTTP", Internet-Draft draft-ietf-httpbis-encryption-encoding-03, October 2016. |
| [I-D.mglt-lurk-tls-use-cases] | Migault, D., Ma, K., Salz, R., Mishra, S. and O. Dios, LURK TLS/DTLS Use Cases", Internet-Draft draft-mglt-lurk-tls-use-cases-02, June 2016. |
| [I-D.reschke-http-oob-encoding] | Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding for HTTP", Internet-Draft draft-reschke-http-oob-encoding-09, October 2016. |
| [I-D.rescorla-tls-subcerts] | Rescorla, E., Barnes, R., Iyengar, S. and N. Sullivan, "Delegated Credentials for TLS", Internet-Draft draft-rescorla-tls-subcerts-00, July 2016. |
| [I-D.sheffer-lurk-cert-delegation] | Sheffer, Y., "Delegating TLS Certificates to a CDN", Internet-Draft draft-sheffer-lurk-cert-delegation-00, May 2016. |