Limited Use of Remote Keys for Interconnected CDNs

CDNI requirements and use cases specify the requirements and use cases of HTTP content delivery between CDNs. The intent of this document is to pursue the work by proposing a solution for delegating content delivery over secure protocols like HTTPS or DTLS. Conversely to HTTP delivery, HTTPS allows content delivery between Content Service Provider (CSP) and End-users with integrity and confidentiality. From the CDNI perspective, all parties - UAs, CSPs origin servers, and CDNs - are involved in the chain of trust and preserving this chain of trust in HTTPS raises concerns. Indeed, regarding TLS certificates, CSPs and CDN providers are reluctant to share private keys mainly because of legal and security issues about private keys. Therefore the CDNI working group must specify a solution that avoids the exchange of private keys between CDNs. This document leverages the work of the LURK initiative and discusses the introduction of a Limited Use of Remote Keys (LURK) solution in the CDNI architecture. It presents 2 use cases which complement those described in and identifies a set of requirements for CDNI. Finally it discusses different options and identifies a set of open issues. The proposed use cases are based on DNS redirection. The user agent is redirected to a dCDN to establish a TLS session to get HTTPS content. Additional use cases are expected in future versions of the draft. This version focus on the delivery over HTTPS only.

This document uses terminology from CDNI framework documents such as CDNI requirements and CDNI interface specifications documents - CDNI metadata interface , CDNI Control interface and Logging interface .

This document introduces a Key Server in the CDNI architecture. The general LURK architecture is described in the Session Key interface draft .

| TLS Server | <-------> | Key Server | +------------+ +------------------+ +------------+ ]]> Figure 1: General Key Server Architecture In CDNI, a LURK interface allows private keys to remain under the authority of its owner – typically the CSP or the uCDN - while delivering the content over HTTPS. The LURK interface can be introduced at different locations in the CDNI architecture. The location of the LURK function depends on the use cases. Additionally, this architecture may support variants where the Key server is owned by a third party.

|dCDN TLS Surrogate| <-------> |(uCDN/CSP/3rd Party) Key Server | +------------+ +------------------+ +--------------------------------+ ]]> Figure 2: Key Server in CDNI Architecture This document complements the LURK architecture of with CDNI use cases. In those use cases, content delivery is decoupled from both content acquisition and signaling information needed to route and control the request. Currently CDNI signaling exchanges occur over the Request Routing Redirection interface (information to route the request across CDNs), the Metadata interface (per content or group of content information about the acquisition and the delivery), the Logging interface (exchange of monitoring information about the delivery) and the Control interface (information for controlling the lifecycle of the aforementioned interfaces). The LURK interface for CDNI adds two types of exchange: one for acquiring the certificate associated with the origin domain and the other for establishing delivery confidentiality and integrity. This document presents two use cases of HTTPS delivery which rely on a LURK function to avoid exchanging private keys between CDNs: A. uCDN Key server: the CSP has provided his certificate and private keys to the uCDN. the uCDN provides the LURK key server and interface. B. CSP Key server: the CSP provides the LURK Key Server and interface. The table below presents the use cases developed in the Section 3.

Figure 3: Use cases description table The use cases' call flows are respectful of the CDNI redirection for the description of redirection methods in CDNI. They share the same steps. The figure below illustrates the framework use cases where the surrogate doesn’t handle the CSP private keys and where the surrogate remotely accesses materials to sign and encrypt information exchanged over the TLS connection.

| | | | | | | | | | | |2. TLS serverHello |+-----------------+| | |<-------------------|| || | | || || | |3. Certificate || || | |<-------------------|| LURK Exchanges || | | ||<--------------->|| | | || || | | || || | | || || | | |+-----------------+| | |4. ServerKeyExchange| | | |<-------------------| | | |... Continued | | | ]]> Figure 4: LURK exchanges in CDNI architecture

Two use cases are considered in this document to implement LURK in CDNI: uCDN Key Server CSP Key Server

In this use case, the dCDN has a LURK interface to a Key Server hosted at the uCDN side. It may be typically a case of CDNI regional delivery delegation. This following example is based on ECDHE cypher suite. The UA is first redirected from the uCDN to a dCDN using a recursive DNS redirection. Then the UA initiates a TLS connection with the dCDN to get his content. Since the dCDN does not store the private keys for the requested certificate, it queries the uCDN Key Server (KS) to get the credential to establish the TLS session with the User Agent. Finally the dCDN can deliver the content in HTTPS to the UA using the CSP certificate. The UA sends an HTTPS request to the CSP to get a content. a. to d. As seen on figure 5, once the DNS resolution is over, i.e., UA was able to resolve dCDN surrogate IP@ steps [a.] to [d.], the user agent connects to the dCDN surrogate. Note that DNS cache is not shown on the figure. 1. The UA sends a ClientHello, as defined in the TLS protocol . The SNI field of the ClientHello includes the CSP domain name. 2. The surrogate receives the ClientHello from the UA, and sends a ServerHello to the UA. 3. The surrogate parses the SNI field, and determines the Key Server interface of the CSP domain name. The surrogate uses this piece of information to determine the certificate of the delivery. The surrogate sends the public certificate to the UA. The UA validates the certificate. 4. The surrogate determines the ECDHE parameters, and requests the Key Server to sign these parameters with the CSP private key. The request includes the domain name received by the surrogate in the SNI field of the ClientHello. 5. The Key Server returns the necessary credentials to the dCDN surrogate over a secure tunnel. 6. and 7. the UA and the surrogate exchange public DH parameters and compute session keys. 8. The UA and the surrogate establish a secure connection. The UA issues its request for content over HTTPS. The surrogate then processes the original request. Below is an example of the handshake establishment:

