RFC 9677

Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials

📅 published October 2024, from ietf

RFC 9677: Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials 💖

Okay bestie, this one is about who holds the keys when content gets delivered over HTTPS through more than one CDN 🔐✨ Here's the header info:

  • Authors: F. Fieau, E. Stephan, G. Bichot and C. Neumann, from Orange and Broadpeak 🎀
  • Category: Standards Track 👑
  • ISSN: 2070-1721
  • Date: October 2024 🌸
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🦋

Abstract ✨

Okay so, delivering content over HTTPS when multiple Content Delivery Networks (CDNs) are involved gets messy with credentials 😭 This doc defines metadata in the CDNI Control and Metadata interface so an upstream CDN (uCDN) can set up HTTPS delegation for a downstream CDN (dCDN) using delegated credentials. It's giving teamwork 🫶

Status of This Memo 💅

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 🧚

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9677 🔥

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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 that uses one or more CDNs along the delivery path means you have to manage credentials 🔑 This gets especially important when an entity hands off HTTPS delivery of its content to another trusted entity 🤝

This document specifies the CDNI Metadata interface for setting up HTTPS delegation with 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 📖 (So only the all-caps versions count, lowercase ones are just regular words 💅)

This document uses terminology from the CDNI specifications: the CDNI framework [RFC7336], the CDNI requirements [RFC7337], and the 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 lets a dCDN share its capabilities and the Metadata interface (MI) objects it supports ✨ To say it supports delegated credentials, the dCDN should announce support for MI.DelegatedCredentials, like in the example below 🧚

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

There's also an object that tells the uCDN how many delegated credentials the dCDN supports, so the uCDN can hand over the right amount 🍓 That object is FCI.DelegationCredentials 🫶

3.1. FCI.DelegatedCredentials 🌈

The FCI.DelegationCredentials object lets a dCDN advertise the maximum number of delegated credentials it supports. That number usually (but not always) matches the number of servers the dCDN has set aside for delegated credentials 🖥️

The property PrivateKeyEncryptionKey holds a public key from the dCDN. The uCDN MUST use it to encrypt private keys whenever those private keys get sent to the dCDN using MI.DelegatedCredentials (see Section 4) 🔐 (yes, MUST, it's not optional bestie 😤)

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

Here's an example of 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 how many servers support delegated credentials 🌸

When the uCDN gets the FCI.DelegatedCredentials object, it can issue that many delegated credentials to the dCDN. When the uCDN configures the dCDN, it MAY decide to give the dCDN fewer than the maximum supported delegated credentials 🦋 Also, different deployment setups for delegated credentials on the endpoints are possible inside a dCDN. The dCDN MAY use one single delegated credential and deploy it on multiple endpoints 🧩 Or the dCDN MAY deploy a different delegated credential for each endpoint (as long as the uCDN delivers enough different delegated credentials) ✨ That choice belongs to the dCDN, and it depends on how many delegated credentials the uCDN provided 👑

FCI.DelegationCredentials doesn't cover expiry or renewal of delegated credentials. Once the uCDN has provided delegated credentials via the MI, the uCDN SHOULD keep an eye on them and their expiry times, and SHOULD refresh the dCDN's credentials via the MI in a timely way 👀 The uCDN may decide not to monitor the validity period or refresh the credentials, for example for short-term one-shot deployments, or once it has decided to deprovision a dCDN 🍂 But if the uCDN doesn't renew the delegated credential on time, the dCDN's servers that only have expired delegated credentials MUST refuse any new TLS connection that needs an up-to-date delegated credential 🚫 That's a hard no 💀

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

As described in [RFC9345], when a uCDN has delegated to a dCDN, the dCDN presents the "delegated_credential" (instead of its own certificate) during the TLS handshake [RFC8446] to the User Agent 🤝 That means the dCDN also has the private key that matches the public key in DelegatedCredential.cred [RFC9345] 🔑 This lets the User Agent verify the signature in a CertificateVerify message (Section 4.4.3 of [RFC8446]) that the dCDN sent and signed 💖

This section defines the MI.DelegatedCredentials object, which holds an array of delegated credentials and optionally the matching private keys 🎀 The CDNI MI [RFC8006] describes the CDNI metadata distribution mechanisms that let a dCDN fetch the MI.DelegatedCredentials object from the uCDN 🌈

The properties of the MI.DelegatedCredentials object are these 📜

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

The DelegatedCredentialObject object is made of these 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 isn't mandatory. If it isn't specified, it's assumed that the dCDN generated the public-private key pair for the delegated credential itself and gave the public key info to the uCDN through an out-of-band mechanism 🔍 See Section 7 for the constraints on using 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] with the base64 compact serialization (Section 7.1 of [RFC7516]), and the private key goes in as the JWE Ciphertext inside the JWE 🫧 The JWE content-type field MAY be used to signal the media type of the encrypted key 💜

Here's 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 ✨

okay so the call flow is where everything clicks 🧚 here's the step-by-step, and then there's a picture (Figure 1) that shows it all at once. 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. ⏰

Here's the picture, bestie 🦋

  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. Here's the table:

                 +==========================+===========+
                 | 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 💀

Okay, this section is serious, so let's go 🫶 The extensions defined here let you hand delegated credentials over to dCDNs. A delegated credential can only be used by a dCDN if it has the associated private key. Likewise, an attacker needs the private key to exploit a delegated credential and impersonate dCDN nodes. So leaking only the delegated credential, without the private key, is a limited security risk.

Delegated credentials and their associated private keys are short-lived (per default, the maximum validity period is set to 7 days in [RFC9345]), so a single leaked delegated credential with its private key is also a limited security risk. Still, it is NOT RECOMMENDED to send private keys through the MI. Leaving the private key out further limits the ways an attacker could exploit 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. That's a lot, so keep this one in mind 👀

9. References 📚

9.1. Normative References

9.2. Informative References

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
📦 where this page comes from