CDNI Metadata for Delegated Credentials

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 November 2023.¶

Copyright Notice

Copyright (c) 2023 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

This document uses terminology from CDNI framework documents: CDNI framework document [RFC7336], CDNI requirements [RFC7337] and CDNI interface specifications documents: CDNI Metadata interface [RFC8006] and CDNI Control interface / Triggers [RFC8007].¶

3. CDNI Footprint and Capabilities Advertisement interface (FCI) for delegated credentials

A dCDN should advertise its supported delegation methods using the Footprint and Capabilities interface (FCI) as defined in RFC8008. The FCI.Metadata object allows a dCDN to advertise its capabilities and the 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 below example.¶

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

There is also a need to announce additional parameters related to the number of credentials supported by the dCDN. For that purpose we introduce the FCI object FCI.DelegationCredentials.¶

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

4. CDNI Metadata interface (MI) for delegated credentials

As expressed in [draft-ietf-tls-subcerts], when an origin has set a delegation to a downstream entity such as a downstream CDN (i.e., dCDN), the dCDN presents the "delegated_credential" during the TLS handshake [RFC8446] to the end-user client application, 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 [draft-ietf-tls-subcerts]. This allows the end user client to verify the signature in 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 Metadata Interface [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 two properties:¶

Property:

delegated-credential¶

Description:

Base64-encoded delegated credential structure DelegatedCredential as defined in [draft-ietf-tls-subcerts]¶

Type:

string¶

Mandatory-to-Specify:

Yes¶

Property:

private-key¶

Description:

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

Find below 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=="}
        ]
    }
    }

5. Delegated credentials call flows

An example call-flow using delegated credentials in CDNI 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-pupose when dCDN announces its maximum number of required delegated crednetials.¶

3. Using CDNI Footprint and Capabilities interface [RFC8008], the dCDN advertises MI.DelegatedCredentials capabilities to the uCDN. The dCDN further uses FCI.DelegatedCredentials to inform on the maximum number of supported delegated credentials.¶

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

5. The client establishes a TLS connection with an endpoint of the dCDN according to [draft-ietf-tls-subcerts] using the delegated credentials retrieved in step 4.¶

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

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

6. IANA Considerations

This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA regarding "CDNI delegation":¶

[RFC Editor: Please replace RFCthis with the published RFC number for this document.]¶

7. Security Considerations

The extensions defined in the present document enable providing delegated credentials to dCDNs. A delegated credentials can only be used by a dCDN if it is in the 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.¶

The delegated credentials and associated private keys are short-lived and as such a single leaked delegated credential with its private key represents a limited security risk. Still, it is recommended not to send private keys through the MI as it further limits the possibility by attacker to exploit the delegated credential.¶

It is also important to ensure that an attacker is not able to systematically retrieve a more important number of delegated credentials and associated private keys. Such an attack would allow the attacker to systematically impersonate dCDN nodes. The FCI and 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.¶

8. Security 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].¶

Authors' Addresses