CDNI extensions for HTTPS delegation

CDNI extensions for HTTPS delegation Orange

40-48, avenue de la Republique Chatillon 92320 France frederic.fieau@orange.com

Orange

2, avenue Pierre Marzin Lannion 22300 France emile.stephan@orange.com

Verizon

13100 Columbia Pike Silver Spring MD 20904 United States of America sanjay.mishra@verizon.com

Applications and Real-Time Content Delivery Networks Interconnection HTTPS delegation ACME STAR This document defines metadata objects to support delegating the delivery of HTTPS content between two or more interconnected CDNs. Specifically, this document defines CDNI Metadata interface objects to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC9115. RFC 9115 allows delegating entity to remain in full control of the delegation and be able to revoke it any time and avoids the need to share private cryptographic key material between the involved entities. About This Document Status information for this document may be found at . Discussion of this document takes place on the Content Delivery Networks Interconnection Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Content delivery over HTTPS using two or more cooperating Content Delivery Networks (CDNs) along the path requires credential management, specifically when DNS-based redirection is used. In such case an upstream CDN (uCDN) needs to delegate its credentials to a downstream (dCDN) for content delivery. defines delegation methods that allow a uCDN on behalf of the content provider, the holder of the domain, to generate on-demand an X.509 certificate that binds the designated domain name with a key-pair owned by the dCDN. For further details, please refer to and . This document defines CDNI Metadata to make use of HTTPS delegation between a uCDN and a dCDN based on the mechanism specified in . Furthermore, it adds a delegation method to the "CDNI Payload Types" IANA registry. defines terminology used in this document. presents delegation metadata for the FCI interface. addresses the metadata for handling HTTPS delegation with the Metadata Interface. addresses IANA registry for delegation methods. covers the security considerations.

Terminology This document uses terminology from CDNI framework documents such as: CDNI framework document , CDNI requirements and CDNI interface specifications documents: CDNI Metadata interface and CDNI Footprint and capabilities . It also uses terminology from .

Advertising Delegation Metadata for CDNI through FCI The Footprint and Capabilities interface defined in allows a dCDN to send a FCI capability type object to a uCDN. The FCI.Metadata object allows a dCDN to advertise the capabilities regarding the supported delegation methods and their configuration. The following is an example of the supported delegated methods capability object for a dCDN implementing the ACME delegation method.

ACME Delegation Metadata for CDNI When a uCDN delegates a dCDN to deliver HTTPS traffic using DNS Redirection , the dCDN must use a certificate bound to the origin's name to successfully authenticate to the end-user (see also ). To that end, this section defines the AcmeDelegationMethod object which describes metadata for using the ACME delegation interface . The ACMEDelegationMethod applies to both ACME STAR delegation, which provides a delegation model based on short-term certificates with automatic renewal , and non-STAR delegation, which allows delegation between CDNs using long-term certificates . provides a high-level view of the combined CDNI and ACME delegation message flows to obtain STAR certificate bound to the origin's name.

ACMEDelegationMethod Object The ACMEDelegationMethod object allows a uCDN to both define STAR and non-STAR delegation objects depending on the delegation certificate validity. The ACMEDelegationMethod object is defined with several properties as shown below.

Property: ACME-delegation
- Description: a URL pointing at an ACME delegation object, either STAR or non-STAR, associated with the dCDN account on the uCDN ACME server (see for the details).
- Type: Source object, according to
- Mandatory-to-Specify: Yes
Property: TimeWindow
- Description: Validity period of the certificate. According to , TimeWindow is defined by defining "start" time of the window, and "end" time of the window. In case of STAR method, the "start" and "end" properties of the window must be understood respectively as the start-date and end-date of the certificate validity. In case of non-STAR method, the "start" and "end" properties of the window must be understood respectively as the notBefore and notAfter fields of the certificate.
- Type: TimeWindow
- Mandatory-to-Specify: Yes

In the case that the delegation is STAR-based, the following properties are mandatory to specify:

Property: Lifetime
- Description: See
- Type: Time, see
- Mandatory-to-Specify: Yes, only if a STAR delegation method is specified
Property: Lifetime-adjust
- Description: See
- Type: Time
- Mandatory-to-Specify: Yes, only if a STAR delegation method is specified

Examples The following example shows an ACMEDelegationMethod object for a STAR-based ACME delegation. The example below shows an ACMEDelegationMethod object for a non-STAR ACME delegation. The following is a complete example showing how a HostMatch and its Metadata related to a host hold associated delegation metadata.

HostMatch:

HostMetadata:

IANA Considerations This document requests the registration of the following entry under the "CDNI Payload Types" registry:

Payload Type	Specification
MI.ACMEDelegationMethod	RFCthis

RFC Editor: please replace RFCthis with the RFC number of this RFC and remove this note.

CDNI MI ACMEDelegationMethod Payload Type

Purpose:: The purpose of this Payload Type is to distinguish AcmeDelegationMethod MI objects (and any associated capability advertisement)
Interface:: MI
Encoding:: See

Security considerations Delegation metadata proposed here do not alter nor change Security Considerations as outlined in the following RFCs: An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates ; the CDNI Metadata and CDNI Footprint and Capabilities . The delegation objects properties such as the list of delegation objects mentioned in are critical. They should be protected by the proper/mandated encryption and authentication. Please refer to Sections 7.1, 7.2 and 7.4 of .

References Normative References Content Delivery Network Interconnection (CDNI) Metadata The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata. Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates. An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates This document defines a profile of the Automatic Certificate Management Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain an X.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party. A primary use case is that of a Content Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time. Importantly, this mechanism does not require any modification to the deployed TLS clients and servers. Informative References Framework for Content Distribution Network Interconnection (CDNI) This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. Content Distribution Network Interconnection (CDNI) Requirements Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.

Acknowledgments We would like to thank authors of the , Antonio Augustin Pastor Perales, Diego Lopez, Thomas Fossati and Yaron Sheffer. Additionally, our gratitude to Thomas Fossati who participated in the drafting, reviewing and giving his feedback in finalizing this document. We also thank CDNI, co-chair Kevin Ma for his continual review and feedback during the development of this document.