| | | | | |b. DNS CNAME dCDN | | | |<----------------------------------------------------------------| | | | | |c. DNS A? dCDN | | | |------------------->| | | | | | | |d. DNS A IP Surrogate | | |<-------------------| | | | | | | |1. ClientHello (Client Random) | | |------------------->| | | | | | | |2. ServerHello (Server Random) | | |<-------------------| | | | | | | |3. Certificate (Server certificate) | | |<-------------------| | | | | | | | |4. LURK query for Signature (ECDHEParams) | | |------------------>| | | | | | | |5. LURK response: signature (ECDHEParams) | | |<------------------| | | | | | |6. ServerKeyExchange (ECDHParams, Signature) | |<-------------------| | | | | | | |7. ClientKeyExchange (clientDHpublic) | | |------------------->| | | |Finished | | | |<------------------>| | | | | | | |8. HTTPS request | | | |------------------->| | | ]]> Figure 5: Key Server hosted by uCDN

This section describes a use case in CDNI where the CSP provides the Key Server (KS). In this example, the CSP delegates the HTTPS content delivery to an uCDN that in turn delegates the HTTPS delivery to a dCDN. For obvious legal or security reasons, the CSP does not want his private keys to be stored on all CDNs involved in the interconnection. In that case, the dCDN relies on credentials received from a CSP Key Server (KS) to deliver HTTPS content.The dCDN cannot here request the KS directly. Instead, the dCDN LURK request will be relayed by the uCDN to the Key Server. Prior to that, the uCDN has to check whether the received LURK request is valid, e.g., complies with Content Distribution policies . In the following example, the CSP stores his certificates and private keys on a Key Server that is able to compute and provide credentials for TLS establishment. 1. The UA sends a ClientHello to the dCDN’s surrogate, as defined in the TLS protocol . The SNI field of the ClientHello includes the CSP domain name. 2. The dCDN’s surrogate receives the ClientHello from the UA, and sends a ServerHello to the UA.. 3. The surrogate parses the SNI field, and determines the Key Server interface of the CSP domain name and determine the certificate of the delivery. The surrogate sends the public certificate to the UA. The UA checks the certificate signature with the public key. 4. The dCDN's surrogate requests the uCDN to sign parameters with the private key. 5. The uCDN parses the SNI field, and determines the Key Server interface of the CSP domain name. The uCDN relaies the LURK request received from the dCDN's surrogate, to the Key Server to sign parameters with the private key. 6. The Key Server returns the necessary credentials to the uCDN surrogate. 7. The uCDN returns the necessary credentials to the dCDN's surrogate. 8. and 9. the UA and the surrogate exchange public DH parameters and compute session keys. 10. The UA and the surrogate establish a secure connection. The UA issues its request for content over HTTPS. The surrogate then processes the original request.

| | | | | | | |2. ServerHello (Server Random) | | |<-------------------| | | | | | | |3. Certificate (Server certificate) | | |<-------------------| | | | | | | | |4. LURK query for Signature (ECDHEParams) | | |------------------>| | | | |5. LURK query for sign. | | | |----------------------->| | | | | | | |6. LURK response | | | |<-----------------------| | | | | | |7. LURK response: signature (ECDHEParams) | | |<------------------| | | | | | |8. ServerKeyExchange (ECDHParams, Signature) | |<-------------------| | | | | | | |9. ClientKeyExchange (clientDHpublic) | | |------------------->| | | |Finished | | | |<------------------>| | | | | | | |10. HTTPS request | | | |------------------->| | | ]]> Figure 6: Cascaded delegation with LURK

Other use cases will be described in a further version of this draft.

This section is a first attempt to identify the requirements introduced by the delivery of HTTPS content. Some of the requirements are new, whereas others may update existing CDNI requirements .

