Internet DRAFT - draft-fieau-interfaces-https-delegation-subcerts
draft-fieau-interfaces-https-delegation-subcerts
CDNI Working Group F. Fieau, Ed.
Internet-Draft E. Stephan
Intended status: Standards Track Orange
Expires: 30 July 2022 G. Bichot
C. Neumann
Broadpeak
26 January 2022
CDNI Metadata for Delegated Credentials
draft-fieau-interfaces-https-delegation-subcerts-01
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
5. CDNI Metadata interface (MI) for delegated credentials . . . . 4
6. Delegated credentials call flows . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1 CDNI MI Delegated Credentials Payload Type . . . . . . . . 7
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . 8
8.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
<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.
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-01
* added section CDNI Footprint and Capabilities Advertisement
interface (FCI) that describeq 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
<Author> Expires <Expiry Date> [Page 3]
INTERNET DRAFT <Document Title> <Issue Date>
* 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
There are currently Internet drafts within the TLS and ACME working
groups adopted to handle delegation of HTTPS delivery between
entities.
This Internet Draft (I-D) specifies the HTTPS delegation between the
CDN entities using CDNI interfaces. The mechanisms described in this
document rely 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 the MI objects supported by
the dCDN. Accordingly, to announce the support for delegated
credentials, the dCDN should announce the support of the object
MI.ConfDelegatedCredentials. This object is described in section 4.
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 two objects, MI.ConfDelegatedCredentials and
MI.DelegatedCredentials, that contain all the necessary metadata and
information for the dCDN to retrieve and use the delegated
credentials. More precisely, the object MI.ConfDelegatedCredentials
contains a URI allowing to download a MI.DelegatedCredentials, the
latter containing the delegated credential itself and the
corresponding private key. The CDNI Metadata Interface [RFC8006]
<Author> Expires <Expiry Date> [Page 4]
INTERNET DRAFT <Document Title> <Issue Date>
describes the CDNI metadata distribution mechanisms according to
which a dCDN can retrieve the MI.ConfDelegatedCredentials object from
the uCDN.
The MI.ConfDelegatedCredentials contains a URI (credentials-location-
uri) that allows the dCDN to download delegated credentials. The
expected behavior of this URI is that each time that the dCDN
accesses this URI a MI.ConfDelegatedCredentials object containing a
delegated credential with its corresponding private key is delivered.
The uCDN may decide on its owns whether it delivers a new delegated
credential with its corresponding private key each time the URI is
called, or - in order to limit the number of credentials being
distributed - always delivers the same delegated credential with its
corresponding private key over a given period of time (e.g., over the
validity period of the credentials).
Within the 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 for each endpoint.
(provided that the uCDN delivers enough different delegated
credentials).
Note, that the access to the credentials-location-uri should be
controlled, i.e. it should be ensured that only an authorized dCDN
can access it. Otherwise, the exposure of the URI would allow anyone
to download DCs.
The properties of the MI.ConfDelegatedCredentials object are as
follows.
Property: credentials-location-uri
Description: expresses the location of the credentials to be
fetched by the dCDN. The credentials are serialized in an
object MI.DelegatedCredential (detailed below), which is
composed of a DelegatedCredential (as defined in
[I-D.ietf-tls-subcerts]) and a corresponding private key.
Link type is as defined in RFC8006, Section 4.3.1.
Type: Link
Mandatory-to-Specify: Yes
The properties of the MI.DelegatedCredentials object are as follows.
Property: delegated-credential
<Author> Expires <Expiry Date> [Page 5]
INTERNET DRAFT <Document Title> <Issue Date>
Description: 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: Yes
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 public-private key pairs and the
corresponding delegated credentials. 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 dCDN request new
delegated credentials.
3. Using CDNI Footprint and Capabilities interface [RFC8008], the
dCDN advertises MI.ConfDelegatedCredentials capabilities to the uCDN.
4. Using CDNI the Metadata interface [RFC8006], the dCDN retrieves
the MI.ConfDelegatedCredentials. E.g., the dCDN retrieves the
MI.ConfDelegatedCredentials object from the uCDN using HTTP GET.
5. The dCDN retrieves the MI.DelegatedCredentials object containing
the delegated credential and corresponding private key by performing
a HTTP GET towards the credentials-location-uri indicated in the
previously retrieved MI.ConfDelegatedCredentials object and deploys
it on some endpoint.
6. 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 5.
Client dCDN uCDN
| | |
<Author> Expires <Expiry Date> [Page 6]
INTERNET DRAFT <Document Title> <Issue Date>
| | 1.[uCDN acquires its certificate
| | out of scope of CDNI]
| | |
| | 2.[generation of private keys
| | and delegated credentials]
| | |
| 3. CDNI FCI interface used to
| advertise support of MI.ConfDelegatedCredentials
| |-------------------->+
| | |
| 4. CDNI Metadata interface used to
| provide the MI.ConfDelegatedCredentials object
| |<--------------------+
| | |
| 5.Retrieve MI.DelegatedCredentials
| (containing Delegated Credential + private key)
| +-------------------->|
| MI.DelegatedCredentials
| |<--------------------+
| | |
6. TLS handshake according |
to [I-D.ietf-tls-subcerts] |
|<------------------->| |
| | |
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 |
+-------------------------------+---------------+
| MI.ConfDelegatedCredentials | RFCthis |
| MI.DelegatedCredentials | RFCthis |
+-------------------------------+---------------+
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
7.1 CDNI MI Delegated Credentials Payload Type
Purpose: The purpose of this Payload Type is to distinguish Delegated
Credentials MI objects (and any associated capability advertisement)
<Author> Expires <Expiry Date> [Page 7]
INTERNET DRAFT <Document Title> <Issue Date>
Interface: MI/FCI
Encoding: see corresponding section
8 References
8.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-11, 23
September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
subcerts-11>.
[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>.
[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>.
8.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 8]
INTERNET DRAFT <Document Title> <Issue Date>
Authors' Addresses
Frederic Fieau (editor)
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 9]
