idnits 2.17.1 draft-fieau-cdni-interfaces-https-delegation-02.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 (October 30, 2017) is 2371 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 458, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'I-D.mglt-lurk-tls' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'I-D.reschke-http-oob-encoding' is defined on line 517, 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-00 == 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: May 3, 2018 S. Mishra 6 Verizon 7 October 30, 2017 9 CDNI extensions for HTTPS delegation 10 draft-fieau-cdni-interfaces-https-delegation-02 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 May 3, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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. Specifying Delegation metadata . . . . . . . . . . . . . . . 3 57 4.1. SecureDelegation object definition . . . . . . . . . . . 3 58 4.2. Extension to the current CDNI metadata model . . . . . . 5 59 5. Delegation methods . . . . . . . . . . . . . . . . . . . . . 7 60 5.1. AcmeStarDelegationMethod object . . . . . . . . . . . . . 7 61 5.2. SubcertsDelegationMethod object . . . . . . . . . . . . . 8 62 6. Metadata Simple Data Type Descriptions . . . . . . . . . . . 10 63 6.1. Periodicity . . . . . . . . . . . . . . . . . . . . . . . 10 64 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. CDNI MI SecureDelegation Payload Type . . . . . . . . . . 10 66 7.2. CDNI MI AcmeStarDelegationMethod Payload Type . . . . . . 10 67 7.3. CDNI MI SubCertsDelegationMethod Payload Type . . . . . . 11 68 8. Security considerations . . . . . . . . . . . . . . . . . . . 11 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative References . . . . . . . . . . . . . . . . . 12 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 is specifically needed 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 proposes an extension to the CDNI control / Triggers 87 and Metadata interfaces to setup HTTPS delegation between an uCDN and 88 dCDN. Furthermore, it includes a proposal of 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 A few methods are currently being 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, we need a common framework 114 in CDNI that 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.rescorla-tls-subcerts] 123 - Short-term certificates in ACME using STAR API [I-D.ietf-acme-star] 125 4. Specifying Delegation metadata 127 Two metadata models for enforcing delegation in CDNI between two 128 entities are suggested in this document: 130 - New standalone object: SecureDelegation 132 - Extension to current CDNI metadata model 134 4.1. SecureDelegation object definition 136 This section presents an alternative to the approach presented in 137 section 5.1. The section proposes to specify a new metadata object, 138 SecureDelegation, dedicated to provide delegation information between 139 two entities. It aims at fully describing a secured delegation 140 between an uCDN and dCDN by indicating the delegated domain, the 141 start and end duration of a delegation, and the delegation method 142 used. 144 property: delegateddomains 146 type: Array 148 Description: List of delegated hostname indicated by an HostMatch 149 object as defined in RFC8006 section 4.3.3. This value should 150 match the SAN value in certificates. 152 property: pathpatterns 154 type: Array 156 Description: List that contains PathPattern objects with a path to 157 match against a resource's URI path in order to trigger the 158 delegation. It is described in RFC8006, 4.1.4. 160 property: timewindow 162 type: TimeWindow 164 Description: Describes delegation start and end times. Timewindow 165 is defined in RFC8006 section 4.2. 167 Property: supporteddelegationmethods 169 type: Array 171 Description: List of delegation method(s) types that are enabled 172 between a uCDN and a dCDN (ex. "MI.SubcertsDelegationMethod", 173 "MI.AcmeStarDelegationMethod", etc.), as defined in the next 174 section. 176 As an example: a SecureDelegation object (which contains a 177 TimeWindow, SupportedDelegationMethods and a HostMatch metadata) that 178 only allows the dCDN to deliver content to clients between 09:00 179 01/01/2000 UTC and 17:00 01/01/2000 UTC: 181 SecureDelegation object: 182 { 183 "generic-metadata-type": "MI.SecureDelegation", 184 "generic-metadata-value": 185 { 186 "timewindow": {start: 946717200, end: 946746000}, 187 "supporteddelegationmethods": ["MI.AcmeStarDelegationMethod", 188 "MI.SubcertsDelegationMethod"], 189 "pathpatterns": [{ 190 "pattern": "/movies/*", 191 "case-sensitive": true 192 }], 193 "delegatedDomains": ["www.origin.com"] 194 } 195 } 197 Such an object shall be conveyed over the CDNI metadata interface. 199 4.2. Extension to the current CDNI metadata model 201 This approach consists of reusing the current metadata model by 202 adding delegation information, like the aforementioned 203 "supportedDelegationMethod" property. 205 Example: 207 As an example, the PathMatch object can reference a path-metadata 208 that would point at the delegation information. Delegation metadata 209 are added to PathMetaData object. 211 PathMatch: 212 { 213 "path-pattern": { 214 "pattern": "/movies/*", 215 "case-sensitive": true 216 }, 217 "path-metadata": { 218 "type": "MI.PathMetadata", 219 "href": "https://metadata.ucdn.example/video.example.com/movies" 220 } 221 } 223 PathMetaData Object related to /movie/* 225 PathMetadata: 226 { 227 "metadata": [ 228 { 229 "generic-metadata-type": "MI.TimeWindowACL", 230 "generic-metadata-value": { 231 "times": [ 232 "windows": [ 233 { 234 "start": "1213948800", 235 "end": "1478047392" 236 } 237 ], 238 "action": "allow", 239 }}, 240 { 241 "generic-metadata-type": "MI.SecureDelegation" 242 "generic-metadata-type": { 243 "supporteddelegationmethods ": ["MI.AcmeStarDelegationMethod"], 244 } 245 } 246 ] 247 } 249 The existence of the "MI.SecureDelegation" object in a PathMetaData 250 Object shall enable the use of one of the supported Methods, chosen 251 by the delegate. See next section for more details about delegation 252 methods metadata specification. 254 5. Delegation methods 256 This section defines the delegation methods objects metadata. Each 257 object of the section consists in defining metadata related to the 258 following steps: 260 o Bootstrapping: bootstrapping a secured delegation consists in 261 providing the dCDN with enough parameters to set it up, e.g. ACME 262 servers, Key Servers, etc.. 264 o Credential renewal: In case of certificates based approaches, 265 [I-D.rescorla-tls-subcerts] and [I-D.ietf-acme-star], there is a 266 need in CDNI to periodically provision and update credentials 267 (certificates or private keys) on the dCDNs for a given delegated 268 domain. 270 o Expiration/Revocation: expiration of delegation can occur for 271 multiple reasons: changes in delegation rights, delegation 272 validity is over. In [I-D.rescorla-tls-subcerts] or 273 [I-D.ietf-acme-star] approaches, the uCDN may implicitly enforce 274 revocation and will prevent any dCDN to renew certificates, or 275 access credentials, when delegation is expired. 277 o Logging: Regarding logging aspects, we consider to log usages and 278 errors related to a delegated domain. As an example, CDNI logs 279 include: supported delegation method(s), credentials renewal 280 requests, credential revocation notice, mutual agreement for 281 selected credential method to use, credentials download status for 282 a specific domain, as well as errors, related to credentials 283 transfer, or crypto aspects such as bad cypher suite supports, 284 revoked delegations, etc. 286 5.1. AcmeStarDelegationMethod object 288 This section defines the AcmeStarDelegationMethod object which 289 describes metadata related to the use of Acme Star API presented in 290 [I-D.ietf-acme-star] 292 As expressed in [I-D.ietf-acme-star] and [I-D.nir-saag-star], when an 293 origin has set a delegation to a specific domain (i.e. dCDN), the 294 dCDN should present to the end-user client, a short-time certificate 295 bound to the master certificate. 297 Property: starproxy 299 Type: Endpoint 300 Description: Used to advertise the STAR Proxy to the dCDN. 301 Endpoint type defined in RFC8006, section 4.3.3 303 Property: acmeserver 305 Type: Endpoint 307 Description: used to advertise the ACME server to the dCDN. 308 Endpoint type is defined in RFC8006, section 4.3.3 310 Property: credentialslocationuri 312 Type: Link 314 Description: expresses the location of the credentials to be 315 fetched by the dCDN. Link type is as defined in RFC8006, section 316 4.3.1 318 Property: periodicity 320 Type: Periodicity 322 description: expresses the credentials renewal periodicity. See 323 next section on simple meta data type. 325 As an example, AcmeStarDelegationMethod object could express the 326 Acme-Star-delegation as the following: 328 AcmeStarDelegationMethod: { 329 "generic-metadata-type": "MI.AcmeStarDelegationMethod", 330 "generic-metadata-value": { 331 "starproxy": "10.2.2.2", 332 "acmeserver": "10.2.3.3", 333 "credentialslocationuri": "www.ucdn.com/credentials", 334 "periodicity": 36000 335 } 336 } 338 5.2. SubcertsDelegationMethod object 340 This section defines the SubcertsDelegationMethod object which 341 describes metadata related to the use of Subcerts as presented in 342 [I-D.rescorla-tls-subcerts] 344 As expressed in [I-D.rescorla-tls-subcerts], when an origin has set a 345 delegation to a specific domain (i.e. dCDN), the dCDN should present 346 the Origin or uCDN certificate or "delegated_credential" during the 347 TLS handshake to the end-user client application, instead of its own 348 certificate. 350 Property: credentialsdelegatingentity 352 Type: Endpoint 354 Description: Endpoint ID (IP) of the delegating Entity (uCDN). 355 Endpoint type defined in RFC8006, section 4.3.3 357 Property: credentialrecipiententity 359 Type: Endpoint 361 Description: Endpoint ID (IP) of the delegated entity (dCDN). 362 Endpoint type is defined in RFC8006, section 4.3.3 364 Property: credentialslocationuri 366 Type: Link 368 Description: expresses the location of the credentials to be 369 fetched by the dCDN. Link type is as defined in RFC8006, section 370 4.3.1 372 Property: periodicity 374 Type: Periodicity 376 description: expresses the credentials renewal periodicity. See 377 next section on simple meta data type. 379 As an example, AcmeStarDelegationMethod object could express the 380 Acme-Star-delegation as the following: 382 SubcertsDelegationMethod: { 383 "generic-metadata-type": "MI.SubcertsDelegationMethod", 384 "generic-metadata-value": { 385 "credentialsdelegatingentity": "10.2.2.2", 386 "credentialsrecepiententity": "10.2.3.3", 387 "credentialslocationuri": "www.ucdn.com/credentials", 388 "periodicity": 36000 389 } 390 } 392 6. Metadata Simple Data Type Descriptions 394 This section describes the simple data types that are used for 395 properties for objects in this document. 397 6.1. Periodicity 399 A time value expressed in seconds to indicate a periodicity. 401 Type: Integer 403 7. IANA considerations 405 This document requests the registration of the following entries 406 under the "CDNI Payload Types" registry hosted by IANA regarding 407 "CDNI delegation": 409 +----------------------------+---------------+ 410 | Payload Type | Specification | 411 +----------------------------+---------------+ 412 | MI.SecureDelegation | TBD | 413 | MI.AcmeStarDelegationMethod| TBD | 414 | MI.SubCertDelegationMethod | TBD | 415 | ... | | 416 +----------------------------+---------------+ 418 7.1. CDNI MI SecureDelegation Payload Type 420 Purpose: The purpose of this Payload Type is to distinguish 421 SecureDelegation MI objects (and any associated capability 422 advertisement) 424 Interface: MI/FCI 426 Encoding: see Section 5.1 428 7.2. CDNI MI AcmeStarDelegationMethod Payload Type 430 Purpose: The purpose of this Payload Type is to distinguish 431 AcmeStarDelegationMethod MI objects (and any associated capability 432 advertisement) 434 Interface: MI/FCI 436 Encoding: see Section 5.1 438 7.3. CDNI MI SubCertsDelegationMethod Payload Type 440 Purpose: The purpose of this Payload Type is to distinguish 441 SubcertsDelegationMethod MI objects (and any associated capability 442 advertisement) 444 Interface: MI/FCI 446 Encoding: see Section 5.2 448 8. Security considerations 450 Extensions proposed here do not change Security Considerations as 451 outlined in the CDNI Metadata and Footprint and Capabilities RFCs 452 [RFC8006]. 454 9. References 456 9.1. Normative References 458 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 459 (TLS) Protocol Version 1.2", RFC 5246, 460 DOI 10.17487/RFC5246, August 2008, 461 . 463 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 464 Housley, R., and W. Polk, "Internet X.509 Public Key 465 Infrastructure Certificate and Certificate Revocation List 466 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 467 . 469 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 470 "Framework for Content Distribution Network 471 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 472 August 2014, . 474 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 475 Network Interconnection (CDNI) Requirements", RFC 7337, 476 DOI 10.17487/RFC7337, August 2014, 477 . 479 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 480 and R. Peterkofsky, "Content Distribution Network 481 Interconnection (CDNI) Logging Interface", RFC 7937, 482 DOI 10.17487/RFC7937, August 2016, 483 . 485 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 486 "Content Delivery Network Interconnection (CDNI) 487 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 488 . 490 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 491 Interconnection (CDNI) Control Interface / Triggers", 492 RFC 8007, DOI 10.17487/RFC8007, December 2016, 493 . 495 9.2. Informative References 497 [I-D.fieau-cdni-https-delegation] 498 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 499 CDNI", draft-fieau-cdni-https-delegation-02 (work in 500 progress), July 2017. 502 [I-D.ietf-acme-star] 503 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 504 Fossati, "Use of Short-Term, Automatically-Renewed (STAR) 505 Certificates to Delegate Authority over Web Sites", draft- 506 ietf-acme-star-00 (work in progress), June 2017. 508 [I-D.mglt-lurk-tls] 509 Migault, D., "LURK Protocol for TLS/DTLS1.2 version 1.0", 510 draft-mglt-lurk-tls-01 (work in progress), March 2017. 512 [I-D.nir-saag-star] 513 Nir, Y., Fossati, T., and Y. Sheffer, "Considerations For 514 Using Short Term Certificates", draft-nir-saag-star-00 515 (work in progress), October 2017. 517 [I-D.reschke-http-oob-encoding] 518 Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding 519 for HTTP", draft-reschke-http-oob-encoding-12 (work in 520 progress), June 2017. 522 [I-D.rescorla-tls-subcerts] 523 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 524 "Delegated Credentials for TLS", draft-rescorla-tls- 525 subcerts-02 (work in progress), October 2017. 527 Authors' Addresses 528 Frederic Fieau (editor) 529 Orange 530 40-48, avenue de la Republique 531 Chatillon 92320 532 France 534 Email: frederic.fieau@orange.com 536 Emile Stephan 537 Orange 538 2, avenue Pierre Marzin 539 Lannion 22300 540 France 542 Email: emile.stephan@orange.com 544 Sanjay Mishra 545 Verizon 546 13100 Columbia Pike 547 Silver Spring MD 20904 548 USA 550 Email: sanjay.mishra@verizon.com