Skip to main content

CDNI delegation using Automated Certificate Management Environment
draft-ietf-cdni-delegation-acme-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9538.
Authors Frédéric Fieau , Stephan Emile , Sanjay Mishra
Last updated 2024-01-23 (Latest revision 2023-12-07)
Replaces draft-ietf-cdni-interfaces-https-delegation
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Kevin J. Ma
Shepherd write-up Show Last changed 2023-09-02
IESG IESG state Became RFC 9538 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Francesca Palombini
Send notices to kevin.j.ma.ietf@gmail.com
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
IANA expert review state Expert Reviews OK
RFC Editor RFC Editor state AUTH48
Details
draft-ietf-cdni-delegation-acme-04
Content Delivery Networks Interconnection                  F. Fieau, Ed.
Internet-Draft                                                E. Stephan
Intended status: Standards Track                                  Orange
Expires: 9 June 2024                                           S. Mishra
                                                                 Verizon
                                                         7 December 2023

   CDNI delegation using Automated Certificate Management Environment
                   draft-ietf-cdni-delegation-acme-04

Abstract

   This document defines metadata to support delegating the delivery of
   HTTPS content between two or more interconnected Content Delivery
   Networks (CDNs).  Specifically, this document defines a Content
   Delivery Network Interconnection (CDNI) Metadata interface object to
   enable delegation of X.509 certificates leveraging delegation schemes
   defined in RFC9115.  RFC9115 allows delegating entities to remain in
   full control of the delegation and be able to revoke it any time and
   this avoids the need to share private cryptographic key material
   between the involved entities.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-cdni-delegation-acme/.

   Discussion of this document takes place on the Content Delivery
   Networks Interconnection Working Group mailing list
   (mailto:cdni@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/cdni/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/cdni/.

   Source for this draft and an issue tracker can be found at
   https://github.com/FredericFi/cdni-wg.

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/.

Fieau, et al.              Expires 9 June 2024                  [Page 1]
Internet-Draft         CDNI delegation using ACME          December 2023

   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 9 June 2024.

Copyright Notice

   Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Advertising Delegation Metadata for CDNI through FCI  . . . .   3
   3.   ACME Delegation Metadata for CDNI  . . . . . . . . . . . . .   4
     3.1.  ACMEDelegationMethod Object . . . . . . . . . . . . . . .   6
       3.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   7
   4.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   8
     4.1.  CDNI MI ACMEDelegationMethod Payload Type . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.   Introduction

   Content delivery over HTTPS using two or more cooperating CDNs along
   the path requires credential management, specifically when DNS-based
   redirection is used.  In such cases, an upstream CDN (uCDN) needs to
   delegate its credentials to a downstream (dCDN) for content delivery.

Fieau, et al.              Expires 9 June 2024                  [Page 2]
Internet-Draft         CDNI delegation using ACME          December 2023

   [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 2 presents delegation metadata for the Footprint &
   Capabilities Advertisement interface (FCI).  Section 3 addresses the
   metadata for handling HTTPS delegation with the Metadata Interface.

1.1.  Terminology

   This document uses terminology from CDNI framework documents such as:
   CDNI framework document [RFC7336] and CDNI interface specifications
   documents: CDNI Metadata interface [RFC8006] and CDNI Footprint and
   Capabilities Advertisement interface [RFC8008].  It also uses
   terminology from Section 1.2 of [RFC8739] and Section 1.1 of
   [RFC9115].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Advertising Delegation Metadata for CDNI through FCI

   The Footprint and Capabilities Advertisement interface (FCI) defined
   in [RFC8008] allows a dCDN to send a FCI capability type object to a
   uCDN.

   This document uses the CDNI Metadata capability object serialization
   from [RFC8008] for a CDN that supports delegation methods.

   The following is an example of the supported delegated methods
   capability object for a dCDN implementing the ACME delegation method.

Fieau, et al.              Expires 9 June 2024                  [Page 3]
Internet-Draft         CDNI delegation using ACME          December 2023

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

3.   ACME Delegation Metadata for CDNI

   When a uCDN delegates the delivery of HTTPS traffic to a dCDN using
   DNS Redirection [RFC7336], 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 from the
   Certificate Authority (CA) bound to the Content Provider's (CP) name.

Fieau, et al.              Expires 9 June 2024                  [Page 4]
Internet-Draft         CDNI delegation using ACME          December 2023

.----.                .----.               .----.                 .----.
|dCDN|                |uCDN|               | CP |                 | CA |
'-+--'                '-+--'               '--+-'                 '--+-'
  |     GET metadata    |                     |                      |
  +--------[CDNI]------>|                     |                      |
  |   200 OK, metadata  |                     |                      |
  |  (inc. dele config) |                     |                      |
  |<-------[CDNI]-------+                     |                      |
  |                     |                     |                      |
  |    GET delegation   |                     |                      |
  +-----[ACME dele]---->|                     |                      |
  | 200 OK, delegation  |                     |                      |
  | (inc. CSR template) |                     |                      |
  |<----[ACME dele]-----+                     |                      |
  |                     |                     |                      |
  +----.                |                     |                      |
  |    |                |                     |                      |
  |  create key pair and|                     |                      |
  |  CSR w/ delegated   |                     |                      |
  |  name               |                     |                      |
  |    |                |                     |                      |
  |<---'                |                     |                      |
  |                     |                     |                      |
  |     POST Order1     |                     |                      |
  +-----[ACME dele]---->|                     |                      |
  |                     |   forward Order1    |                      |
  |                     +-----[ACME dele]---->|                      |
  |                     |                     |     POST Order2      |
  |                     |                     +-----[ACME STAR]----->|
  |                     |                     |                      |
  |                     |                     |<---authorizations--->|
  |                     |                     |                      |
  |<---wait issuance--->|<---wait issuance--->|<---wait issuance---->|
  |                                                                  |
  |              (unauthenticated) GET star-certificate              |
  +----------------------------------------------------------------->|
  |                          certificate #1                          |
  |<-----------------------------------------------------------------+
  |                              ...                                 |

   Figure 1: Example call-flow of STAR delegation in CDNI showing 2
                         levels of delegation

      |  Note: The delegation object defined in Section 2.3.1.3 of
      |  [RFC9115] only allows to specify DNS mappings using CNAME RRs.
      |  A future document updating [RFC9115] could expand the
      |  delegation object to also include SVCB/HTTPS-based [RFC9460]
      |  mappings.

Fieau, et al.              Expires 9 June 2024                  [Page 5]
Internet-Draft         CDNI delegation using ACME          December 2023

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

3.1.  ACMEDelegationMethod Object

   The ACMEDelegationMethod object allows a uCDN to define both STAR and
   non-STAR delegation.  The dCDN, the consumer of the delegation, can
   determine the type of delegation by the presence (or absence) of the
   "lifetime" property.  That is, the presence of the "lifetime"
   property explicitly means a short-term delegation with lifetime of
   the certificate based on that property (and the optional "lifetime-
   adjust" attribute).  A non-STAR delegation will not have the
   "lifetime" property in the delegation.  See also the examples in
   Section 3.1.1.

   The ACMEDelegationMethod object is defined with the properties 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 Section 2.3.1.3 of [RFC9115] for the
         details).  The URL MUST use the https scheme.

      -  Type: String

      -  Mandatory-to-Specify: Yes

   *  Property: time-window

      -  Description: Validity period of the certificate.  According to
         Section 4.3.4 of [RFC8006], a TimeWindow object is defined by a
         window "start" time, and a window "end" time.  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 the case of the 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

   *  Property: lifetime

      -  Description: See lifetime in Section 3.1.1 of [RFC8739]

Fieau, et al.              Expires 9 June 2024                  [Page 6]
Internet-Draft         CDNI delegation using ACME          December 2023

      -  Type: Integer

      -  Mandatory-to-Specify: Yes, only if a STAR delegation method is
         specified

   *  Property: lifetime-adjust

      -  Description: See lifetime-adjust in Section 3.1.1 of [RFC8739]

      -  Type: Integer

      -  Mandatory-to-Specify: No

3.1.1.  Examples

   The following example shows an ACMEDelegationMethod object for a
   STAR-based ACME delegation.

   {
     "generic-metadata-type": "MI.ACMEDelegationMethod",
     "generic-metadata-value": {
       "acme-delegation": "https://acme.ucdn.example/delegation/ogfr",
       "time-window": {
         "start": 1665417434,
         "end": 1665676634
       },
       "lifetime": 345600,
       "lifetime-adjust": 259200
     }
   }

   The example below shows an ACMEDelegationMethod object for a non-STAR
   ACME delegation.  The delegation object is defined as per Section 4.3
   of [RFC8006].

   {
     "generic-metadata-type": "MI.ACMEDelegationMethod",
     "generic-metadata-value": {
       "acme-delegation": "https://acme.ucdn.example/delegation/wSi5",
       "time-window": {
         "start": 1570982234,
         "end": 1665417434
       }
     }
   }

Fieau, et al.              Expires 9 June 2024                  [Page 7]
Internet-Draft         CDNI delegation using ACME          December 2023

4.   IANA Considerations

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

                +=========================+===============+
                | Payload Type            | Specification |
                +=========================+===============+
                | MI.ACMEDelegationMethod | RFCthis       |
                +-------------------------+---------------+

                                  Table 1

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

4.1.  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/FCI

   Encoding:  See Section 3.1

5.  Security Considerations

   The metadata object defined in this document does not introduce any
   new security or privacy concerns over those already discussed in
   [RFC9115], [RFC8006] and [RFC8008].

   The reader is expected to understand the ACME delegation trust model
   (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
   [RFC9115]), in particular the criticality around the protection of
   the user account associated with the delegation, which authorizes all
   the security relevant operations between dCDN and uCDN over the ACME
   channel.  The dCDN's ACME account is also relevant to the privacy of
   the entire scheme; for example, the acme-delegation resource in the
   Metadata object is only accessible to the holder of the account key,
   who is allowed to fetch its content exclusively via POST-as-GET
   (Section 2.3.1.2 of [RFC9115]).

   In addition, the Metadata interface authentication and
   confidentiality requirements defined in Section 8 of [RFC8006] MUST
   be followed.

Fieau, et al.              Expires 9 June 2024                  [Page 8]
Internet-Draft         CDNI delegation using ACME          December 2023

   Implementers MUST adhere to the security considerations defined in
   the CDNI Request Routing: Footprint and Capabilities Semantics,
   Section 7 of [RFC8008].

   When TLS is used to achieve the above security objectives, the
   general TLS usage guidance in [RFC9325] MUST be followed.

6.  References

6.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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8006]  Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "Content Delivery Network Interconnection (CDNI)
              Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
              <https://www.rfc-editor.org/rfc/rfc8006>.

   [RFC8008]  Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
              R., and K. Ma, "Content Delivery Network Interconnection
              (CDNI) Request Routing: Footprint and Capabilities
              Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
              <https://www.rfc-editor.org/rfc/rfc8008>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8739]  Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor
              Perales, A., and T. Fossati, "Support for Short-Term,
              Automatically Renewed (STAR) Certificates in the Automated
              Certificate Management Environment (ACME)", RFC 8739,
              DOI 10.17487/RFC8739, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8739>.

   [RFC9115]  Sheffer, Y., López, D., Pastor Perales, A., and T.
              Fossati, "An Automatic Certificate Management Environment
              (ACME) Profile for Generating Delegated Certificates",
              RFC 9115, DOI 10.17487/RFC9115, September 2021,
              <https://www.rfc-editor.org/rfc/rfc9115>.

Fieau, et al.              Expires 9 June 2024                  [Page 9]
Internet-Draft         CDNI delegation using ACME          December 2023

   [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/rfc/rfc9325>.

6.2.  Informative References

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <https://www.rfc-editor.org/rfc/rfc7336>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

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

   Frédéric Fieau (editor)
   Orange
   40-48, avenue de la Republique
   92320 Chatillon
   France
   Email: frederic.fieau@orange.com

   Emile Stephan
   Orange
   2, avenue Pierre Marzin
   22300 Lannion
   France
   Email: emile.stephan@orange.com

Fieau, et al.              Expires 9 June 2024                 [Page 10]
Internet-Draft         CDNI delegation using ACME          December 2023

   Sanjay Mishra
   Verizon
   13100 Columbia Pike
   Silver Spring,  MD 20904
   United States of America
   Email: sanjay.mishra@verizon.com

Fieau, et al.              Expires 9 June 2024                 [Page 11]