CDNI Metadata for Delegated Credentials
draft-ietf-cdni-https-delegation-subcerts-09

Network Working Group                                           F. Fieau
Internet-Draft                                                E. Stephan
Intended status: Standards Track                                  Orange
Expires: 2 January 2025                                     G. Guillaume
                                                            C. Christoph
                                                               Broadpeak
                                                             1 July 2024

                CDNI Metadata for Delegated Credentials
              draft-ietf-cdni-https-delegation-subcerts-09

Abstract

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

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 2 January 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Fieau, et al.            Expires 2 January 2025                 [Page 1]
Internet-Draft              RFC XML Examples                   July 2024

   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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  CDNI Footprint and Capabilities Advertisement interface (FCI)
           capabilities object for delegated credentials . . . . . .   3
     3.1.  FCI.DelegatedCredentials  . . . . . . . . . . . . . . . .   3
     3.2.  Expected usage of the property number of supported
           delegated credentials . . . . . . . . . . . . . . . . . .   4
   4.  CDNI Metadata interface (MI) metadata object for delegated
           credentials . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Delegated credentials call flow . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  CDNI MI DelegatedCredentials Payload Type . . . . . . . .   9
     6.2.  CDNI FCI DelegatedCredentials Payload Type  . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  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).

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.

Fieau, et al.            Expires 2 January 2025                 [Page 2]
Internet-Draft              RFC XML Examples                   July 2024

   This document uses terminology from CDNI framework documents: CDNI
   framework document [RFC7336], CDNI requirements [RFC7337] and CDNI
   interface specifications documents: 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 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.

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

Fieau, et al.            Expires 2 January 2025                 [Page 3]
Internet-Draft              RFC XML Examples                   July 2024

   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>
              ]
           }
         ]
       }

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

Fieau, et al.            Expires 2 January 2025                 [Page 4]
Internet-Draft              RFC XML Examples                   July 2024

   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.

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

Fieau, et al.            Expires 2 January 2025                 [Page 5]
Internet-Draft              RFC XML Examples                   July 2024

      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.

Fieau, et al.            Expires 2 January 2025                 [Page 6]
Internet-Draft              RFC XML Examples                   July 2024

       {
       "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.

   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.

Fieau, et al.            Expires 2 January 2025                 [Page 7]
Internet-Draft              RFC XML Examples                   July 2024

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

        Figure 1: Example call-flow of Delegated credentials in CDNI

6.  IANA Considerations

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

Fieau, et al.            Expires 2 January 2025                 [Page 8]
Internet-Draft              RFC XML Examples                   July 2024

               +--------------------------+---------------+
               | Payload Type             | Specification |
               +--------------------------+---------------+
               | MI.DelegatedCredentials  | RFCthis       |
               +--------------------------+---------------+
               | FCI.DelegatedCredentials | RFCthis       |
               +--------------------------+---------------+

                                 Table 1

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

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

   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.

Fieau, et al.            Expires 2 January 2025                 [Page 9]
Internet-Draft              RFC XML Examples                   July 2024

   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.

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

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Fieau, et al.            Expires 2 January 2025                [Page 10]
Internet-Draft              RFC XML Examples                   July 2024

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <https://www.rfc-editor.org/info/rfc7336>.

   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <https://www.rfc-editor.org/info/rfc7337>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC8006]  Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "Content Delivery Network Interconnection (CDNI)
              Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
              <https://www.rfc-editor.org/info/rfc8006>.

   [RFC8008]  Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
              R., and K. Ma, "Content Delivery Network Interconnection
              (CDNI) Request Routing: Footprint and Capabilities
              Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
              <https://www.rfc-editor.org/info/rfc8008>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9345]  Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
              "Delegated Credentials for TLS and DTLS", RFC 9345,
              DOI 10.17487/RFC9345, July 2023,
              <https://www.rfc-editor.org/info/rfc9345>.

Authors' Addresses

Fieau, et al.            Expires 2 January 2025                [Page 11]
Internet-Draft              RFC XML Examples                   July 2024

   Frederic Fieau
   Orange
   40-48, avenue de la Republique
   92320 Chatillon
   France
   Email: frederic.fieau@orange.com

   Emile Stephan
   Orange
   2, avenue Pierre Marzin
   22300 Lannion
   France
   Email: emile.stephan@orange.com

   Guillaume Bichot
   Broadpeak
   15, rue Claude Chappe
   35510 Cesson-Sevigne
   France
   Email: guillaume.bichot@broadpeak.tv

   Christoph Neumann
   Broadpeak
   15, rue Claude Chappe
   35510 Cesson-Sevigne
   France
   Email: christoph.neumann@broadpeak.tv

Fieau, et al.            Expires 2 January 2025                [Page 12]