idnits 2.17.1 draft-fieau-cdni-interfaces-https-delegation-00.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 are 11 instances of too long lines in the document, the longest one being 17 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 (March 13, 2017) is 2572 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 355 -- Looks like a reference, but probably isn't: '2' on line 355 -- Looks like a reference, but probably isn't: '3' on line 355 == Unused Reference: 'RFC2818' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC6844' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'I-D.cairns-tls-session-key-interface' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'I-D.cdni-fieau-lurk-https-delegation' is defined on line 430, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) ** Downref: Normative reference to an Informational RFC: RFC 7336 ** Downref: Normative reference to an Informational RFC: RFC 7337 == Outdated reference: A later version (-12) exists of draft-reschke-http-oob-encoding-11 == Outdated reference: A later version (-02) exists of draft-rescorla-tls-subcerts-01 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: September 14, 2017 S. Mishra 6 Verizon 7 March 13, 2017 9 CDNI interfaces update for HTTPS delegation 10 draft-fieau-cdni-interfaces-https-delegation-00 12 Abstract 14 Content delivery includes one or more CDNs and in many instances 15 involves cascaded delegation when handling encrypted data. The 16 delivery of such content over HTTPS though raises credential 17 management issues. Two models of HTTPS delegation can be considered: 18 direct delegation, and "cascaded" delegation. While the first model 19 of delegation is addressed by most of the work at the IETF, in the 20 latter case, it is up to downstream CDN(s) delivering the content to 21 an end-user to present legacy credentials of either the origin or of 22 the upstream CDN which delegated the delivery to the aforementioned 23 dCDN. This document presents updates needed in CDNI Control and 24 Metadata interfaces to setup HTTPS delegation between an uCDN and 25 dCDN. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. HTTPS Delegation Models . . . . . . . . . . . . . . . . . . . 3 64 4. Known delegation methods . . . . . . . . . . . . . . . . . . 4 65 5. Delegation definition . . . . . . . . . . . . . . . . . . . . 6 66 6. Credentials management . . . . . . . . . . . . . . . . . . . 7 67 7. Handling delegation expiration . . . . . . . . . . . . . . . 7 68 8. Logging delegation related data . . . . . . . . . . . . . . . 8 69 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 70 10. Security considerations . . . . . . . . . . . . . . . . . . . 8 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 11.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 In most cases, content is delivered over HTTP or HTTPS using one and 79 more CDNs along the delivery path in the direction of end-user. The 80 delivery of the content over HTTPS raises credential management 81 issues. This document presents updates needed in CDNI Control and 82 Metadata interfaces to setup HTTPS delegation between an uCDN and 83 dCDN. 85 It is up to the downstream CDN which delivers the content to the end- 86 user to present credentials of either the origin or of the upstream 87 CDN which delegated the delivery to the aforementioned dCDN. The 88 domain of the certificate presented to the end-user must match the 89 domain delivering content. However, in a model when an entity other 90 than the origin has been delegated to serve secured content on behalf 91 of the certificate owner, then in such case of "cascaded" delegation, 92 an end-user (UA) may not know (or have the ability to know) if the 93 domain of the just authenticated entity delivering the content is the 94 same as the origin domain. Current IETF work on credential 95 delegations do not yet include solutions for cascaded delegation that 96 would allow an UA validate whether content is delivered by origin 97 domain or by a delegated entity on behalf of the origin domain. 99 CDNi framework supports implicit cascade delegation whereas, HTTPS 100 delegation requires explicit transitive delegation to carry the 101 credentials from the origin to dCDN passing through all intermediate 102 CDNs. 104 Several delegation methods are currently proposed within several IETF 105 working groups. The specifications of the provisioning of their 106 credentials (how key is transported and stored) are out of the scope 107 of the document. The intent of the document is to identify update to 108 the CDNI interfaces, namely CDNI control / Triggers and Metadata 109 interfaces to support multiple levels of delegation in CDNI for 110 HTTPS. 112 Section 2 is about terminology used in this document. Section 3 113 shows the delegation models in delivery architectures. Section 4 114 presents delegation methods specified at the IETF. Section 5 115 introduces delegation metadata for CDNI. Section 6 discusses the 116 management of credentials in delegation. Section 7 is about an IANA 117 registry for delegation methods. Section 8 discussed how to address 118 the expiration of a delegation. Section 9 is about logging 119 delegation data. Section 10 shows security issues. 121 2. Terminology 123 This document uses terminology from CDNI framework documents such as 124 CDNi framework document [RFC7336], CDNI requirements [RFC7337] and 125 CDNI interface specifications documents: CDNI Metadata interface 126 [RFC8006], CDNI Control interface / Triggers [RFC8007] and Logging 127 interface [RFC7937]. 129 3. HTTPS Delegation Models 131 This document considers two models for HTTPS delegation and their 132 applicability to CDN interconnection. 134 - Direct HTTPS delegation 136 A uCDN delegates HTTPS delivery to dCDN. The dCDN can deliver 137 contents to the UA on behalf of the uCDN: the uCDN domain stays 138 visible in the UA, the UA accepts a (sub) certificate bound to the 139 uCDN. Only one level of delegation is considered here. 141 +------------+ delivery +---------+ delegation +--------+ +--------+ 142 | TLS Client | <---------- | dCDN | <----------> | uCDN | <----------> | origin | 143 +------------+ +---------+ +--------+ +--------+ 145 Figure 1: Direct HTTPS delegation in CDNI 147 - Cascaded HTTPS delegation: 149 An origin delegates HTTPS delivery to uCDN which in turn delegates 150 delivery to dCDNs. The dCDN can deliver contents to the UA on behalf 151 of the Origin: the origin domain stays visible to the UA, the UA 152 accepts a (sub) certificate bound to the origin. N levels of cascade 153 might be considered here. 155 -- sub-case 1: delivery with origin domain 157 +------------+ delivery +---------+ delegation +--------+ delegation +--------+ 158 | TLS Client | <---------- | dCDN | <----------> | uCDN | <----------> | origin | 159 +------------+ +---------+ +--------+ +--------+ 161 Figure 2: cascaded HTTPS delegation in CDNI 163 -- sub-case 2: delivery with uCDN domain 165 +------------+ delivery +---------+ delegation +--------+ delegation +--------+ 166 | TLS Client | <---------- | dCDN2 | <----------> | dCDN1 | <----------> | uCDN | 167 +------------+ +---------+ +--------+ +--------+ 169 Figure 3: cascaded HTTPS delegation in CDNI 171 In both models, a uCDN could give its private keys to one or more 172 dCDNs. Some virtual hosting providers have required this method of 173 credentials sharing, such as private keys and certificates. However, 174 this is not desirable for the assignee of the credentials, as it 175 significantly degrades the security of the entire architecture. 177 4. Known delegation methods 179 A few methods are currently being proposed at the IETF to handle 180 delegation of HTTPS delivery between entities respecting those 181 constraints. Note that these methods are still an ongoing work at 182 the IETF within specific WG. We however anticipate the need to 183 handle delegation in interconnected CDNs and a need to address within 184 the CDNI WG. Despite the types of delegation methods, we might need 185 a common framework in CDNI that would provide new requirements on the 186 CDNI interfaces. 188 This document considers three methods supporting HTTPS delegation and 189 may be used between two or more CDNs with applicable interface 190 support following the CDNI framework, such as the CI/Triggers and 191 Metadata Interface: 193 - Sub-certificates and short-term certificates 195 In sub-certs [I-D.rescorla-tls-subcerts], a dCDN might be able to 196 present a "delegated_credentials" to UA, containing a cryptographic 197 assertion that it is an authorized delegate of the uCDN. This 198 solution requires changes in the UA. A Delegated credentials has a 199 validity period (no longer than 7 days) and a public key. 201 Short-term certificates [I-D.sheffer-lurk-cert-delegation] are 202 standard certificates with a short period of validity, which can be 203 renewed as long as the delegation is true. Unlike the subcerts, this 204 solution does not require any changes in the UA. In both cases 205 however, periodic certificates provisioning on the CDNs is required. 207 - Keyless SSL / LURK [I-D.mglt-lurk-tls] 209 KeyLess SSL approaches (e.g. LURK) might allow a dCDN get 210 credentials when the UA requests a TLS session establishment. The 211 main objective of keyless SSL is to keep the uCDN (or the origin) 212 private keys stored in a secured Key Server (for instance hosted on 213 the uCDN), so that they would never be exposed to the dCDN caches. 215 - Out-of-Band redirection [I-D.reschke-http-oob-encoding] 217 OOB redirection is a method to enable an Origin to delegate the 218 delivery of contents to another server. This method suggests the use 219 of a resource map that will be downloaded from the origin by the 220 user-agent, instead of the content itself. The UA will be able to 221 contact secondary sources (i.e., CDN caches) to get the content on 222 behalf of the Origin. 224 OOB advantages are dual for the uCDN and the Origin. First, there 225 might be no need to deal with delegated credentials nor private keys 226 at uCDN nor dCDNs, and second, the content can remain encrypted on 227 the dCDN which can be of interest for the Origin. 229 Supporting these delegation methods might end up with the definition 230 of new metadata and triggers, specific to each of them. 232 5. Delegation definition 234 When HTTPS delegation has been set for a specific domain, the dCDN 235 should present the Origin or uCDN certificate or 236 "delegated_credential" instead of its own certificate when content 237 delivery is requested. 239 CDNI might needs to advertise support of HTTPS delegation information 240 and parameters from uCDN to dCDNs. Delegation related metadata might 241 for instance include the delegated domain, and delegation period. 242 Multiple delegations might be advertised for a same domain. 244 We might also consider the dCDN discovery of the key server interface 245 endpoint as well as the mutual authentication of the dCDN and uCDN 246 key server. 248 For instance, the uCDN might advertise to the dCDNs metadata such as 249 the delegation validity (start, end), certificate renewal periodicity 250 (if needed), the delegated domain FQDN. Such information could be 251 for instance, conveyed over the CDNI metadata interface. We might 252 also advertise what is/are the delegation method(s) to use for a 253 given delegated domain (ex. OOB, Subcerts, etc.) between a uCDN and 254 a dCDN. The above information could be carried in a 255 delegationMethodOptions object in the DeliveryDelegation metadata. 257 For instance, delegation might be seen as a new metadata 258 DeliveryDelegation object. 260 Example DeliveryDelegation object: 261 { 262 "generic-metadata-type": "MI.DeliveryDelegation", 263 "generic-metadata-value": 264 { 265 times: [{ 266 "window": [{start: delegationStart, end: delegationEnd}] 267 }], 268 delegationMethodType: "subcerts", // refer to IANA considerations 269 delegationMethodOptions: { 270 "delegatedDomain": domain, 271 "credentialLocationURI": locationURI, 272 "renewalPeriodicity": periodicity, 273 "renewalMode": mode, // "pull" or "push" 274 "KeyServerEndpoint": endpoint 275 } 276 } 277 } 279 According to HTTPS delegation models, we might consider delivery 280 delegation rights to be expressed through a set of metadata received 281 at uCDN or dCDN. As an example, the metadata might indicate if, for 282 instance, the uCDN has been given the right to delegate delivery to 283 other dCDN domains. This could be expressed by "delegabilityAllowed" 284 boolean. Finer granularity might be expected. 286 6. Credentials management 288 In case of certificates based approaches, aka subcerts 289 [I-D.rescorla-tls-subcerts] and short-lived certs 290 [I-D.sheffer-lurk-cert-delegation], there might be a need in CDNI to 291 periodically provision and update credentials (certificates or 292 private keys) on the dCDNs for a given delegated domain. This 293 provisioning phase might be done off-line and is not in the scope of 294 CDNI. 296 We might also need to control credentials, e.g., sub-certificates, 297 renewal demands incoming from dCDNs, or from the uCDN itself. This 298 might be specified in delegation metadata (see Delegation 299 definition). The credentials can be downloaded, either using dCDN 300 pull requests to the uCDN, triggered or not by an UA request, or 301 uploaded via an uCDN push request. Both ways of provisioning might 302 be specified in the corresponding metadata. 304 In Keyless SSL approaches, like LURK [I-D.mglt-lurk-tls], we might 305 have similar needs for CDNI: discovery of the key server, interface 306 for credentials exchanges. The credentials exchanges interface that 307 allows live delivery of credentials (e.g., session keys) at the TLS 308 session setup between the UA and the dCDN should be out of scope of 309 CDNI. 311 OOB redirection [I-D.reschke-http-oob-encoding] might require other 312 specific needs because of its way of working. For example, a uCDN 313 might allow the creation of a resource map pointing at dCDNs 314 pertaining to a delegation. 316 The uCDN and dCDN might accept connections when BC header is 317 positioned to true. In case of expired delegation, enforcement might 318 consist of creating a resource map not containing expired dCDN 319 sources, or a uCDN not giving the necessary keys to decrypt the 320 content stored on the revoked dCDN. 322 7. Handling delegation expiration 324 When the delegation has terminated for a given domain, an uCDN might 325 have to enforce the expiration of the delegation. Expiration of 326 delegation can occur for multiple reasons: changes in delegation 327 rights, delegation validity is over. 329 The uCDN might have then to prevent any dCDN to renew certificates, 330 or access credentials, and might advertise consequently the 331 expiration status to the requesting dCDN for that delegated domain. 333 Removing of credentials in cascade might be ensured by the Control 334 Interfaces / Triggers. 336 CDNI Metadata Interface already provides deliveryAuthorization 337 metadata [RFC8006] (see 7.1.17) which might be used for handling 338 delegation expiration 340 8. Logging delegation related data 342 Regarding logging aspects, we might consider to log usages and errors 343 related to a delegated domain. 345 As an example, CDNI logs might include: supported delegation 346 method(s), credentials renewal requests, credential revocation 347 notice, mutual agreement for selected credential method to use, 348 credentials download status for a specific domain, as well as errors, 349 related to credentials transfer, or crypto aspects such as bad cypher 350 suite supports, revoked delegations, etc. 352 9. IANA considerations 354 The document might consider specifying a registry of delegation 355 methods, e.g. [1] OOB, [2] subcert, [3] shortlivedcert, that might be 356 used in the delegation metadata in CDNI. 358 10. Security considerations 360 The CI/T interface and Metadata interface need only to specify 361 mechanisms for delegation between uCDN and dCDN without the use of 362 actual transfer of encrypting keys within the interface messages. 363 The uCDN actions must be limited to in specifying its support for 364 methods it prefers for delegation, actual delegation and revocation 365 of any delegation. The dCDN similarly, must indicate delegation 366 methods it supports. Any subsequent communications enabling 367 delegation must be limited to the agreed delegation method. 368 Additionally, the HTTPS delegation framework must comply with 369 security considerations as specified within RFC 8007 [CDNI Control 370 Interfaces]. 372 11. References 374 11.1. Normative References 376 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 377 DOI 10.17487/RFC2818, May 2000, 378 . 380 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 381 (TLS) Protocol Version 1.2", RFC 5246, 382 DOI 10.17487/RFC5246, August 2008, 383 . 385 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 386 Housley, R., and W. Polk, "Internet X.509 Public Key 387 Infrastructure Certificate and Certificate Revocation List 388 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 389 . 391 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 392 Authority Authorization (CAA) Resource Record", RFC 6844, 393 DOI 10.17487/RFC6844, January 2013, 394 . 396 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 397 "Framework for Content Distribution Network 398 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 399 August 2014, . 401 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 402 Network Interconnection (CDNI) Requirements", RFC 7337, 403 DOI 10.17487/RFC7337, August 2014, 404 . 406 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 407 and R. Peterkofsky, "Content Distribution Network 408 Interconnection (CDNI) Logging Interface", RFC 7937, 409 DOI 10.17487/RFC7937, August 2016, 410 . 412 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 413 "Content Delivery Network Interconnection (CDNI) 414 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 415 . 417 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 418 Interconnection (CDNI) Control Interface / Triggers", 419 RFC 8007, DOI 10.17487/RFC8007, December 2016, 420 . 422 11.2. Informative References 424 [I-D.cairns-tls-session-key-interface] 425 Cairns, K., Mattsson, J., Skog, R., and D. Migault, 426 "Session Key Interface (SKI) for TLS and DTLS", draft- 427 cairns-tls-session-key-interface-01 (work in progress), 428 October 2015. 430 [I-D.cdni-fieau-lurk-https-delegation] 431 Fieau, F. and S. Emile, "Limited Use of Remote Keys for 432 Interconnected CDNs", draft-cdni-fieau-lurk-https- 433 delegation-00 (work in progress), July 2016. 435 [I-D.mglt-lurk-tls] 436 Migault, D., "LURK Protocol for TLS/DTLS1.2 version 1.0", 437 draft-mglt-lurk-tls-01 (work in progress), March 2017. 439 [I-D.reschke-http-oob-encoding] 440 Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding 441 for HTTP", draft-reschke-http-oob-encoding-11 (work in 442 progress), March 2017. 444 [I-D.rescorla-tls-subcerts] 445 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 446 "Delegated Credentials for TLS", draft-rescorla-tls- 447 subcerts-01 (work in progress), March 2017. 449 [I-D.sheffer-lurk-cert-delegation] 450 Sheffer, Y., "Delegating TLS Certificates to a CDN", 451 draft-sheffer-lurk-cert-delegation-00 (work in progress), 452 May 2016. 454 Authors' Addresses 456 Frederic Fieau (editor) 457 Orange 458 40-48, avenue de la Republique 459 Chatillon 92320 460 France 462 Email: frederic.fieau@orange.com 463 Emile Stephan 464 Orange 465 2, avenue Pierre Marzin 466 Lannion 22300 467 France 469 Email: emile.stephan@orange.com 471 Sanjay Mishra 472 Verizon 473 13100 Columbia Pike 474 Silver Spring MD 20904 475 USA 477 Email: sanjay.mishra@verizon.com