LURK-GEN-1: The specification should not require any change in User Agent. This is already stated in /GEN-2 Discussion: Despite this is obvious, it is important to notice that recent limitation in TLS (version, cyphers…) or HTTP (cyphers) documents may constrain User Agent. LURK-GEN-2: The user agent should be able to see that the requested content is delivered by the CDN using the CSP domain. Delivery domain name SHOULD be the same as the CSP portal domain name (or a sub-domain request name) LURK-GEN-3: The Certificate delivered by the dCDN and CSP must match the domain of the URL . As an example, it means that no certificate error occurs on the UA when the dCDN has redirected the UA a dCDN. LURK-GEN-4: The dCDN's surrogates which implements LURK interface should support the delivery of content of the protocol HTTPS. LURK-GEN-5: The dCDNs must be able to present the CSP certificate and credentials to the user agent when establishing a TLS session

LURK-CI-1: The CDNI Control Interface may allow the bootstrapping of a Key Server interface. For example this may include: - discovery the Key Server interface endpoint. - credentials for Key Server and CDN mutual authentication. - TLS version, Certificate types, TLS crypto suites. Proposal: add this requirement to the section CDNI Control Interface of .

LURK-FC-1: The CDNI Footprint and Capabilities Advertisement interface should allow the downstream CDN to communicate to the upstream CDN about its capabilities regarding the support of client side of the Key Server interface.

This section identifies additional requirements related to the CDNI Logging interface (LI). TLS-LI-1: the CDNI Logging interface should allow a dCDN to report to the uCDN logging for deliveries which fail during the establishment of the secure connection, e.g., ability to report certificate validation error. TLS-LI-2: The CDNI Logging interface should allow dCDN to report to uCDN logging incomplete deliveries due to encryption errors. Discussion: this requirement is mostly a subcase of LI-2 about incomplete deliveries. LURK-LI-3: the CDNI Logging interface should allow a dCDN to report to the uCDN secure connections failures when using LURK interface. As an example, the UA can’t establish a secure connection to a dCDN because either, the credentials provided by a Key Server are invalid, or because the Key Server has refused to provide them to the dCDN.

LURK-KS-1: A Key Server interface must not allow the exchange private keys. This is the centrality of the LURK interface. LURK-KS-2: The Key Server and the requesting CDN must authenticate each other, according to the information provided by the CDNI Control interface. LURK-KS-3: The dCDN Key Server interface must be able to send a LURK request to a Key Server. As an example (UC A, step 4), the dCDN surrogate determines ECDHE parameters (...), and requests the Key Server to sign these parameters with the CSP private key. The request includes the domain name received by the surrogate in the SNI field of the ClientHello.

HTTPS contents are delivered with the dCDN credentials. The introduction of a Key Server in the CDNI architecture allows the HTTPS content to be delivered with the CSP origin server certificate. It conforms to the end-to-end HTTPS framework .

CDNI WG and LURK WG should use a common set of cyphersuites, or CDNI WG should specify or points to the set of suites to support. TLS and HTTP2 recommend different set of cypher suites. CDNI WG should clarify which one should be supported in the case of a HTTPS delivery based on LURK credentials: HTTP2 Cipher Suite, refer to appendix A of and "backwards-compatibility-security-restrictions" in [I-D.draft-ietf-tls-tls13"].

Should the delivery be PFS proof?

Which version of TLS should be supported by LURK: TLS/LTS, TLS1.2, TLS1.3?

For each TLS session initialization on the dCDNs, the dCDNs need to request the KS to get the necessary credentials. To be scalable, the KS may need to be replicated.

At least one private key per CSP is stored on the KS. Therefore the use of a KS avoids the complexity of duplicating private keys on uncontrolled servers. This also allows the uCDN to maintain a single domain name for the CDN interconnection.

In the case of an HTTPS delegation revocation, a dCDN has no longer the delegation right to deliver a content for a given CSP. The uCDN would then deny access to CSP certificates and credentials derived from private keys, and therefore the dCDN would not be able to establish the TLS session without triggering a warning on UA Side.

The dCDN may have to retrieve at least once the CSP public certificate related to the targeted domain name. The certificates may be cached on the dCDN for a given duration. . Is certificate provisioning in the scope of CDNI as it seems implementation dependant? Which interface provides the certificates to the uCDN (Control, Metadata, LURK, ..)?

With regard to the use case B, the CSP may provide a Key server. As a consequence the requirement /GEN-3 should be updated accordingly.

Usage of the LURK interface when acquiring content: when the dCDN acquires content directly from the origin server, would it have to request first the KS to get the uCDN credentials ?

What should be carried by the CI or the MI ?

Not yet addressed in this document, contributors are welcome.

Contents might be delivered over other protocols than TCP and than HTTP/1.1 in a close future. The CDNI WG must discuss the support of HTTPS delivery over TLS/LTS, TLSv3, DTLS, QUIC and HTTP2.

This document has no IANA considerations.

The entire document is about security.

Many thanks to Benoit Gaussen who contributed to this draft.