path: root/doc/rfc/rfc9677.txt

Internet Engineering Task Force (IETF)                          F. Fieau
Request for Comments: 9677                                    E. Stephan
Category: Standards Track                                         Orange
ISSN: 2070-1721                                                G. Bichot
                                                              C. Neumann
                                                               Broadpeak
                                                            October 2024


 Content Delivery Network Interconnection (CDNI) Metadata for Delegated
                              Credentials

Abstract

   The delivery of content over HTTPS involving multiple Content
   Delivery Networks (CDNs) raises credential management issues.  This
   document defines metadata in the Content Delivery Network
   Interconnection (CDNI) Control and Metadata interface to set up HTTPS
   delegation using delegated credentials from an upstream CDN (uCDN) to
   a downstream CDN (dCDN).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9677.

Copyright Notice

   Copyright (c) 2024 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.  Terminology
   3.  CDNI Footprint and Capabilities Advertisement Interface (FCI)
           Capabilities Object for Delegated Credentials
     3.1.  FCI.DelegatedCredentials
     3.2.  Expected Usage of the Property Number of Supported
           Delegated Credentials
   4.  CDNI Metadata Interface (MI) Metadata Object for Delegated
           Credentials
   5.  Delegated Credentials Call Flow
   6.  IANA Considerations
     6.1.  CDNI MI.DelegatedCredentials Payload Type
     6.2.  CDNI FCI.DelegatedCredentials Payload Type
   7.  Security Considerations
   8.  Privacy Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Authors' Addresses

1.  Introduction

   Content delivery over HTTPS utilizing one or more Content Delivery
   Networks (CDNs) along the delivery path necessitates the management
   of credentials.  This requirement is particularly pertinent when an
   entity delegates the delivery of content via HTTPS to another trusted
   entity.

   This document specifies the CDNI Metadata interface for establishing
   HTTPS delegation through the use of delegated credentials, as defined
   in [RFC9345], between an upstream CDN (uCDN) and a downstream CDN
   (dCDN).

2.  Terminology

   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.

   This document uses terminology from the CDNI specifications -- CDNI
   framework [RFC7336], CDNI requirements [RFC7337], and CDNI Metadata
   interface [RFC8006].

3.  CDNI Footprint and Capabilities Advertisement Interface (FCI)
    Capabilities Object for Delegated Credentials

   A dCDN should advertise its supported delegation methods using the
   Footprint and Capabilities Advertisement interface (FCI) as defined
   in [RFC8008].  The FCI.Metadata object enables a dCDN to communicate
   its capabilities and the Metadata interface (MI) objects it supports.
   To indicate support for delegated credentials, the dCDN should
   announce the support for MI.DelegatedCredentials, as illustrated in
   the example below.

      {
        "capabilities": [
          {
            "capability-type": "FCI.Metadata",
            "capability-value": {
              "metadata": [
                "MI.DelegatedCredentials",
                "... other supported MI objects ..."
              ]
            },
            "footprints": [
              "Footprint objects"
            ]
          }
        ]
      }

   This document also defines an object that informs the uCDN of the
   number of delegated credentials supported by the dCDN, enabling the
   uCDN to supply the appropriate number of delegated credentials.  To
   this end, the FCI object, FCI.DelegationCredentials, is introduced.

3.1.  FCI.DelegatedCredentials

   The FCI.DelegationCredentials object enables advertising the maximum
   number of delegated credentials supported by the dCDN.  This number
   typically (but not necessarily) corresponds to the number of servers
   designated by the dCDN to support delegated credentials.

   The property PrivateKeyEncryptionKey contains a public key provided
   by the dCDN that MUST be used by the uCDN to encrypt private keys
   whenever such private keys are transmitted to the dCDN using
   MI.DelegatedCredentials (see Section 4).

   Property:  number-delegated-certs-supported
   Description:  Number of delegated credentials supported by the dCDN.
   Type:  integer
   Mandatory-to-Specify:  Yes

   Property:  PrivateKeyEncryptionKey
   Description:  Public key in JSON Web Key (JWK) format [RFC7517] of
      the dCDN to be used by the uCDN to encrypt private keys.
   Type:  string
   Mandatory-to-Specify:  No

   The following is an example of the FCI.DelegatedCredentials.

       {
         "capabilities": [
           {
            "capability-type": "FCI.DelegatedCredentials",
            "capability-value": {
               "number-delegated-certs-supported": 10
              }
            "footprints": [
               <Footprint objects>
              ]
           }
         ]
       }

