idnits 2.17.1 draft-fieau-cdni-interfaces-https-delegation-03.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 : ---------------------------------------------------------------------------- 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 (January 08, 2018) is 2271 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 393, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'I-D.mglt-lurk-tls' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'I-D.reschke-http-oob-encoding' is defined on line 453, 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-02 == Outdated reference: A later version (-01) exists of draft-nir-saag-star-00 Summary: 3 errors (**), 0 flaws (~~), 7 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: July 12, 2018 S. Mishra 6 Verizon 7 January 08, 2018 9 CDNI extensions for HTTPS delegation 10 draft-fieau-cdni-interfaces-https-delegation-03 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 a 17 uCDN to a 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 July 12, 2018. 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 . . . . . . . . . . . . . . . . . . . 5 59 4.2.1. AcmeStarDelegationMethod object . . . . . . . . . . . 5 60 4.2.2. SubcertsDelegationMethod object . . . . . . . . . . . 6 61 5. Metadata Simple Data Type Descriptions . . . . . . . . . . . 8 62 5.1. Periodicity . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. CDNI MI SecureDelegation Payload Type . . . . . . . . . . 8 65 6.2. CDNI MI AcmeStarDelegationMethod Payload Type . . . . . . 8 66 6.3. CDNI MI SubCertsDelegationMethod Payload Type . . . . . . 9 67 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Content delivery over HTTPS using one or more CDNs along the path 76 requires credential management. This is specifically needed when an 77 entity delegates delivery of encrypted content to another trusted 78 entity. 80 Several delegation methods are currently proposed within different 81 IETF working groups (refer to [I-D.fieau-cdni-https-delegation] for 82 an overview of delegation works ongoing at the IETF). They specify 83 different methods for provisioning HTTPS delivery credentials. 85 This document proposes an extension to the CDNI control / Triggers 86 and Metadata interfaces to setup HTTPS delegation between an uCDN and 87 dCDN. Furthermore, it includes a proposal of registry to enable the 88 adding of new methods in the future. 90 Section 2 is about terminology used in this document. Section 3 91 presents delegation methods specified at the IETF. Section 4 92 introduces delegation metadata in CDNI. Section 5 addresses the 93 delegation methods objects. Section 6 describes simple data types. 94 Section 7 is about an IANA registry for delegation methods. 95 Section 8 raises the security issues. 97 2. Terminology 99 This document uses terminology from CDNI framework documents such as 100 CDNi framework document [RFC7336], CDNI requirements [RFC7337] and 101 CDNI interface specifications documents: CDNI Metadata interface 102 [RFC8006], CDNI Control interface / Triggers [RFC8007] and Logging 103 interface [RFC7937]. 105 3. Known delegation methods 107 A few methods are currently being proposed at the IETF to handle 108 delegation of HTTPS delivery between entities, refer to 109 [I-D.fieau-cdni-https-delegation]. 111 Regading the existing delegation methods, we need a common framework 112 in CDNI that provides new requirements on the CDNI interfaces. 114 This document considers the following methods supporting HTTPS 115 delegation. It may be used between two or more CDNs with applicable 116 interface support following the CDNI framework, such as the CI/ 117 Triggers and Metadata Interface: 119 - Sub-certificates [I-D.rescorla-tls-subcerts] 121 - Short-term certificates in ACME using STAR API [I-D.ietf-acme-star] 123 4. Extending the CDNI metadata model 125 4.1. SecureDelegation object 127 We suggest reusing the PathMetadata object by adding a new 128 "SecureDelegation" object containing a "supportedDelegationMethods" 129 property. 131 Property: supportedDelegationMethods 133 type: Array 135 Description: List of delegation method(s) types that are enabled 136 between a uCDN and a dCDN (ex. "MI.SubcertsDelegationMethod", 137 "MI.AcmeStarDelegationMethod", etc.), as defined in the next 138 section. 140 Example: 142 As an example, the PathMatch object can reference a path-metadata 143 that would point at the delegation information. Delegation metadata 144 are added to PathMetaData object. 146 PathMatch: 147 { 148 "path-pattern": { 149 "pattern": "/movies/*", 150 "case-sensitive": true 151 }, 152 "path-metadata": { 153 "type": "MI.PathMetadata", 154 "href": "https://metadata.ucdn.example/video.example.com/movies" 155 } 156 } 158 PathMetaData Object related to /movie/* 160 PathMetadata: 161 { 162 "metadata": [ 163 { 164 "generic-metadata-type": "MI.TimeWindowACL", 165 "generic-metadata-value": { 166 "times": [ 167 "windows": [ 168 { 169 "start": "1213948800", 170 "end": "1478047392" 171 } 172 ], 173 "action": "allow", 174 }}, 175 { 176 "generic-metadata-type": "MI.SecureDelegation" 177 "generic-metadata-type": { 178 "supportedDelegationMethods": ["MI.AcmeStarDelegationMethod"], 179 } 180 } 181 ] 182 } 184 The existence of the "MI.SecureDelegation" object in a PathMetaData 185 Object shall enable the use of one of the supported Methods, chosen 186 by the delegate. See next section for more details about delegation 187 methods metadata specification. 189 4.2. Delegation methods 191 This section defines the delegation methods objects metadata. Each 192 object of the section consists in defining metadata related to the 193 following steps: 195 o Bootstrapping: bootstrapping a secured delegation consists in 196 providing the dCDN with enough parameters to set it up, e.g. ACME 197 servers, Key Servers, etc.. 199 o Credential renewal: In case of certificates based approaches, 200 [I-D.rescorla-tls-subcerts] and [I-D.ietf-acme-star], there is a 201 need in CDNI to periodically provision and update credentials 202 (certificates or private keys) on the dCDNs for a given delegated 203 domain. 205 o Expiration/Revocation: expiration of delegation can occur for 206 multiple reasons: changes in delegation rights, delegation 207 validity is over. In [I-D.rescorla-tls-subcerts] or 208 [I-D.ietf-acme-star] approaches, the uCDN may implicitly enforce 209 revocation and will prevent any dCDN to renew certificates, or 210 access credentials, when delegation is expired. 212 o Logging: Regarding logging aspects, we consider to log usages and 213 errors related to a delegated domain. As an example, CDNI logs 214 include: supported delegation method(s), credentials renewal 215 requests, credential revocation notice, mutual agreement for 216 selected credential method to use, credentials download status for 217 a specific domain, as well as errors, related to credentials 218 transfer, or crypto aspects such as bad cypher suite supports, 219 revoked delegations, etc. 221 4.2.1. AcmeStarDelegationMethod object 223 This section defines the AcmeStarDelegationMethod object which 224 describes metadata related to the use of Acme Star API presented in 225 [I-D.ietf-acme-star] 227 As expressed in [I-D.ietf-acme-star] and [I-D.nir-saag-star], when an 228 origin has set a delegation to a specific domain (i.e. dCDN), the 229 dCDN should present to the end-user client, a short-time certificate 230 bound to the master certificate. 232 Property: starproxy 234 Type: Endpoint 235 Description: Used to advertise the STAR Proxy to the dCDN. 236 Endpoint type defined in RFC8006, section 4.3.3 238 Property: acmeserver 240 Type: Endpoint 242 Description: used to advertise the ACME server to the dCDN. 243 Endpoint type is defined in RFC8006, section 4.3.3 245 Property: credentialslocationuri 247 Type: Link 249 Description: expresses the location of the credentials to be 250 fetched by the dCDN. Link type is as defined in RFC8006, section 251 4.3.1 253 Property: periodicity 255 Type: Periodicity 257 description: expresses the credentials renewal periodicity. See 258 next section on simple meta data type. 260 As an example, AcmeStarDelegationMethod object could express the 261 Acme-Star-delegation as the following: 263 AcmeStarDelegationMethod: { 264 "generic-metadata-type": "MI.AcmeStarDelegationMethod", 265 "generic-metadata-value": { 266 "starproxy": "10.2.2.2", 267 "acmeserver": "10.2.3.3", 268 "credentialslocationuri": "www.ucdn.com/credentials", 269 "periodicity": 36000 270 } 271 } 273 4.2.2. SubcertsDelegationMethod object 275 This section defines the SubcertsDelegationMethod object which 276 describes metadata related to the use of Subcerts as presented in 277 [I-D.rescorla-tls-subcerts] 279 As expressed in [I-D.rescorla-tls-subcerts], when an origin has set a 280 delegation to a specific domain (i.e. dCDN), the dCDN should present 281 the Origin or uCDN certificate or "delegated_credential" during the 282 TLS handshake to the end-user client application, instead of its own 283 certificate. 285 Property: credentialsdelegatingentity 287 Type: Endpoint 289 Description: Endpoint ID (IP) of the delegating Entity (uCDN). 290 Endpoint type defined in RFC8006, section 4.3.3 292 Property: credentialrecipiententity 294 Type: Endpoint 296 Description: Endpoint ID (IP) of the delegated entity (dCDN). 297 Endpoint type is defined in RFC8006, section 4.3.3 299 Property: credentialslocationuri 301 Type: Link 303 Description: expresses the location of the credentials to be 304 fetched by the dCDN. Link type is as defined in RFC8006, section 305 4.3.1 307 Property: periodicity 309 Type: Periodicity 311 description: expresses the credentials renewal periodicity. See 312 next section on simple meta data type. 314 As an example, AcmeStarDelegationMethod object could express the 315 Acme-Star-delegation as the following: 317 SubcertsDelegationMethod: { 318 "generic-metadata-type": "MI.SubcertsDelegationMethod", 319 "generic-metadata-value": { 320 "credentialsdelegatingentity": "10.2.2.2", 321 "credentialsrecepiententity": "10.2.3.3", 322 "credentialslocationuri": "www.ucdn.com/credentials", 323 "periodicity": 36000 324 } 325 } 327 5. Metadata Simple Data Type Descriptions 329 This section describes the simple data types that are used for 330 properties for objects in this document. 332 5.1. Periodicity 334 A time value expressed in seconds to indicate a periodicity. 336 Type: Integer 338 6. IANA considerations 340 This document requests the registration of the following entries 341 under the "CDNI Payload Types" registry hosted by IANA regarding 342 "CDNI delegation": 344 +----------------------------+---------------+ 345 | Payload Type | Specification | 346 +----------------------------+---------------+ 347 | MI.SecureDelegation | TBD | 348 | MI.AcmeStarDelegationMethod| TBD | 349 | MI.SubCertDelegationMethod | TBD | 350 | ... | | 351 +----------------------------+---------------+ 353 6.1. CDNI MI SecureDelegation Payload Type 355 Purpose: The purpose of this Payload Type is to distinguish 356 SecureDelegation MI objects (and any associated capability 357 advertisement) 359 Interface: MI/FCI 361 Encoding: see Section 5.1 363 6.2. CDNI MI AcmeStarDelegationMethod Payload Type 365 Purpose: The purpose of this Payload Type is to distinguish 366 AcmeStarDelegationMethod MI objects (and any associated capability 367 advertisement) 369 Interface: MI/FCI 371 Encoding: see Section 5.1 373 6.3. CDNI MI SubCertsDelegationMethod Payload Type 375 Purpose: The purpose of this Payload Type is to distinguish 376 SubcertsDelegationMethod MI objects (and any associated capability 377 advertisement) 379 Interface: MI/FCI 381 Encoding: see Section 5.2 383 7. Security considerations 385 Extensions proposed here do not change Security Considerations as 386 outlined in the CDNI Metadata and Footprint and Capabilities RFCs 387 [RFC8006]. 389 8. References 391 8.1. Normative References 393 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 394 (TLS) Protocol Version 1.2", RFC 5246, 395 DOI 10.17487/RFC5246, August 2008, 396 . 398 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 399 Housley, R., and W. Polk, "Internet X.509 Public Key 400 Infrastructure Certificate and Certificate Revocation List 401 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 402 . 404 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 405 "Framework for Content Distribution Network 406 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 407 August 2014, . 409 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 410 Network Interconnection (CDNI) Requirements", RFC 7337, 411 DOI 10.17487/RFC7337, August 2014, 412 . 414 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 415 and R. Peterkofsky, "Content Distribution Network 416 Interconnection (CDNI) Logging Interface", RFC 7937, 417 DOI 10.17487/RFC7937, August 2016, 418 . 420 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 421 "Content Delivery Network Interconnection (CDNI) 422 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 423 . 425 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 426 Interconnection (CDNI) Control Interface / Triggers", 427 RFC 8007, DOI 10.17487/RFC8007, December 2016, 428 . 430 8.2. Informative References 432 [I-D.fieau-cdni-https-delegation] 433 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 434 CDNI", draft-fieau-cdni-https-delegation-02 (work in 435 progress), July 2017. 437 [I-D.ietf-acme-star] 438 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 439 Fossati, "Support for Short-Term, Automatically-Renewed 440 (STAR) Certificates in Automated Certificate Management 441 Environment (ACME)", draft-ietf-acme-star-02 (work in 442 progress), November 2017. 444 [I-D.mglt-lurk-tls] 445 Migault, D., "LURK Protocol for TLS/DTLS1.2 version 1.0", 446 draft-mglt-lurk-tls-01 (work in progress), March 2017. 448 [I-D.nir-saag-star] 449 Nir, Y., Fossati, T., and Y. Sheffer, "Considerations For 450 Using Short Term Certificates", draft-nir-saag-star-00 451 (work in progress), October 2017. 453 [I-D.reschke-http-oob-encoding] 454 Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding 455 for HTTP", draft-reschke-http-oob-encoding-12 (work in 456 progress), June 2017. 458 [I-D.rescorla-tls-subcerts] 459 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 460 "Delegated Credentials for TLS", draft-rescorla-tls- 461 subcerts-02 (work in progress), October 2017. 463 Authors' Addresses 464 Frederic Fieau (editor) 465 Orange 466 40-48, avenue de la Republique 467 Chatillon 92320 468 France 470 Email: frederic.fieau@orange.com 472 Emile Stephan 473 Orange 474 2, avenue Pierre Marzin 475 Lannion 22300 476 France 478 Email: emile.stephan@orange.com 480 Sanjay Mishra 481 Verizon 482 13100 Columbia Pike 483 Silver Spring MD 20904 484 USA 486 Email: sanjay.mishra@verizon.com