CDNI extensions for HTTPS delegation

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 https://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 26 April 2023.¶

Copyright Notice

Copyright (c) 2022 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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.¶

[RFC9115] 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 Section 1 of [RFC9115] and Section 5.1.2.1 of [RFC9115].¶

This document defines CDNI Metadata to make use of HTTPS delegation between a uCDN and a dCDN based on the mechanism specified in [RFC9115]. Furthermore, it adds a delegation method to the "CDNI Payload Types" IANA registry.¶

Section 1.1 defines terminology used in this document. Section 2 presents delegation metadata for the FCI interface. Section 3 addresses the metadata for handling HTTPS delegation with the Metadata Interface. Section 4 addresses IANA registry for delegation methods. Section 5 covers the security considerations.¶

2. Advertising Delegation Metadata for CDNI through FCI

The Footprint and Capabilities interface defined in [RFC8008] 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.¶

{
  "capabilities": [
    {
      "capability-type": "FCI.Metadata",
      "capability-value": {
        "metadata": [
          "ACMEDelegationMethod",
          "... Other supported delegation methods ..."
        ]
      },
      "footprints": [
        "Footprint objects"
      ]
    }
  ]
}

3. ACME Delegation Metadata for CDNI

When a uCDN delegates a dCDN to deliver HTTPS traffic using DNS Redirection [RFC7975], the dCDN must use a certificate bound to the origin's name to successfully authenticate to the end-user (see also Section 5.1.2.1 of [RFC9115]).¶

To that end, this section defines the AcmeDelegationMethod object which describes metadata for using the ACME delegation interface [RFC9115].¶

The ACMEDelegationMethod applies to both ACME STAR delegation, which provides a delegation model based on short-term certificates with automatic renewal Section 2.3.2 of [RFC9115], and non-STAR delegation, which allows delegation between CDNs using long-term certificates Section 2.3.3 of [RFC9115].¶

Figure 1 provides a high-level view of the combined CDNI and ACME delegation message flows to obtain STAR certificate bound to the origin's name.¶

Section 3.1 defines the objects used for bootstrapping the ACME delegation method between a uCDN and a delegate dCDN.¶

{
  "generic-metadata-type": "MI.ACMEDelegationMethod",
  "generic-metadata-value": {
    "ACME-delegation": "https://acme.ucdn.example/delegation/ogfr",
    "TimeWindow": {
      "start": "2022-10-10T00:00:00Z",
      "end": "2022-10-13T00:00:00Z"
    },
    "Lifetime": 345600,
    "Lifetime-adjust": 259200
  }
}

{
  "generic-metadata-type": "MI.ACMEDelegationMethod",
  "generic-metadata-value": {
    "ACME-delegation": "https://acme.ucdn.example/delegation/wSi5",
    "TimeWindow": {
      "start": "2019-01-10T00:00:00Z",
      "end": "2023-01-20T00:00:00Z"
    }
  }
}

{
  "host": "video.example.com",
  "host-metadata": {
    "type": "MI.HostMetadata",
    "href": "https://metadata.ucdn.example/host1234"
  }
}

{
  "paths": "/video",
  "metadata": [ // defining here a STAR delegation
    {
      "generic-metadata-type": "MI.ACMEDelegationMethod",
      "generic-metadata-value": {
        "ACME-delegation": "https://acme.ucdn.example/delegation/wSi5",
        "TimeWindow": {
          "start": "2019-01-10T00:00:00Z",
          "end": "2023-01-20T00:00:00Z"
        }
      }
    }
  ]
}

4. IANA Considerations

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

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

5. 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 [RFC9115]; the CDNI Metadata [RFC8006] and CDNI Footprint and Capabilities [RFC8008].¶

The delegation objects properties such as the list of delegation objects mentioned in Section 3are critical. They should be protected by the proper/mandated encryption and authentication. Please refer to Sections 7.1, 7.2 and 7.4 of [RFC9115].¶

Acknowledgments

We would like to thank authors of the [RFC9115], 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.¶

Authors' Addresses