3.2.  Expected Usage of the Property Number of Supported Delegated
      Credentials

   The dCDN uses the FCI.DelegatedCredentials object to announce the
   number of servers that support delegated credentials.

   When the uCDN receives the FCI.DelegatedCredentials object, it can
   issue the supported number of delegated credentials to the dCDN.
   When configuring the dCDN, the uCDN MAY decide to provide less than
   the maximum supported delegated credentials to the dCDN.  Note that,
   within a dCDN, different deployment possibilities of the delegated
   credentials on the endpoints exist.  The dCDN MAY use one single
   delegated credential and deploy it on multiple endpoints.
   Alternatively, the dCDN MAY deploy a different delegated credential
   for each endpoint (provided that the uCDN delivers enough different
   delegated credentials).  This choice is at the discretion of the dCDN
   and depends on the number of delegated credentials provided by the
   uCDN.

   The FCI.DelegationCredentials object does not address expiry or
   renewal of delegated credentials.  Once the uCDN has provided
   delegated credentials via the MI, the uCDN SHOULD monitor the
   provided credentials and their expiry times and SHOULD refresh dCDN
   credentials via the MI in a timely manner.  The uCDN may decide not
   to monitor the validity period of delegated credentials and not to
   refresh the credentials, for example, in cases of short-term one-shot
   deployments or once it has decided to deprovision a dCDN.  If the
   delegated credential is not renewed on time by the uCDN, the servers
   of the dCDN that only have expired delegated credentials MUST refuse
   any new TLS connection that requires an up-to-date delegated
   credential.

