Internet DRAFT - draft-cdni-https-delegation-subcerts
draft-cdni-https-delegation-subcerts
CDNI Working Group F. Fieau
Internet-Draft E. Stephan
Intended status: Standards Track Orange
Expires: 9 January 2023 G. Bichot
C. Neumann
Broadpeak
8 July 2022
CDNI Metadata for Delegated Credentials
draft-cdni-https-delegation-subcerts-00
Abstract
The delivery of content over HTTPS involving multiple CDNs raises
credential management issues. This document defines metadata in 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 30 July 2022.
Copyright Notice
Copyright (c) 2022 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
<Author> Expires <Expiry Date> [Page 1]
INTERNET DRAFT <Document Title> <Issue Date>
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Known delegation methods . . . . . . . . . . . . . . . . . . . 4
4. CDNI Footprint and Capabilities Advertisement interface
(FCI) for delegated credentials . . . . . . . . . . . . . . . 4
4.1 FCI.DelegatedCredentials . . . . . . . . . . . . . . . . . 5
4.2 Expected usage of FCI.DelegatedCredentials . . . . . . . . . 5
5. CDNI Metadata interface (MI) for delegated credentials . . . . 6
6. Delegated credentials call flows . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1 CDNI MI DelegatedCredentials Payload Type . . . . . . . . . 9
7.1 CDNI FCI DelegatedCredentials Payload Type . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1 Normative References . . . . . . . . . . . . . . . . . . . 10
10.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
<Author> Expires <Expiry Date> [Page 2]
INTERNET DRAFT <Document Title> <Issue Date>
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.
Several delegation methods are currently proposed within different
IETF working groups. They specify different methods for provisioning
HTTPS delivery credentials.
This document defines the CDNI Metadata interface to setup HTTPS
delegation using Delegated Credentials between an upstream CDN (uCDN)
and downstream CDN (dCDN). Furthermore, it includes a proposal of
IANA registry to enable adding of new methods.
Section 2 is about terminology used in this document. Section 3
presents delegation methods specified at the IETF. Section 4
specifies the CDNI Footprint and Capabilities Advertisement interface
(FCI) for delegated credentials. Section 5 specifies the CDNI
Metadata interface (MI) for delegated credentials. Section 6 provides
overall call-flows for delegated credentials. Section 7 addresses
IANA registry for delegation methods. Section 8 discusses Security
Considerations. Section 9 discusses Privacy Considerations.
2. Terminology
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].
2.1. Change Log
draft-cdni-https-delegation-subcerts-00
* Added object FCI.DelegatedCredentials allowing to announce the
number of credentials needed
* Removed object MI.ConfDelegatedCredentials
* MI.DelegatedCredentials changed: private key is now optional,
arrays used to embed multiple delegated credentials within the
object.
* Added sections on privacy and security considerations
<Author> Expires <Expiry Date> [Page 3]
INTERNET DRAFT <Document Title> <Issue Date>
draft-fieau-interfaces-https-delegation-subcerts-01
* added section CDNI Footprint and Capabilities Advertisement
interface (FCI) that describes how to announce support of delegated
credentials
* moved to two different MI objects: MI.ConfDelegatedCredentials and
MI.DelegatedCredentials. The former provides an URI that allows to
download a MI.DelegatedCredentials object that contains the delegated
credential and a private key.
* Added precision on the cryptographic material required by the dCDN
in order to be able to use delegated credentials
* Added precision on the expected behavior when fetching a delegated
credential using credentials-location-uri
* completed and simplified call-flow figure (figure 1) and moved it
to a separate section and added descriptive text
* Minor text improvements
3. Known delegation methods
The TLS and ACME working groups specified a set of RFCs and Internet
drafts to handle delegation of HTTPS delivery between entities.
[RFC8739] specifies the Support for Short-Term, Automatically Renewed
(STAR) Certificates in the Automated Certificate Management
Environment (ACME). [RFC9115] specifies the automatic generation of
delegated certificates in ACME. Together these two RFCs allow
managing short term delegated certificates with ACME. [I-D.ietf-cdni-
interfaces-https-delegation] specifies the HTTPS delegation between
the CDN entities using CDNI interfaces using the STAR/ACME delegation
method.
Instead of working with actual certificates, [I-D.ietf-tls-subcerts]
proposes the use of delegated credentials. This Internet Draft (I-D)
specifies the HTTPS delegation between the CDN entities using CDNI
interfaces by relying on the use of delegated credentials as a
delegation method as defined in [I-D.ietf-tls-subcerts].
4. 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.
With FCI, the dCDN informs the uCDN about its capabilities and the MI
objects supported by the dCDN. Accordingly, to announce the support
<Author> Expires <Expiry Date> [Page 4]
INTERNET DRAFT <Document Title> <Issue Date>
for delegated credentials, the dCDN should announce the support of
MI.DelegatedCredentials .
There is also a need to announce parameters, i.e., the number of
delegated credentials needed by the dCDN in order to work properly.
For that purpose we introduce the FCI object
FCI.DelegationCredentials.
4.1 FCI.DelegatedCredentials
The FCI.DelegationCredentials object allows to announce support for
delegated credentials and to announce the number of delegated
credentials needed.
Property: number-delegated-certs-needed
Description: Number of delegated credentials needed by the
dCDN.
Type: integer
Mandatory-to-Specify: Yes.
The following is an example of the FCI.DelegatedCredentials.
{
"capabilities": [
{
"capability-type": "FCI.DelegatedCredentials",
"capability-value": {
"number-delegated-certs-needed": 10
}
"footprints": [
<Footprint objects>
]
}
]
}
4.2 Expected usage of FCI.DelegatedCredentials
At the first announcement of FCI.DelegatedCredentials to an uCDN, the
dCDN may announce the number of endpoints as the number of required
delegated credentials. When configuring the dCDN, the uCDN may decide
to provide only a subset of the requested delegated credentials. Note
that, within a dCDN different deployment possibilities of the
delegated credentials on the endpoints exist. The dCDN may use one
<Author> Expires <Expiry Date> [Page 5]
INTERNET DRAFT <Document Title> <Issue Date>
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 depends of course on the number
of delegated credentials provided by the uCDN.
Once the dCDN has been configured with delegated credentials and a
set of delegated credentials have been deployed on endpoints, the
dCDN monitors the number of credentials that are about to expires
(e.g. within one day), and ask for new ones by announcing this number
of required delegated credentials via the FCI.DelegatedCredentials
object.
When uCDN queries and retrieves the FCI object it can push the
required number of delegated credentials to the dCDN.
5. CDNI Metadata interface (MI) for delegated credentials
As expressed in [I-D.ietf-tls-subcerts], when an origin has set a
delegation to a downstream entity such as a downstream CDN (i.e.
dCDN), the dCDN should present the "delegated_credential" during the
TLS handshake [RFC8446] to the end-user client application, instead
of its own certificate. The dCDN must further be in the possession of
the private key corresponding to the public key in
DelegatedCredential.cred [I-D.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 object, MI.DelegatedCredentials 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
Mandatory-to-Specify: Yes
Each item of the array of the property delegated-credentials is
composed of the following two properties:
Property: delegated-credential
<Author> Expires <Expiry Date> [Page 6]
INTERNET DRAFT <Document Title> <Issue Date>
Description: Hex-encoded delegated credential structure
DelegatedCredential as defined in [I-D.ietf-tls-subcerts].
Mandatory-to-Specify: Yes
Property: private-key
Description: private key corresponding to the public key
contained in the DelegatedCredential.
Mandatory-to-Specify: No
The private-key property is not mandatory. If not used we suppose
that the dCDN generated the public-private key pair for the delegated
credential itself and provided the public key information with a
mechanism outside of this specification to the uCDN.
Find below an example MI.DelegatedCredential object.
{
"generic-metadata-type": "MI.DelegatedCredentials",
"generic-metadata-value": {
"delegated-credentials": [
{"delegated-credential":
"70105f9bc28aea93f3fed7602b279dc0...
8970822009b330cd11f052c8dc16b451"},
{"delegated-credential":
"e29c881ad8c5772b35fbdcbfe2c4bf16...
27e87d967458ff18268bae512c62a847"},
{"delegated-credential":
"e8f5853b4836017bd46942d72ce6dc54...
1d7a25753fea698082344c8273c24cd8"}
]
}
}
6. Delegated credentials call flows
An example call-flow using delegated credentials in CDNI is depicted
in Figure 1.
1. We suppose 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 we suppose
that public keys of the dCDN are known). Note, that the uCDN may
<Author> Expires <Expiry Date> [Page 7]
INTERNET DRAFT <Document Title> <Issue Date>
generate this material at different points in time, e.g. in advance
to have a pool of delegated credentials or on-demand when dCDN
request new delegated credentials.
3. Using CDNI Footprint and Capabilities interface [RFC8008], the
dCDN advertises MI.DelegatedCredentials capabilities to the uCDN. The
dCDN further uses FCI.DelegatedCredentials to ask for a certain
number of 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 [I-D.ietf-tls-subcerts] using the delegated
credentials retrieved in step 4.
6. Some delegated credentials are about to expire. The dCDN uses
FCI.DelegatedCredentials to announce the number of delegated
credentials needed.
7. Using CDNI the Metadata interface [RFC8006], the dCDN acquires the
MI.DelegatedCredentials, therefore retrieving an new array of
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
| needed using FCI.DelegatedCredentials
| |-------------------->+
| | |
| 4. CDNI Metadata interface used to
| provide the MI.DelegatedCredential object
| |<--------------------+
| | |
| | |
[5. TLS handshake according |
to [I-D.ietf-tls-subcerts]] |
|<------------------->| |
<Author> Expires <Expiry Date> [Page 8]
INTERNET DRAFT <Document Title> <Issue Date>
| | |
| 6.Some delegated credentials about to expire.
| CDNI FCI interface used to announce number
| of delegated credentials needed
| using FCI.DelegatedCredentials
| +-------------------->|
| | |
| 7. CDNI Metadata interface used to
| provide the MI.DelegatedCredential object
| |<--------------------+
| | |
Figure 1: Example call-flow of Delegated credentials in CDNI
7. IANA Considerations
This document requests the registration of the following entries
under the "CDNI Payload Types" registry hosted by IANA regarding
"CDNI delegation":
+-------------------------------+---------------+
| Payload Type | Specification |
+-------------------------------+---------------+
| FCI.DelegatedCredentials | RFCthis |
| MI.DelegatedCredentials | RFCthis |
+-------------------------------+---------------+
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
7.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 corresponding section
7.1 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
<Author> Expires <Expiry Date> [Page 9]
INTERNET DRAFT <Document Title> <Issue Date>
Encoding: see corresponding section
8. Security Considerations
The extensions defined in the present document allow to provide
delegated credentials to dCDNs. The delegated credentials themselves
are short-lived and as such a single leaked delegated credential
represents a limited security risk. However, it is important to
ensure that an attacker is not able to systematically retrieve a more
important number of delegated credentials. 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.
The security provide by [RFC8006] should therefore address the above
security concerns.
9. 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].
10 References
10.1 Normative References
[I-D.ietf-tls-subcerts] Barnes, R., Iyengar, S., Sullivan, N., and E.
Rescorla, "Delegated Credentials for TLS", Work in
Progress, Internet-Draft, draft-ietf-tls-subcerts-15, 15
June 2022, <https://datatracker.ietf.org/doc/html/draft-
ietf-tls-subcerts-15>.
[RFC9115] Sheffer, Y., Lopez, D., Pastor Perales, A., and T. Fossati,
"An Automatic Certificate Management Environment (ACME)
Profile for Generating Delegated Certificates", RFC 9115,
DOI 10.17487/RFC9115, September 2021, <https://www.rfc-
editor.org/info/rfc9115>.
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor
Perales, A., and T. Fossati, "Support for Short-Term,
Automatically Renewed (STAR) Certificates in the Automated
Certificate Management Environment (ACME)", RFC 8739, DOI
10.17487/RFC8739, March 2020, <https://www.rfc-
<Author> Expires <Expiry Date> [Page 10]
INTERNET DRAFT <Document Title> <Issue Date>
editor.org/info/rfc9115>.
[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/rfc8739>.
[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>.
[I-D.ietf-cdni-interfaces-https-delegation] Fieau, F., Stephan, E.,
and S. Mishra, "CDNI extensions for HTTPS delegation",
Work in Progress, Internet-Draft, draft-ietf-cdni-
interfaces-https-delegation-08, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-cdni-
interfaces-https-delegation-08>.
10.2 Informative References
[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>.
[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>.
<Author> Expires <Expiry Date> [Page 11]
INTERNET DRAFT <Document Title> <Issue Date>
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
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
<Author> Expires <Expiry Date> [Page 12]
