idnits 2.17.1 draft-fieau-cdni-interfaces-https-delegation-01.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 (July 03, 2017) is 2487 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 359, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 364, 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 (-02) exists of draft-fieau-cdni-https-delegation-01 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-00 == Outdated reference: A later version (-02) exists of draft-rescorla-tls-subcerts-01 Summary: 3 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 4, 2018 S. Mishra 6 Verizon 7 July 03, 2017 9 CDNI interfaces update for HTTPS delegation 10 draft-fieau-cdni-interfaces-https-delegation-01 12 Abstract 14 The delivery of content over HTTPS involving multiple CDNs raises 15 credential management issues. This document recalls the methods 16 under study at the IETF. Then it specifies the updates needed in 17 CDNI Control and Metadata interfaces to setup HTTPS delegation 18 between an uCDN and dCDN. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Known delegation methods . . . . . . . . . . . . . . . . . . 3 57 4. SecuredDelegation object definition . . . . . . . . . . . . . 3 58 5. Delegation methods . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. AcmeStarDelegationMethod object . . . . . . . . . . . . . 6 60 5.2. SubcertsDelegationMethod object . . . . . . . . . . . . . 7 61 6. Metadata Simple Data Type Descriptions . . . . . . . . . . . 7 62 6.1. Periodicity . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. CDNI MI AcmeStarDelegationMethod Payload Type . . . . . . 7 65 7.2. CDNI MI SubCertsDelegationMethod Payload Type . . . . . . 8 66 8. Security considerations . . . . . . . . . . . . . . . . . . . 8 67 9. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 10.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 When content is delivered over HTTPS using one or more CDNs along the 76 path, credential management is required. This is specifically 77 required when an entity delegates delivery of encrypted content to 78 another trusted entity. This document presents updates needed in 79 CDNI Control and Metadata interfaces to setup HTTPS delegation 80 between an uCDN and dCDN. 82 Several delegation methods are currently proposed within several IETF 83 working groups (refer to [I-D.fieau-cdni-https-delegation] for an 84 overview of delegation works ongoing at the IETF). They specify 85 separately the provisioning of their credentials. 87 This document specifies an update to the CDNI control / Triggers and 88 Metadata interfaces to support these methods. Furthermore, it 89 includes a proposal of registry to enable the adding of new methods 90 in the future. 92 Section 2 is about terminology used in this document. Section 3 93 presents delegation methods specified at the IETF. Section 4 94 introduces a secured delegation object for CDNI. Section 5 addresses 95 the delegation methods objects. Section 6 describes simple data 96 types. Section 7 is about an IANA registry for delegation methods. 98 Section 8 raises the security issues. Section 9 opens the 99 discussion. 101 2. Terminology 103 This document uses terminology from CDNI framework documents such as 104 CDNi framework document [RFC7336], CDNI requirements [RFC7337] and 105 CDNI interface specifications documents: CDNI Metadata interface 106 [RFC8006], CDNI Control interface / Triggers [RFC8007] and Logging 107 interface [RFC7937]. 109 3. Known delegation methods 111 A few methods are currently being proposed at the IETF to handle 112 delegation of HTTPS delivery between entities respecting those 113 constraints (refer to [I-D.fieau-cdni-https-delegation]). Note that 114 many of these methods are still an ongoing work at the IETF within 115 specific WGs. 117 We however anticipate the need to handle delegation in interconnected 118 CDNs and a need to address within the CDNI WG. Despite the types of 119 delegation methods, we need a common framework in CDNI that would 120 provide new requirements on the CDNI interfaces. 122 This document considers the following methods supporting HTTPS 123 delegation and may be used between two or more CDNs with applicable 124 interface support following the CDNI framework, such as the CI/ 125 Triggers and Metadata Interface: 127 - Sub-certificates [I-D.rescorla-tls-subcerts] likely to be a TLS WG 128 draft. 130 - Short-term certificates in ACME using STAR API [I-D.ietf-acme-star] 132 4. SecuredDelegation object definition 134 As expressed in [I-D.rescorla-tls-subcerts], when HTTPS origin 135 delivery is requested for a specific domain, the delegate, i.e. a 136 dCDN, presents the Origin, or uCDN certificate or even, 137 "delegated_credential" instead of its own certificate at the TLS 138 handshake to the end. 140 When HTTPS delegation has been set for a specific domain, the dCDN 141 should present the Origin or uCDN certificate or 142 "delegated_credential" instead of its own certificate when content 143 delivery is requested. 145 The SecuredDelegation object metadata aims at describing a secured 146 delegation between an uCDN and dCDN by indicating the delegated 147 domain, the start and end of a delegation, and the delegation method 148 used. 150 property: delegateddomain 152 type: HostMatch 154 Description: It describes the delegated hostname, restricted to 155 Hostname. HostMatch is defined in RFC8006 section 4.3.3. This 156 value should match the SAN value in certificates. 158 property: pathpattern 160 type: PathPattern 162 Description: a PathPattern object contains a PathPattern object 163 with a path to match against a resource's URI path in order to 164 trigger the delegation. It is described in RFC8006, 4.1.4. 166 property: timewindow 168 type: TimeWindow 170 Description: Describes delegation start and end times. Timewindow 171 is defined in RFC8006 section 4.2. 173 Property: delegationmethod 175 type: DelegationMethod 177 Description: the delegation method(s) used between a uCDN and a 178 dCDN (ex. Subcerts, short term cert, etc.), as defined in the 179 next section. 181 As an example: a SecuredDelegation object (which contains a 182 TimeWindow object, DelegationMethod and a HostMatch) that only allows 183 the dCDN to deliver content to clients between 09:00 01/01/2000 UTC 184 and 17:00 01/01/2000 UTC: 186 SecuredDelegation object: 187 { 188 "generic-metadata-type": "MI.SecuredDelegation", 189 "generic-metadata-value": 190 { 191 "timewindow": {start: 946717200, end: 946746000}, 192 "delegationMethod": AcmeStarDelegationMethod, 193 "pathpattern": { 194 "pattern": "/movies/*", 195 "case-sensitive": true 196 }, 197 "delegatedDomain": "www.origin.com", 198 } 199 } 201 Such as object shall be conveyed over the CDNI metadata interface. 203 5. Delegation methods 205 This section defines the delegation methods objects metadata used by 206 a securedDelegation. Each method consists of 4 phases: 208 o Bootstrapping: bootstrapping a secured delegation consists in 209 providing the dCDN with enough parameters to set it up, e.g. ACME 210 servers, Key Servers, etc.. 212 o Credential renewal: In case of certificates based approaches, 213 [I-D.rescorla-tls-subcerts] and [I-D.ietf-acme-star], there is a 214 need in CDNI to periodically provision and update credentials 215 (certificates or private keys) on the dCDNs for a given delegated 216 domain. 218 o Expiration/Revocation: expiration of delegation can occur for 219 multiple reasons: changes in delegation rights, delegation 220 validity is over. In [I-D.rescorla-tls-subcerts] or 221 [I-D.ietf-acme-star] approaches, the uCDN may implicitly enforce 222 revocation and will prevent any dCDN to renew certificates, or 223 access credentials, when delegation is expired. 225 o Logging: Regarding logging aspects, we consider to log usages and 226 errors related to a delegated domain. As an example, CDNI logs 227 include: supported delegation method(s), credentials renewal 228 requests, credential revocation notice, mutual agreement for 229 selected credential method to use, credentials download status for 230 a specific domain, as well as errors, related to credentials 231 transfer, or crypto aspects such as bad cypher suite supports, 232 revoked delegations, etc. 234 5.1. AcmeStarDelegationMethod object 236 This section defines the AcmeStarDelegationMethod object which 237 describes metadata related to the use of Acme Star API presented in 238 [I-D.ietf-acme-star] 240 Property: starproxy 242 Type: Endpoint 244 Description: Used to advertise the STAR Proxy to the dCDN. 245 Endpoint type defined in RFC8006, section 4.3.3 247 Property: acmeserver 249 Type: Endpoint 251 Description: used to advertise the ACME server to the dCDN. 252 Endpoint type is defined in RFC8006, section 4.3.3 254 Property: credentialslocationuri 256 Type: Link 258 Description: expresses the location of the credentials to be 259 fetched by the dCDN. Link type is as defined in RFC8006, section 260 4.3.1 262 Property: periodicity 264 Type: Periodicity 266 description: expresses the credentials renewal periodicity. See 267 next section on simple meta data type. 269 As an example, AcmeStarDelegationMethod object could express the 270 Acme-Star-delegation as the following: 272 AcmeStarDelegationMethod: { 273 "generic-metadata-type": "MI.AcmeStarDelegationMethod", 274 "generic-metadata-value": { 275 "starproxy": "10.2.2.2", 276 "acmeserver": "10.2.3.3", 277 "credentialslocationuri": "www.ucdn.com/credentials", 278 "periodicity": 36000 279 } 280 } 282 5.2. SubcertsDelegationMethod object 284 TBD 286 6. Metadata Simple Data Type Descriptions 288 This section describes the simple data types that are used for 289 properties for objects in this document. 291 6.1. Periodicity 293 A time value expressed in seconds. 295 Type: Integer 297 7. IANA considerations 299 This document requests the registration of the following entries 300 under the "CDNI Payload Types" registry hosted by IANA regarding 301 "CDNI delegation": 303 +----------------------------+---------------+ 304 | Payload Type | Specification | 305 +----------------------------+---------------+ 306 | MI.AcmeStarDelegationMethod| TBD | 307 | MI.SubCertDelegationMethod | TBD | 308 | ... | | 309 +----------------------------+---------------+ 311 7.1. CDNI MI AcmeStarDelegationMethod Payload Type 313 Purpose: The purpose of this Payload Type is to distinguish 314 AcmeStarDelegationMethod MI objects (and any associated capability 315 advertisement) 316 Interface: MI/FCI 318 Encoding: see Section 5.1 320 7.2. CDNI MI SubCertsDelegationMethod Payload Type 322 Purpose: The purpose of this Payload Type is to distinguish 323 SubcertsDelegationMethod MI objects (and any associated capability 324 advertisement) 326 Interface: MI/FCI 328 Encoding: see Section 5.2 330 8. Security considerations 332 The CI/T interface and Metadata interface need only to specify 333 mechanisms for delegation between uCDN and dCDN without the use of 334 actual transfer of encrypting keys within the interface messages. 335 The uCDN actions must be limited to in specifying its support for 336 methods it prefers for delegation, actual delegation and revocation 337 of any delegation. The dCDN similarly, must indicate delegation 338 methods it supports. Any subsequent communications enabling 339 delegation must be limited to the agreed delegation method. 340 Additionally, the HTTPS delegation framework must comply with 341 security considerations as specified within RFC 8007 [CDNI Control 342 Interfaces]. 344 9. Discussion 346 More prospective works include: 348 - Keyless SSL / LURK [I-D.mglt-lurk-tls]: No WG is currently 349 addressing Lurk. 351 - Out-of-Band encoding redirection [I-D.reschke-http-oob-encoding] 353 Should they be considered as delegation methods for CDNI? 355 10. References 357 10.1. Normative References 359 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 360 (TLS) Protocol Version 1.2", RFC 5246, 361 DOI 10.17487/RFC5246, August 2008, 362 . 364 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 365 Housley, R., and W. Polk, "Internet X.509 Public Key 366 Infrastructure Certificate and Certificate Revocation List 367 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 368 . 370 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 371 "Framework for Content Distribution Network 372 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 373 August 2014, . 375 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 376 Network Interconnection (CDNI) Requirements", RFC 7337, 377 DOI 10.17487/RFC7337, August 2014, 378 . 380 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 381 and R. Peterkofsky, "Content Distribution Network 382 Interconnection (CDNI) Logging Interface", RFC 7937, 383 DOI 10.17487/RFC7937, August 2016, 384 . 386 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 387 "Content Delivery Network Interconnection (CDNI) 388 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 389 . 391 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 392 Interconnection (CDNI) Control Interface / Triggers", 393 RFC 8007, DOI 10.17487/RFC8007, December 2016, 394 . 396 10.2. Informative References 398 [I-D.fieau-cdni-https-delegation] 399 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 400 CDNI", draft-fieau-cdni-https-delegation-01 (work in 401 progress), March 2017. 403 [I-D.ietf-acme-star] 404 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 405 Fossati, "Use of Short-Term, Automatically-Renewed (STAR) 406 Certificates to Delegate Authority over Web Sites", draft- 407 ietf-acme-star-00 (work in progress), June 2017. 409 [I-D.mglt-lurk-tls] 410 Migault, D., "LURK Protocol for TLS/DTLS1.2 version 1.0", 411 draft-mglt-lurk-tls-01 (work in progress), March 2017. 413 [I-D.reschke-http-oob-encoding] 414 Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding 415 for HTTP", draft-reschke-http-oob-encoding-12 (work in 416 progress), June 2017. 418 [I-D.rescorla-tls-subcerts] 419 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 420 "Delegated Credentials for TLS", draft-rescorla-tls- 421 subcerts-01 (work in progress), March 2017. 423 Authors' Addresses 425 Frederic Fieau (editor) 426 Orange 427 40-48, avenue de la Republique 428 Chatillon 92320 429 France 431 Email: frederic.fieau@orange.com 433 Emile Stephan 434 Orange 435 2, avenue Pierre Marzin 436 Lannion 22300 437 France 439 Email: emile.stephan@orange.com 441 Sanjay Mishra 442 Verizon 443 13100 Columbia Pike 444 Silver Spring MD 20904 445 USA 447 Email: sanjay.mishra@verizon.com