idnits 2.17.1 draft-fieau-cdni-interfaces-https-delegation-04.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 53 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2125 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) == Unused Reference: 'RFC5246' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'I-D.reschke-http-oob-encoding' is defined on line 494, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 7336 ** Downref: Normative reference to an Informational RFC: RFC 7337 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-03 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-00 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Fieau, Ed. 3 Internet-Draft E. Stephan 4 Intended status: Standards Track Orange 5 Expires: January 3, 2019 S. Mishra 6 Verizon 7 July 02, 2018 9 CDNI extensions for HTTPS delegation 10 draft-fieau-cdni-interfaces-https-delegation-04 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 January 3, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Known delegation methods . . . . . . . . . . . . . . . . . . 3 56 4. Extending the CDNI metadata model . . . . . . . . . . . . . . 3 57 4.1. SecureDelegation object . . . . . . . . . . . . . . . . . 3 58 4.2. Delegation methods . . . . . . . . . . . . . . . . . . . 6 59 4.2.1. AcmeStarDelegationMethod object . . . . . . . . . . . 6 60 4.2.2. SubcertsDelegationMethod object . . . . . . . . . . . 7 61 4.2.3. LurkDelegationMethod object . . . . . . . . . . . . . 9 62 5. Metadata Simple Data Type Descriptions . . . . . . . . . . . 9 63 5.1. Periodicity . . . . . . . . . . . . . . . . . . . . . . . 9 64 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. CDNI MI SecureDelegation Payload Type . . . . . . . . . . 10 66 6.2. CDNI MI AcmeStarDelegationMethod Payload Type . . . . . . 10 67 6.3. CDNI MI SubCertsDelegationMethod Payload Type . . . . . . 10 68 7. Security considerations . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Content delivery over HTTPS using one or more CDNs along the path 77 requires credential management. This specifically applies when an 78 entity delegates delivery of encrypted content to another trusted 79 entity. 81 Several delegation methods are currently proposed within different 82 IETF working groups (refer to [I-D.fieau-cdni-https-delegation] for 83 an overview of delegation works ongoing at the IETF). They specify 84 different methods for provisioning HTTPS delivery credentials. 86 This document extends the CDNI Metadata interface to setup HTTPS 87 delegation between an upstream CDN (uCDN) and downstream CDN (dCDN). 88 Furthermore, it includes a proposal of IANA registry to enable the 89 adding of new methods in the future. 91 Section 2 is about terminology used in this document. Section 3 92 presents delegation methods specified at the IETF. Section 4 93 introduces delegation metadata in CDNI. Section 5 addresses the 94 delegation methods objects. Section 6 describes simple data types. 96 Section 7 is about an IANA registry for delegation methods. 97 Section 8 raises the security issues. 99 2. Terminology 101 This document uses terminology from CDNI framework documents such as 102 CDNi framework document [RFC7336], CDNI requirements [RFC7337] and 103 CDNI interface specifications documents: CDNI Metadata interface 104 [RFC8006], CDNI Control interface / Triggers [RFC8007] and Logging 105 interface [RFC7937]. 107 3. Known delegation methods 109 There are currently I-D drafts proposed at the IETF to handle 110 delegation of HTTPS delivery between entities, refer to 111 [I-D.fieau-cdni-https-delegation]. 113 Regading the existing delegation methods, this additional CDNI 114 framework provides new requirements on the CDNI interfaces. 116 This document considers the following methods supporting HTTPS 117 delegation. It may be used between two or more CDNs with applicable 118 interface support following the CDNI framework, such as the CI/ 119 Triggers and Metadata Interface: 121 - Sub-certificates [I-D.ietf-tls-subcerts] 123 - Short-term certificates in ACME using STAR API [I-D.ietf-acme-star] 125 4. Extending the CDNI metadata model 127 This section defines a CDNI extension to the current Metadata 128 interface model that allows bootstrapping a delegation method between 129 a uCDN and a delegate dCDN. 131 4.1. SecureDelegation object 133 This document reuses PathMetadata object, as defined in [RFC8006], by 134 adding a new "SecureDelegation" object containing a 135 "supportedDelegationMethods" property. 137 This object will allow a uCDN delegating HTTPS delivery to a dCDN to 138 indicate whether there is a delegation occurring on a PathMatch and 139 which are the delegation methods that can be applied when the UA 140 requests contents on the dCDN. 142 Property: supportedDelegationMethods 143 type: Array 145 Description: List of delegation method(s) types that are enabled 146 between a uCDN and a dCDN (ex. "MI.SubcertsDelegationMethod", 147 "MI.AcmeStarDelegationMethod", etc.), as defined in the next 148 section, according to the IANA registry defined in section 8. 150 Example: 152 As an example, the PathMatch object can reference a path-metadata 153 that points at the delegation information. Delegation metadata are 154 added to PathMetaData object. 156 PathMatch: 157 { 158 "path-pattern": { 159 "pattern": "/movies/*", 160 "case-sensitive": true 161 }, 162 "path-metadata": { 163 "type": "MI.PathMetadata", 164 "href": "https://metadata.ucdn.example/video.example.com/movies" 165 } 166 } 168 Below shows the PathMetaData Object related to /movie/* ( located at https://metadata.ucdn.example/video.example.com/movies ) 170 PathMetadata: 171 { 172 "metadata": [ 173 { 174 "generic-metadata-type": "MI.TimeWindowACL", 175 "generic-metadata-value": { 176 "times": [ 177 "windows": [ 178 { 179 "start": "1213948800", 180 "end": "1478047392" 181 } 182 ], 183 "action": "allow", 184 }}, 185 { 186 "generic-metadata-type": "MI.SecureDelegation" 187 "generic-metadata-type": { 188 "supportedDelegationMethods": ["MI.AcmeStarDelegationMethod"], 189 } 190 } 191 ] 192 } 194 The existence of the "MI.SecureDelegation" object in a PathMetaData 195 Object shall enable the use of one of the supported Methods, chosen 196 by the delegate. The delegation method will be activated for the set 197 of Path defined in the PathMatch. See next section for more details 198 about delegation methods metadata specification. 200 4.2. Delegation methods 202 This section defines the delegation methods objects metadata. Those 203 metadata are related to the following aspects of a delegation: 205 o Bootstrapping: bootstrapping a secured delegation consists in 206 providing the dCDN with parameters to set it up, e.g. ACME 207 servers, Key Servers, etc... Please refer to next section for the 208 bootstrapping objects. 210 o Credential renewal: In case of certificates based approaches, 211 [I-D.ietf-tls-subcerts] and [I-D.ietf-acme-star], CDNI should 212 enable certificates and credentials update on given delegated 213 domains. 215 o Expiration/Revocation: expiration of delegation can occur for 216 multiple reasons: changes in delegation rights, delegation 217 validity is over. In [I-D.ietf-tls-subcerts] or 218 [I-D.ietf-acme-star] approaches, the uCDN may implicitly enforce 219 revocation. But it should also prevent any dCDN to renew 220 certificates, or access credentials, when delegation is expired. 222 o Logging: considering delegation logging (usages, errors), CDNI 223 logs should include: supported delegation method(s), credentials 224 renewal requests, credential revocation notice, mutual agreement 225 for selected credential method to use, credentials download status 226 for a specific domain, as well as errors, related to credentials 227 transfer, or crypto aspects such as bad cypher suite supports, 228 revoked delegations, etc. 230 4.2.1. AcmeStarDelegationMethod object 232 This section defines the AcmeStarDelegationMethod object which 233 describes metadata related to the use of Acme Star API presented in 234 [I-D.ietf-acme-star] 236 As expressed in [I-D.ietf-acme-star] and [I-D.nir-saag-star], when an 237 origin has set a delegation to a specific domain (i.e. dCDN), the 238 dCDN should present to the end-user client, a short-term certificate 239 bound to the master certificate. 241 Property: starproxy 243 Type: Endpoint 245 Description: Used to advertise the STAR Proxy to the dCDN. 246 Endpoint type defined in RFC8006, section 4.3.3 248 Property: acmeserver 250 Type: Endpoint 252 Description: used to advertise the ACME server to the dCDN. 253 Endpoint type is defined in RFC8006, section 4.3.3 255 Property: credentialslocationuri 257 Type: Link 259 Description: expresses the location of the credentials to be 260 fetched by the dCDN. Link type is as defined in RFC8006, section 261 4.3.1 263 Property: periodicity 265 Type: Periodicity 267 description: expresses the credentials renewal periodicity. See 268 next section on simple meta data type. 270 As an example, AcmeStarDelegationMethod object could express the 271 Acme-Star delegation as the following: 273 AcmeStarDelegationMethod: { 274 "generic-metadata-type": "MI.AcmeStarDelegationMethod", 275 "generic-metadata-value": { 276 "starproxy": "10.2.2.2", 277 "acmeserver": "10.2.3.3", 278 "credentialslocationuri": "www.ucdn.com/credentials", 279 "periodicity": 36000 280 } 281 } 283 4.2.2. SubcertsDelegationMethod object 285 This section defines the SubcertsDelegationMethod object which 286 describes metadata related to the use of Subcerts as presented in 287 [I-D.ietf-tls-subcerts] 289 As expressed in [I-D.ietf-tls-subcerts], when an origin has set a 290 delegation to a specific domain (i.e. dCDN), the dCDN should present 291 the Origin or uCDN certificate or "delegated_credential" during the 292 TLS handshake to the end-user client application, instead of its own 293 certificate. 295 Property: credentialsdelegatingentity 297 Type: Endpoint 299 Description: Endpoint ID (IP) of the delegating Entity (uCDN). 300 Endpoint type defined in RFC8006, section 4.3.3 302 Property: credentialrecipiententity 304 Type: Endpoint 306 Description: Endpoint ID (IP) of the delegated entity (dCDN). 307 Endpoint type is defined in RFC8006, section 4.3.3 309 Property: credentialslocationuri 311 Type: Link 313 Description: expresses the location of the credentials to be 314 fetched by the dCDN. Link type is as defined in RFC8006, section 315 4.3.1 317 Property: periodicity 319 Type: Periodicity 321 description: expresses the credentials renewal periodicity. See 322 next section on simple meta data type. 324 As an example, when a uCDN has delegated HTTPS delivery to dCDN, a 325 SubcertsDelegationMethod object can express the SubCerts delegation 326 as the following: 328 SubcertsDelegationMethod: { 329 "generic-metadata-type": "MI.SubcertsDelegationMethod", 330 "generic-metadata-value": { 331 "credentialsdelegatingentity": "10.2.2.2", 332 "credentialsrecepiententity": "10.2.3.3", 333 "credentialslocationuri": "www.ucdn.com/credentials", 334 "periodicity": 36000 335 } 336 } 338 4.2.3. LurkDelegationMethod object 340 This section defines the LurkDelegationMethod object which describes 341 metadata related to the use of LURK as defined in 342 [I-D.mglt-lurk-tls]. 344 Property: keyserver 346 Type: Endpoint 348 Description: Endpoint ID (IP) of the delegating Entity (uCDN). 349 Endpoint type defined in RFC8006, section 4.3.3 351 As an example, when a uCDN has delegated HTTPS delivery to dCDN, a 352 LurksDelegationMethod object can express the LURK delegation as the 353 following: 355 LurkDelegationMethod: { 356 "generic-metadata-type": "MI.LurkDelegationMethod", 357 "generic-metadata-value": { 358 "keyserver": "10.2.2.2", 359 } 360 } 362 5. Metadata Simple Data Type Descriptions 364 This section describes the simple data types that are used for 365 properties for objects in this document. 367 5.1. Periodicity 369 A time value expressed in seconds to indicate a periodicity. 371 Type: Integer 373 6. IANA considerations 375 This document requests the registration of the following entries 376 under the "CDNI Payload Types" registry hosted by IANA regarding 377 "CDNI delegation": 379 +----------------------------+---------------+ 380 | Payload Type | Specification | 381 +----------------------------+---------------+ 382 | MI.SecureDelegation | TBD | 383 | MI.AcmeStarDelegationMethod| TBD | 384 | MI.SubCertDelegationMethod | TBD | 385 | MI.LurkDelegationMethod | TBD | 386 | ... | | 387 +----------------------------+---------------+ 389 6.1. CDNI MI SecureDelegation Payload Type 391 Purpose: The purpose of this Payload Type is to distinguish 392 SecureDelegation MI objects (and any associated capability 393 advertisement) 395 Interface: MI/FCI 397 Encoding: see Section 5.1 399 6.2. CDNI MI AcmeStarDelegationMethod Payload Type 401 Purpose: The purpose of this Payload Type is to distinguish 402 AcmeStarDelegationMethod MI objects (and any associated capability 403 advertisement) 405 Interface: MI/FCI 407 Encoding: see Section 5.1 409 6.3. CDNI MI SubCertsDelegationMethod Payload Type 411 Purpose: The purpose of this Payload Type is to distinguish 412 SubcertsDelegationMethod MI objects (and any associated capability 413 advertisement) 415 Interface: MI/FCI 417 Encoding: see Section 5.2 419 7. Security considerations 421 Extensions proposed here do not change Security Considerations as 422 outlined in the CDNI Metadata and Footprint and Capabilities RFCs 423 [RFC8006]. 425 8. References 427 8.1. Normative References 429 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 430 (TLS) Protocol Version 1.2", RFC 5246, 431 DOI 10.17487/RFC5246, August 2008, 432 . 434 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 435 Housley, R., and W. Polk, "Internet X.509 Public Key 436 Infrastructure Certificate and Certificate Revocation List 437 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 438 . 440 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 441 "Framework for Content Distribution Network 442 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 443 August 2014, . 445 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 446 Network Interconnection (CDNI) Requirements", RFC 7337, 447 DOI 10.17487/RFC7337, August 2014, 448 . 450 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 451 and R. Peterkofsky, "Content Distribution Network 452 Interconnection (CDNI) Logging Interface", RFC 7937, 453 DOI 10.17487/RFC7937, August 2016, 454 . 456 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 457 "Content Delivery Network Interconnection (CDNI) 458 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 459 . 461 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 462 Interconnection (CDNI) Control Interface / Triggers", 463 RFC 8007, DOI 10.17487/RFC8007, December 2016, 464 . 466 8.2. Informative References 468 [I-D.fieau-cdni-https-delegation] 469 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 470 CDNI", draft-fieau-cdni-https-delegation-02 (work in 471 progress), July 2017. 473 [I-D.ietf-acme-star] 474 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 475 Fossati, "Support for Short-Term, Automatically-Renewed 476 (STAR) Certificates in Automated Certificate Management 477 Environment (ACME)", draft-ietf-acme-star-03 (work in 478 progress), March 2018. 480 [I-D.ietf-tls-subcerts] 481 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 482 "Delegated Credentials for TLS", draft-ietf-tls- 483 subcerts-00 (work in progress), October 2017. 485 [I-D.mglt-lurk-tls] 486 Migault, D., "LURK Protocol for TLS/DTLS1.2 version 1.0", 487 draft-mglt-lurk-tls-01 (work in progress), March 2017. 489 [I-D.nir-saag-star] 490 Nir, Y., Fossati, T., Sheffer, Y., and T. Eckert, 491 "Considerations For Using Short Term Certificates", draft- 492 nir-saag-star-01 (work in progress), March 2018. 494 [I-D.reschke-http-oob-encoding] 495 Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding 496 for HTTP", draft-reschke-http-oob-encoding-12 (work in 497 progress), June 2017. 499 Authors' Addresses 501 Frederic Fieau (editor) 502 Orange 503 40-48, avenue de la Republique 504 Chatillon 92320 505 France 507 Email: frederic.fieau@orange.com 509 Emile Stephan 510 Orange 511 2, avenue Pierre Marzin 512 Lannion 22300 513 France 515 Email: emile.stephan@orange.com 516 Sanjay Mishra 517 Verizon 518 13100 Columbia Pike 519 Silver Spring MD 20904 520 USA 522 Email: sanjay.mishra@verizon.com