CDNI Metadata for Delegated Credentials
Frederic Fieau
Orange
40-48, avenue de la Republique
Chatillon
92320
France
frederic.fieau@orange.com
Emile Stephan
Orange
2, avenue Pierre Marzin
Lannion
22300
France
emile.stephan@orange.com
Guillaume Bichot
Broadpeak
15, rue Claude Chappe
Cesson-Sevigne
35510
France
guillaume.bichot@broadpeak.tv
Christoph Neumann
Broadpeak
15, rue Claude Chappe
Cesson-Sevigne
35510
France
christoph.neumann@broadpeak.tv
The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document defines metadata in the CDNI Control and Metadata interface to setup HTTPS delegation using delegated credentials from an Upstream CDN (uCDN) to a Downstream CDN (dCDN).

Introduction
Content delivery over HTTPS using one or more CDNs along the path requires credential management. This specifically applies when an entity delegates to another trusted entity delivery of content via HTTPS.
This document defines the CDNI Metadata interface to setup HTTPS delegation using delegated credentials (as defined by [RFC9345]) between an upstream CDN (uCDN) and downstream CDN (dCDN).

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 CDNI framework documents: CDNI framework document [RFC7336], CDNI requirements [RFC7337] and CDNI interface specifications documents: CDNI Metadata interface [RFC8006].

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 allows a dCDN to advertise its capabilities and the Metadata interface (MI) objects supported by the dCDN. Accordingly, to announce the support for delegated credentials, the dCDN should announce the support of MI.DelegatedCredentials as shown 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 announces to the delegating entity how many delegated credentials the downstream supports such that the delegating entity can provide the corresponding number of delegated credentials. For that purpose we introduce the FCI object FCI.DelegationCredentials.

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:
Base64-encoded (as defined in Section 4 of [RFC4648]) public key 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>
           ]
        }
      ]
    }

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 and renewal of delegated credentials. Once the uCDN has provided delegated credentials via the MI, uCDN SHOULD monitor the provided credentials and their expiry times. The uCDN SHOULD timely refresh dCDN credentials via the MI. 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 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.

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" during the TLS handshake [RFC8446] to the User Agent, instead of its own certificate. 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 CertificateVerify message ([RFC8446] Section 4.4.3.) 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 [RFC8446] Section 4.4.2. The CertificateEntry MUST contain a DelegatedCredential structure (as defined in [RFC9345]) using the extension in the CertificateEntry of its end-entity certificate (see [RFC9345] section 4.1.1)
Type:
string
Mandatory-to-Specify:
Yes
Property:
private-key
Description:
Encrypted and base64-encoded (as defined in Section 4 of [RFC4648]) private key corresponding to the public key contained in the DelegatedCredential
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. As discussed in Section 7, it is NOT RECOMMENDED to communicate private keys to the dCDN using MI.
If the private-key property is used, the transported private key MUST be encrypted using the PrivateKeyEncryptionKey specified in FCI.DelegatedCredentials. The base64 envelope format for this property MUST use JWE [RFC7516], whereas the private key is included as JWE Ciphertext in the JWE.
Below, please see an example MI.DelegatedCredential 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=="}
            ]
        }
    }

Delegated credentials call flow
An example call-flow using delegated credentials is depicted in Figure 1.
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., CSP) 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.

Example call-flow of Delegated credentials in CDNI

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.DelegatedCredential object
   |                     |<--------------------+
   |                     |                     |
                         .
                         .
                         .
  [5. TLS handshake according                  |
          to [RFC9345]]  .                     |
   |<------------------->|                     |
   |                     |                     |
                         .
                         .
                         .
   |              6.Some delegated credentials about to expire.
   |                   CDNI MI used to
   |             provide new MI.DelegatedCredential object
   |                     |<--------------------+
   |                     |                     |

IANA Considerations
This document requests IANA registration of the following entries under the "CDNI Payload Types" registry hosted by IANA regarding "CDNI delegation":
Payload Type | Specification
MI.DelegatedCredentials | RFCthis
FCI.DelegatedCredentials | RFCthis
[RFC Editor: Please replace RFCthis with the published RFC number for this document.]

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

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

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 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 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 possibility exploits by an attacker to exploit the delegated credential.
If despite this recommendation, 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. 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, confidentiality and ensuring the authenticity of the dCDN and uCDN, which should prevent an attacker to systematically retrieve delegated credential and associated private keys.

Privacy Considerations
The information, FCI, and MI objects 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 Consideration outlined in the CDNI Metadata and Footprint and Capabilities RFCs [RFC8006].
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.

Normative References
[RFC7516]

JSON Web Encryption (JWE)
M. Jones
J. Hildebrand
May 2015
RFC 7516
DOI 10.17487/RFC7516
[RFC8006]

Content Delivery Network Interconnection (CDNI) Metadata
B. Niven-Jenkins
R. Murray
M. Caulfield
K. Ma
December 2016
RFC 8006
DOI 10.17487/RFC8006
[RFC8008]

Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics
J. Seedorf
J. Peterson
S. Previdi
R. van Brandenburg
K. Ma
December 2016
RFC 8008
DOI 10.17487/RFC8008
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[RFC9345]

Delegated Credentials for TLS and DTLS
R. Barnes
S. Iyengar
N. Sullivan
E. Rescorla
July 2023
RFC 9345
DOI 10.17487/RFC9345
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC7336]

Framework for Content Distribution Network Interconnection (CDNI)
L. Peterson
B. Davie
R. van Brandenburg, Ed.
August 2014
RFC 7336
DOI 10.17487/RFC7336
[RFC7337]

Content Distribution Network Interconnection (CDNI) Requirements
K. Leung, Ed.
Y. Lee, Ed.
August 2014
RFC 7337
DOI 10.17487/RFC7337
[RFC4648]

The Base16, Base32, and Base64 Data Encodings
S. Josefsson
October 2006
RFC 4648
DOI 10.17487/RFC4648