idnits 2.17.1 draft-ietf-cdni-interfaces-https-delegation-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 September 2021) is 952 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CDNI' is mentioned on line 277, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI Working Group F.F. Fieau, Ed. 3 Internet-Draft E.S. Stephan 4 Intended status: Standards Track Orange 5 Expires: 14 March 2022 S.M. Mishra 6 Verizon 7 10 September 2021 9 CDNI extensions for HTTPS delegation 10 draft-ietf-cdni-interfaces-https-delegation-06 12 Abstract 14 The delivery of content over HTTPS involving multiple CDNs raises 15 credential management issues. This document proposes extensions in 16 CDNI Control and Metadata interfaces to setup HTTPS delegation from 17 an Upstream CDN (uCDN) to a Downstream CDN (dCDN). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 14 March 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Known delegation methods . . . . . . . . . . . . . . . . . . 3 55 4. Extension to CDNI FCI . . . . . . . . . . . . . . . . . . . . 3 56 5. Extending the CDNI metadata model . . . . . . . . . . . . . . 4 57 5.1. Extension to HostMetadata object . . . . . . . . . . . . 4 58 5.2. Extension to PathMetadata object . . . . . . . . . . . . 5 59 6. AcmeStarDelegationMethod object . . . . . . . . . . . . . . . 6 60 7. Metadata Simple Data Type Descriptions . . . . . . . . . . . 8 61 7.1. Periodicity . . . . . . . . . . . . . . . . . . . . . . . 8 62 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 63 8.1. CDNI MI AcmeStarDelegationMethod Payload Type . . . . . . 9 64 9. Security considerations . . . . . . . . . . . . . . . . . . . 9 65 10. Comments and questions . . . . . . . . . . . . . . . . . . . 9 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 11.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 Content delivery over HTTPS using one or more CDNs along the path 74 requires credential management. This specifically applies when an 75 entity delegates delivery of encrypted content to another trusted 76 entity. 78 Several delegation methods are currently proposed within different 79 IETF working groups. They specify different methods for provisioning 80 HTTPS delivery credentials. 82 This document extends the CDNI Metadata interface to setup HTTPS 83 delegation between an upstream CDN (uCDN) and downstream CDN (dCDN) 84 using the Standardized delegation methods. Furthermore, it includes 85 a proposal of IANA registry to enable adding of new methods. 87 Section 2 is about terminology used in this document. Section 3 88 presents delegation methods specified at the IETF. Section 4 89 addresses the extension for handling HTTPS delegation in CDNI. 90 Section 5 describes simple data types. Section 6 addresses IANA 91 registry for delegation methods. Section 7 covers the security 92 issues. Section 8 is about comments and questions. 94 2. Terminology 96 This document uses terminology from CDNI framework documents such as: 97 CDNI framework document [RFC7336], CDNI requirements [RFC7337] and 98 CDNI interface specifications documents: CDNI Metadata interface 99 [RFC8006] and CDNI Control interface / Triggers [RFC8007]. 101 3. Known delegation methods 103 There are currently Internet drafts within the TLS and ACME working 104 groups adopted to handle delegation of HTTPS delivery between 105 entities. 107 This Internet Draft (I-D) proposes standardizing HTTPS delegation 108 between the CDN entities using CDNI interfaces. 110 This document only considers the Short-term, Automatically-Renewed 111 (STAR) certificates in Automated Certificate Management 112 Environment(ACME) [RFC8739] 114 This document allows the extension to other delegation methods. 115 Those methods can easily be extended to any further methods in the 116 future. 118 4. Extension to CDNI FCI 120 In order for CDNs to negotiate on which methods are supported, the 121 Footprint and Capabilities interface as defined in RFC8008, allows a 122 uCDN to send a FCI capability type objects, named 123 FCI.SupportedDelegationMethods, to dCDN. 125 The following example shows an exemple of the supported delegated 126 methods capability object serialization for a CDN that supports STAR 127 delegation method. 129 { 130 "capabilities": [ 131 { 132 "capability-type": "FCI.SupportedDelegationMethods", 133 "capability-value": { 134 "delegation-methods": [ 135 "AcmeStarDelegationDelegationMethod", 136 "... Other delegation methods ..." 137 ] 138 } 139 "footprints": [ 140 141 ] 142 } 143 ] 144 } 146 5. Extending the CDNI metadata model 148 This section defines a CDNI extension to the current Metadata 149 interface model that allows bootstrapping delegation methods between 150 a uCDN and a delegate dCDN. 152 5.1. Extension to HostMetadata object 154 This extension reuses HostMetadata object, as defined in [RFC8006], 155 and adds new "Delegation methods" objects as specified in the 156 following sections. 158 The existence of the delegation methods in a HostMetaData Object 159 shall enable the use of one of this methods, chosen by the delegating 160 entity. The delegation method will be activated for the set of Host 161 defined in the HostMatch. See Section 6 for more details about 162 delegation methods metadata specification. 164 Example: 166 The HostMatch object can reference a host metadata that points at the 167 delegation information. Delegation metadata are added to 168 HostMetadata object. 170 Below shows both HostMatch and HostMetadata objects related to a 171 host, for example, here is a HostMatch object referencing 172 "video.example.com": 174 HostMatch: 175 { 176 "host": "video.example.com", 177 "host-metadata": { 178 "type": "MI.HostMetadata", 179 "href": "https://metadata.ucdn.example/host1234" 180 } 181 } 183 Following the example above, the HostMetadata can be modeled 184 for ACMEStarDelegationMethod as: 186 { 187 "hostmetadata": [ 188 { 189 "generic-metadata-type": "MI.AcmeStarDelegationMethod", 190 "generic-metadata-value": { 191 "star-proxy": "10.2.2.2", 192 "acme-server" : "10.2.3.3", 193 "credentials-location-uri": “www.ucdn.com/credentials", 194 "periodicity": 36000, 195 "CSR-template": Json/Text of the CSR template (see 4.2) 196 }}] 197 } 199 This extension allows to explicitly indicate support for a given 200 method. Therefore, the presence (or lack thereof) of an 201 AcmeStarDelegationMethod, and/or further delegation methods, implies 202 support (or lack thereof) for the given method. 204 5.2. Extension to PathMetadata object 206 This extension reuses PathMetadata object, as defined in [RFC8006], 207 and adds new "Delegation methods" objects as specified in the 208 following sections. 210 This allows to explicitly indicate support for a given method. 211 Therefore, the presence (or lack thereof) of an 212 AcmeStarDelegationMethod, and/or further delegation methods, implies 213 support (or lack thereof) for the given method. 215 Example: 217 The PathMatch object can reference a path-metadata that points at the 218 delegation information. Delegation metadata are added to 219 PathMetaData object. 221 Below shows both PathMatch and PathMetaData objects related to a 222 path, for example, here /movies/* located at 223 https://metadata.ucdn.example/video.example.com/movies 225 PathMatch: 226 { 227 "path-pattern": { 228 "pattern": "/movies/*", 229 "case-sensitive": true 230 }, 231 "path-metadata": { 232 "type": "MI.PathMetadata", 233 "href": "https://metadata.ucdn.example/video.example.com/movies" 234 } 235 } 237 Following the example above, the PathMetadata can be modeled 238 for ACMEStarDelegationMethod as: 240 { 241 PathMetadata: 242 { 243 "metadata": [ 244 { 245 "generic-metadata-type": "MI.AcmeStarDelegationMethod", 246 "generic-metadata-value": { 247 "star-proxy": "10.2.2.2", 248 "acme-server" : "10.2.3.3", 249 "credentials-location-uri": “www.ucdn.com/credentials", 250 "periodicity": 36000, 251 "CSR-template": Json/Text of the CSR template (see section 4.2) 252 }}] 253 } 254 } 256 The existence of the "MI.AcmeStarDelegationMethod" object in a 257 PathMetaData Object shall enable the use of one of the 258 AcmeStarDelegation Methods, chosen by the delegating entity. The 259 delegation method will be activated for the set of Path defined in 260 the PathMatch. See Section 6 for more details about delegation 261 methods metadata specification. 263 6. AcmeStarDelegationMethod object 265 This section defines the AcmeStarDelegationMethod object which 266 describes metadata related to the use of ACME/STAR API presented in 267 [RFC8739] 268 As expressed in [RFC8739], when an origin has set a delegation to a 269 specific domain (i.e. dCDN), the dCDN should present to the end-user 270 client, a short-term certificate bound to the master certificate. 272 dCDN uCDN Content Provider CA 273 | ACME/STAR proxy ACME/STAR client ACME/STAR srv 274 | | | | 275 | 1. GET Metadata incl. Delegation Method object with CSR template| 276 +-------------------->| | | 277 | 200 OK + Metadata incl. CSR template [CDNI] | 278 |<--------------------+ | | 279 | 2. Request delegation: video.dcdn.example + dCDN public key | 280 +-------------------->| | | 281 | | 3. Request STAR Cert + dCDN public key | 282 | +-------------------->| 4. Request STAR cert| 283 | | | + Pubkey | 284 | | |-------------------->| 285 | | | 5. STAR certificate | 286 | | 6. STAR certificate |<--------------------| 287 | 7. STAR certificate |<--------------------+ | 288 +<--------------------| | | 289 | | | | 290 | 8. Retrieve STAR certificate (credential-location-uri) | 291 +---------------------------------------------------------------->| 292 | | | 9. renew +--| 293 | | | cert | | 294 | 10. Star certificate | +->| 295 |<----------------------------------------------------------------+ 296 | ... | | | 298 Figure 1: Example call-flow of STAR delegation in CDNI showing 2 levels 299 of delegation 301 Property: star-proxy 303 Description: Used to advertise the STAR Proxy to the dCDN. 304 Endpoint type defined in RFC8006, Section 4.3.3. 306 Type: Endpoint 308 Mandatory-to-Specify: Yes 310 Property: acme-server 312 Description: used to advertise the ACME server to the dCDN. 313 Endpoint type is defined in RFC8006, Section 4.3.3. 315 Type: Endpoint 316 Mandatory-to-Specify: Yes 318 Property: credentials-location-uri 320 Description: expresses the location of the credentials to be 321 fetched by the dCDN. Link type is as defined in RFC8006, 322 Section 4.3.1. 324 Type: Link 326 Mandatory-to-Specify: Yes 328 Property: periodicity 330 Description: expresses the credentials renewal periodicity. See 331 Section 7.1. 333 Type: Periodicity 335 Mandatory-to-Specify: Yes 337 Property: CSR-template 339 Description: The CSR template must be included in the metadata 340 when dealing with AcmeStarDelegation Methods. It shall follow the 341 description in [RFC8739] section 3. It should be included in 342 JSON/text format. 344 Type: JSON 346 Mandatory-to-Specify: Yes 348 7. Metadata Simple Data Type Descriptions 350 This section describes the simple data types that are used for 351 properties for objects in this document. 353 7.1. Periodicity 355 A time value expressed in seconds to indicate a periodicity. 357 Type: Integer 359 8. IANA considerations 361 This document requests the registration of the following entries 362 under the "CDNI Payload Types" registry hosted by IANA regarding 363 "CDNI delegation": 365 +-------------------------------+---------------+ 366 | Payload Type | Specification | 367 +-------------------------------+---------------+ 368 | MI.AcmeStarDelegationMethod | RFCthis | 369 +-------------------------------+---------------+ 371 [RFC Editor: Please replace RFCthis with the published RFC number for 372 this document.] 374 8.1. CDNI MI AcmeStarDelegationMethod Payload Type 376 Purpose: The purpose of this Payload Type is to distinguish 377 AcmeStarDelegationMethod MI objects (and any associated capability 378 advertisement) 380 Interface: MI/FCI 382 Encoding: see Section 4.2.1 384 9. Security considerations 386 Extensions proposed here do not alter nor change Security 387 Considerations as outlined in the CDNI Metadata and Footprint and 388 Capabilities RFCs [RFC8006]. 390 10. Comments and questions 392 Should dCDN be visible from the Content Provider or not? This would 393 lead to different solutions to handle delegation towards the CP. In 394 most cases, the dCDNs should never be visible to the CP, in order to 395 reduce the burden of certificates generation for dCDN. 397 11. References 399 11.1. Normative References 401 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 402 "Content Delivery Network Interconnection (CDNI) 403 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 404 . 406 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 407 Interconnection (CDNI) Control Interface / Triggers", 408 RFC 8007, DOI 10.17487/RFC8007, December 2016, 409 . 411 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 412 Perales, A., and T. Fossati, "Support for Short-Term, 413 Automatically Renewed (STAR) Certificates in the Automated 414 Certificate Management Environment (ACME)", RFC 8739, 415 DOI 10.17487/RFC8739, March 2020, 416 . 418 11.2. Informative References 420 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 421 "Framework for Content Distribution Network 422 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 423 August 2014, . 425 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 426 Network Interconnection (CDNI) Requirements", RFC 7337, 427 DOI 10.17487/RFC7337, August 2014, 428 . 430 Authors' Addresses 432 Frederic Fieau (editor) 433 Orange 434 40-48, avenue de la Republique 435 92320 Chatillon 436 France 438 Email: frederic.fieau@orange.com 440 Emile Stephan 441 Orange 442 2, avenue Pierre Marzin 443 22300 Lannion 444 France 446 Email: emile.stephan@orange.com 448 Sanjay Mishra 449 Verizon 450 13100 Columbia Pike 451 Silver Spring, MD 20904 452 United States of America 454 Email: sanjay.mishra@verizon.com