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

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

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

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

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

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

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

Authors' Addresses