4.  CDNI Metadata Interface (MI) Metadata Object for Delegated
    Credentials

   As expressed in [RFC9345], when an uCDN has delegated to a dCDN, the
   dCDN presents the "delegated_credential" (rather than its own
   certificate) during the TLS handshake [RFC8446] to the User Agent.
   This implies that the dCDN is also in the possession of the private
   key corresponding to the public key in DelegatedCredential.cred
   [RFC9345].  This allows the User Agent to verify the signature in a
   CertificateVerify message (Section 4.4.3 of [RFC8446]) sent and
   signed by the dCDN.

   This section defines the MI.DelegatedCredentials object containing an
   array of delegated credentials and optionally the corresponding
   private keys.  The CDNI MI [RFC8006] describes the CDNI metadata
   distribution mechanisms according to which a dCDN can retrieve the
   MI.DelegatedCredentials object from the uCDN.

   The properties of the MI.DelegatedCredentials object are as follows:

   Property:  delegated-credentials
   Description:  Array of delegated credentials
   Type:  Array of DelegatedCredentialObject objects
   Mandatory-to-Specify:  Yes

   The DelegatedCredentialObject object is composed of the following
   properties:

   Property:  delegated-credential
   Description:  Base64-encoded (as defined in Section 4 of [RFC4648])
      version of a CertificateEntry as defined in Section 4.4.2 of
      [RFC8446].  The CertificateEntry MUST contain a
      DelegatedCredential structure (as defined in [RFC9345]) using the
      extension in the CertificateEntry of its end-entity certificate
      (see Section 4.1.1 of [RFC9345]).
   Type:  string
   Mandatory-to-Specify:  Yes

   Property:  private-key
   Description:  Encrypted private key corresponding to the public key
      contained in the DelegatedCredential.  The envelope format for
      this property is JSON Web Encryption (JWE) [RFC7516] using the
      base64 compact serialization (Section 7.1 of [RFC7516]).
   Type:  string
   Mandatory-to-Specify:  No

   The private-key property is not mandatory.  If not specified, it is
   assumed that the dCDN generated the public-private key pair for the
   delegated credential itself and provided the public key information
   with an out-of-band mechanism to the uCDN.  See Section 7 for
   constraints regarding the usage of the private key.

   If the private-key property is used, the transported private key MUST
   be encrypted using the PrivateKeyEncryptionKey specified in
   FCI.DelegatedCredentials.  The envelope format for this property MUST
   use JWE [RFC7516] using the base64 compact serialization (Section 7.1
   of [RFC7516]), whereas the private key is included as JWE Ciphertext
   in the JWE.  The JWE content-type field MAY be used to signal the
   media type of the encrypted key.

   Below, please see an example of an MI.DelegatedCredentials object.

       {
       "generic-metadata-type": "MI.DelegatedCredentials",
       "generic-metadata-value": {
           "delegated-credentials": [
                   {"delegated-credential":
                       "cBBfm8KK6pPz/tdgKyedwA...
                       iXCCIAmzMM0R8FLI3Ba0UQ=="},
                   {"delegated-credential":
                       "4pyIGtjFdys1+9y/4sS/Fg...
                       J+h9lnRY/xgmi65RLGKoRw=="},
                   {"delegated-credential":
                       "6PWFO0g2AXvUaULXLObcVA...
                       HXoldT/qaYCCNEyCc8JM2A=="}
               ]
           }
       }

5.  Delegated Credentials Call Flow

   An example call-flow using delegated credentials is depicted in
   Figure 1.  The steps are as follows.

   1.  It is assumed that the uCDN has been provisioned and configured
       with a certificate.  Note that it is out of scope of CDNI and the
       present document how and from where (e.g., which Content Service
       Provider) the uCDN acquired its certificate.

   2.  The uCDN generates a set of delegated credentials (here it is
       assumed that public keys of the dCDN are known).  Note that the
       uCDN may generate this material at different points in time,
       e.g., in advance to have a pool of delegated credentials or on
       demand when the dCDN announces its maximum number of supported
       delegated credentials.

   3.  Using the CDNI FCI [RFC8008], the dCDN advertises
       MI.DelegatedCredentials capabilities to the uCDN.  The dCDN
       further uses FCI.DelegatedCredentials to advertise the maximum
       number of supported delegated credentials.

   4.  Using the CDNI MI [RFC8006], the dCDN acquires the
       MI.DelegatedCredentials, retrieving an array of delegated
       credentials.

   5.  The client establishes a TLS connection with an endpoint of the
       dCDN according to [RFC9345] using the delegated credentials
       retrieved in step 4.

   6.  When some delegated credentials are about to expire, the uCDN
       uses the CDNI MI [RFC8006] to provide new, valid delegated
       credentials.

     User-Agent                  dCDN                 uCDN
        |                     |                     |
        |                     |      [1. uCDN acquires its certificate
        |                     |            out of scope of CDNI]
        |                     |                     |
        |                     |             [2. generation of
        |                     |          delegated credentials]
        |                     |                     |
        |                  3. CDNI FCI used to
        |              advertise support of MI.DelegatedCredentials
        |              and announce number of delegated credentials
        |                 supported using FCI.DelegatedCredentials
        |                     |-------------------->+
        |                     |                     |
        |                 4. CDNI MI used to
        |             provide the MI.DelegatedCredentials object
        |                     |<--------------------+
        |                     |                     |
                              .
                              .
                              .
       [5. TLS handshake according                  |
               to [RFC9345]]  .                     |
        |<------------------->|                     |
        |                     |                     |
                              .
                              .
                              .
        |              6. Some delegated credentials about to expire.
        |                    CDNI MI used to
        |             provide new MI.DelegatedCredentials object
        |                     |<--------------------+
        |                     |                     |

        Figure 1: Example Call Flow of Delegated Credentials in CDNI

6.  IANA Considerations

   IANA has registered the following payload types in the "CDNI Payload
   Types" registry in the "Content Delivery Network Interconnection
   (CDNI) Parameters" registry group.

                 +==========================+===========+
                 | Payload Type             | Reference |
                 +==========================+===========+
                 | MI.DelegatedCredentials  | RFC 9677  |
                 +--------------------------+-----------+
                 | FCI.DelegatedCredentials | RFC 9677  |
                 +--------------------------+-----------+

                                 Table 1

   Sections 6.1 and 6.2 provide additional necessary information for the
   registration of those CDNI payload types (see Section 2.2 of
   [RFC7736]).

6.1.  CDNI MI.DelegatedCredentials Payload Type

   Purpose:  The purpose of this payload type is to distinguish
      delegated credentials MI objects.

   Interface:  MI/FCI

   Encoding:  See Section 4.

6.2.  CDNI FCI.DelegatedCredentials Payload Type

   Purpose:  The purpose of this payload type is to advertise the number
      of delegated credentials needed (and any associated capability
      advertisement).

   Interface:  FCI

   Encoding:  See Section 3.1.

7.  Security Considerations

   The extensions defined enable providing delegated credentials to
   dCDNs.  A delegated credential can only be used by a dCDN if it is in
   possession of the associated private key.  Similarly, an attacker
   requires access to the private key in order to exploit a delegated
   credential and impersonate dCDN nodes.  Thus, leakage of only the
   delegated credential without the private key represents a limited
   security risk.

   Delegated credentials and associated private keys are short-lived
   (per default, the maximum validity period is set to 7 days in
   [RFC9345]) and as such a single leaked delegated credential with its
   private key represents a limited security risk.  Still, it is NOT
   RECOMMENDED to send private keys through the MI.  Omitting the
   private key further limits the possible ways an attacker could
   exploits the delegated credential.

   If this recommendation is not followed, i.e., the private key is
   communicated via the MI, the transported private key MUST be
   encrypted within a JWE envelope using the encryption key
   (PrivateKeyEncryptionKey) provided within the
   FCI.DelegatedCredentials by the dCDN.  The JWE encryption key
   (PrivateKeyEncryptionKey) MUST have a strength equal to or larger
   than the private key it is encrypting for transport.  Note that the
   specified encryption method does not offer forward secrecy.  If the
   dCDN's encryption key becomes compromised in the future, then all
   encrypted JWEs will become compromised.  Due to the short-lived
   nature of delegated credentials, the impact is limited.

   It is also important to ensure that an attacker is not able to
   systematically retrieve a consecutive or consistent set of delegated
   credentials and associated private keys.  Such an attack would allow
   the attacker to systematically impersonate dCDN nodes.  The MI
   objects defined in the present document are transferred via the
   interfaces defined in CDNI [RFC8006].  [RFC8006] describes how to
   secure these interfaces, protecting the integrity and
   confidentiality, as well as ensuring the authenticity of the dCDN and
   uCDN, which should prevent an attacker from systematically retrieving
   delegated credentials and associated private keys.

8.  Privacy Considerations

   The FCI and MI objects and the information defined in the present
   document do not contain any personally identifiable information
   (PII).  As such, this document does not change or alter the
   confidentiality and privacy considerations outlined in Section 8.2 of
   [RFC8006] and Section 7 of [RFC8008].

   A single or systematic retrieval of delegated credentials and
   associated private keys would allow the attacker to decrypt any data
   sent by the end user intended for the end service, which may include
   PII.

9.  References

9.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/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [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/info/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/info/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/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9345]  Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
              "Delegated Credentials for TLS and DTLS", RFC 9345,
              DOI 10.17487/RFC9345, July 2023,
              <https://www.rfc-editor.org/info/rfc9345>.

9.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/info/rfc7336>.

   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <https://www.rfc-editor.org/info/rfc7337>.

   [RFC7736]  Ma, K., "Content Delivery Network Interconnection (CDNI)
              Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
              December 2015, <https://www.rfc-editor.org/info/rfc7736>.

Authors' Addresses

   Frédéric Fieau
   Orange
   40-48, avenue de la République
   92320 Châtillon
   France
   Email: frederic.fieau@orange.com


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


   Guillaume Bichot
   Broadpeak
   3771 Boulevard des Alliés
   35510 Cesson-Sévigné
   France
   Email: guillaume.bichot@broadpeak.tv


   Christoph Neumann
   Broadpeak
   3771 Boulevard des Alliés
   35510 Cesson-Sévigné
   France
   Email: christoph.neumann@broadpeak.tv