Content Delivery Network Interconnection (CDNI) Metadata for Delegated CredentialsOrange40-48, avenue de la RépubliqueChâtillon92320Francefrederic.fieau@orange.comOrange2, avenue Pierre MarzinLannion22300Franceemile.stephan@orange.comBroadpeak3771 Boulevard des AlliésCesson-Sévigné35510Franceguillaume.bichot@broadpeak.tvBroadpeak3771 Boulevard des AlliésCesson-Sévigné35510Francechristoph.neumann@broadpeak.tv
WIT
cdniHTTPSTLS
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
.
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
() 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
. Introduction
. Terminology
. CDNI Footprint and Capabilities Advertisement Interface (FCI) Capabilities Object for Delegated Credentials
. FCI.DelegatedCredentials
. Expected Usage of the Property Number of Supported Delegated Credentials
. CDNI Metadata Interface (MI) Metadata Object for Delegated Credentials
. Delegated Credentials Call Flow
. IANA Considerations
. CDNI MI.DelegatedCredentials Payload Type
. CDNI FCI.DelegatedCredentials Payload Type
. Security Considerations
. Privacy Considerations
. References
. Normative References
. Informative References
Authors' Addresses
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 ,
between an upstream CDN (uCDN) and a 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 when, and only when, they appear in all capitals, as
shown here.
This document uses terminology from the CDNI specifications -- CDNI framework
, CDNI requirements , and CDNI
Metadata interface .
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 .
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.
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 ).
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 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 CredentialsThe 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.
CDNI Metadata Interface (MI) Metadata Object for Delegated CredentialsAs expressed in , when an uCDN has delegated to a dCDN, the dCDN presents the
"delegated_credential" (rather than its own certificate) during the TLS handshake 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 .
This allows the User Agent to verify the signature in a CertificateVerify message () 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 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 ) version of a CertificateEntry as defined in . The CertificateEntry MUST contain a DelegatedCredential structure (as defined in ) using the extension in the CertificateEntry of its end-entity certificate (see ).
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) using the base64 compact serialization ().
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 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 using the base64 compact serialization (), 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=="}
]
}
}
Delegated Credentials Call FlowAn example call-flow using delegated credentials is depicted in
. The steps are as follows.
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.
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.
Using the CDNI FCI , the
dCDN advertises MI.DelegatedCredentials capabilities to the uCDN.
The dCDN further uses FCI.DelegatedCredentials to advertise the maximum number
of supported delegated credentials.
Using the CDNI MI , the dCDN acquires
the MI.DelegatedCredentials, retrieving an array of delegated
credentials.
The client establishes a TLS connection with an endpoint of
the dCDN according to using the delegated
credentials retrieved in step 4.
When some delegated credentials are about to expire, the uCDN uses the CDNI MI 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.DelegatedCredentials object
| |<--------------------+
| | |
.
.
.
[5. TLS handshake according |
to [RFC9345]] . |
|<------------------->| |
| | |
.
.
.
| 6. Some delegated credentials about to expire.
| CDNI MI used to
| provide new MI.DelegatedCredentials object
| |<--------------------+
| | |
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
Sections and provide additional necessary information for the
registration of those CDNI payload types (see ).
CDNI MI.DelegatedCredentials Payload Type
Purpose:
The purpose of this payload type is to distinguish delegated
credentials MI objects.
Interface:
MI/FCI
Encoding:
See .
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 .
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 ) 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 .
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.
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 and
.
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.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]JSON Web Encryption (JWE)JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.JSON Web Key (JWK)A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.Content Delivery Network Interconnection (CDNI) MetadataThe Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics<p>This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.</p>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Delegated Credentials for TLS and DTLSThe organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.Informative ReferencesFramework for Content Distribution Network Interconnection (CDNI)This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466.Content Distribution Network Interconnection (CDNI) RequirementsContent delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.Content Delivery Network Interconnection (CDNI) Media Type RegistrationThis document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.Authors' AddressesOrange40-48, avenue de la RépubliqueChâtillon92320Francefrederic.fieau@orange.comOrange2, avenue Pierre MarzinLannion22300Franceemile.stephan@orange.comBroadpeak3771 Boulevard des AlliésCesson-Sévigné35510Franceguillaume.bichot@broadpeak.tvBroadpeak3771 Boulevard des AlliésCesson-Sévigné35510Francechristoph.neumann@broadpeak.tv