CDNI Metadata for Delegated Credentials
draft-ietf-cdni-https-delegation-subcerts-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9677.
|
|
|---|---|---|---|
| Authors | Frédéric Fieau , Emile Stephan , Guillaume Bichot , Christoph Neumann | ||
| Last updated | 2023-10-05 (Latest revision 2023-08-17) | ||
| Replaces | draft-cdni-https-delegation-subcerts | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9677 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-cdni-https-delegation-subcerts-05
Network Working Group F. Fieau
Internet-Draft E. Stephan
Intended status: Standards Track Orange
Expires: 7 April 2024 G. Guillaume
C. Christoph
Broadpeak
5 October 2023
CDNI Metadata for Delegated Credentials
draft-ietf-cdni-https-delegation-subcerts-05
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 7 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fieau, et al. Expires 7 April 2024 [Page 1]
Internet-Draft RFC XML Examples October 2023
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 propert number of supported delegated
credentials . . . . . . . . . . . . . . . . . . . . . . . 4
4. CDNI Metadata interface (MI) metadata object for delegated
credentials . . . . . . . . . . . . . . . . . . . . . . . 5
5. Delegated credentials call flow . . . . . . . . . . . . . . . 6
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. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
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 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
[RFC2119].
Fieau, et al. Expires 7 April 2024 [Page 2]
Internet-Draft RFC XML Examples October 2023
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)
capabilities object 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.
3.1. FCI.DelegatedCredentials
The FCI.DelegationCredentials object enables advertising the maximum
number of delegated credentials supported by the dCDN. This number
is typically (but not necessarily) linked with the number of servers
in the dCDN.
The property PrivateKeyEncryptionKey contains a public key provided
by the dCDN that MUST be used by the uCDN to encrypt private keys if
ever such private keys are transmitted to the dCDN using
MI.DelegatedCredentials (see Section 4).
Fieau, et al. Expires 7 April 2024 [Page 3]
Internet-Draft RFC XML Examples October 2023
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 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 propert number of supported delegated
credentials
The dCDN uses the FCI.DelegatedCredentials object to announce the
number of endpoints as the number of supported delegated credentials.
When the uCDN receives the FCI.DelegatedCredentials object it can
provide 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 of 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
Fieau, et al. Expires 7 April 2024 [Page 4]
Internet-Draft RFC XML Examples October 2023
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.
4. CDNI Metadata interface (MI) metadata object for delegated
credentials
As expressed in [RFC9345], when an origin has delgated 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 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 [RFC9345]
Type: string
Fieau, et al. Expires 7 April 2024 [Page 5]
Internet-Draft RFC XML Examples October 2023
Mandatory-to-Specify: Yes
Property: private-key
Description: Encrypted and 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. 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 rely on JOSE/JWE [RFC7516], whereas the private key is
included as JWE Ciphertext in the JWE.
Below, please find 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 flow
An example call-flow using delegated credentials in CDNI is depicted
in Figure 1.
Fieau, et al. Expires 7 April 2024 [Page 6]
Internet-Draft RFC XML Examples October 2023
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 crednetials.
3. Using the 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 the CDNI 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 [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.
Fieau, et al. Expires 7 April 2024 [Page 7]
Internet-Draft RFC XML Examples October 2023
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
| |<--------------------+
| | |
Figure 1: Example call-flow of Delegated credentials in CDNI
6. IANA Considerations
This document requests the registration of the following entries
under the "CDNI Payload Types" registry hosted by IANA regarding
"CDNI delegation":
Fieau, et al. Expires 7 April 2024 [Page 8]
Internet-Draft RFC XML Examples October 2023
+--------------------------+---------------+
| 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 (and any associated capability
advertisement)
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 in the present document enable providing
delegated credentials to dCDNs. A delegated credentials 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 7 April 2024 [Page 9]
Internet-Draft RFC XML Examples October 2023
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 NOT RECOMMENDED to
send private keys through the MI as omitting the private key further
limits the possibility exploits by an attacker to exploit the
delegated credential.
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 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. 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].
9. References
9.1. Normative References
[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>.
[RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network
Interconnection (CDNI) Control Interface / Triggers",
RFC 8007, DOI 10.17487/RFC8007, December 2016,
<https://www.rfc-editor.org/info/rfc8007>.
Fieau, et al. Expires 7 April 2024 [Page 10]
Internet-Draft RFC XML Examples October 2023
[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>.
[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>.
9.2. Informative 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>.
[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>.
Authors' Addresses
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
Fieau, et al. Expires 7 April 2024 [Page 11]
Internet-Draft RFC XML Examples October 2023
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 7 April 2024 [Page 12]