idnits 2.17.1 draft-slovetskiy-cdni-https-delegation-approaches-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 441 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-cdni-uri-signing-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI Working Group S. Slovetskiy 3 Internet-Draft Ericsson 4 Intended status: Informational July 06, 2015 5 Expires: January 7, 2016 7 Approaches to HTTPS-based Request Routing and Delegation 8 draft-slovetskiy-cdni-https-delegation-approaches-00 10 Abstract 12 This document provides a basic non exhaustive background and discusses 13 potential approaches to the issue of correct delegation of the encrypted 14 (TLS-based) traffic requests between CDNs in inter CDN networks and 15 during interactions between client UAs, CSPs, and CDNs. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction 52 2. The Use Case 53 3. Problem Scope 54 4. Solution Approaches 55 4.1. HTTPS-based Redirection 56 4.2. Relation to CDNI URI Signing 57 4.3. DNS-based Redirection 58 5. Conclusion 59 6. IANA Considerations 60 7. Security Considerations 61 8. Acknowledgements 62 9. Informative References 63 Authors' Addresses 65 1. Introduction 67 The potential issue of handling the delegation of encrypted traffic 68 between interconnected CDNs has been recently raised at IETF92 CDNI 69 meeting in Dallas, see [HTTPS-delegation]. 71 Brief survey indicates that there is a multitude of ad hoc approaches 72 for handling TLS-based traffic in CDN environment. However, many of 73 the currently adopted practices seem to have problems of various 74 nature, inhibiting and compromising security, scalability, and ease 75 of operation and maintenance (see e.g. [HTTPS-CDN] and 76 [SSL-Challenges]). 78 The nature of the problems is in the end-to-end nature of the 79 HTTPs/TLS and the fundamentally 3-party nature of interactions 80 between clients, origins, and CDN nodes, where there is a need for 81 the origin to delegate content delivery and trust to CDN network and 82 assure this trust to a user (client). 84 This document is intended as a starting point for discussion. The 85 focus is on the Application Layer level request redirects, whereas 86 other methods are acknowledged. 88 2. The Use Case 90 This section discusses the Use Case and provides some relevant 91 background information. 93 The Use Case is a typical CDN Request-Routing, but now with all 94 connections encrypted over TLS. The user (UA) initiates a request to 95 the origin server (CSP) for a specific content item, whereas the 96 origin CSP subsequently redirects the user UA to a target CDN 97 surrogate content server, therefore delegating the content delivery 98 to a 3-rd party - CDN. 100 There are multiple Request-Routing mechanisms used in practice, many 101 of which are introduced in [RFC3568]. 103 Most popular can be loosely classified as follows: 105 - DNS-based redirection 106 - HTTP-based redirection 107 - URI rewriting 109 Out of those three, both HTTP redirection and URL rewriting seem to 110 be able to handle the request redirections over TLS transparently and 111 without side effects to the user, whereas DNS-based redirects may 112 have certificate validation problems. Even if no security warning has 113 been issued to the user, there still may be cases when the 114 communication has not been properly secured, see e.g. illuminating 115 survey and categorization of security issues with HTTPS in 116 [SSL-Challenges]. We also gratefully acknowledge a recent survey of 117 the problem and current practices, which has been done in 118 [HTTPS-CDN]. In many places we follow the logic and reiterate some 119 conclusions. 121 3. Problem Scope 123 When using TLS as an underlying security and encryption mechanism, 124 the end-to-end nature of TLS is enforced, involving two parties in 125 the secure communication. Involving CDN brings a third party in the 126 secure communication process, for which TLS, generally speaking, has 127 not been designed. 129 In the case of DNS-based redirection, the actual redirect happens 130 before the establishment of the TLS tunnel. The problem is that the 131 user UA expects the origin CSP's certificate, but instead obtains the 132 target CDN surrogate's certificate during the TLS handshake. Mismatch 133 between the expected origin CSP URI and the received target CDN URI 134 designated in the obtained certificate causes certificate validation 135 warnings at the UA. Eventually a client UA displays a warning to the 136 end user requiring additional steps, which compromises user 137 satisfaction. 139 In the case of the HTTP-based redirection, TLS set-up happens before 140 the first HTTP request is sent, therefore, the subsequent traffic 141 including request URI and query parameters will be encrypted, making 142 it impossible to signal UA intent to the CSP before the establishment 143 of the TLS tunnel. Therefore, CSP's server would be unable to do any 144 preliminary analysis of the request before the completion of the TLS 145 tunnel setup. 147 Generally speaking, the HTTP-based redirection should not raise any 148 warnings for the user. First, the TLS session is established between 149 the UA and the origin CSP, authenticating the CSP. Then, the CSP uses 150 HTTP mechanisms for redirection, (usually 3xx messages, e.g. 302 151 Found) embedding the new target URI (for CDN surrogate) in the 152 Location header. UA then sets up a separate TLS session with the CDN 153 surrogate, validating the CDN certificate. Trust relationship is 154 implied since the redirection message has been received over the 155 authenticated TLS tunnel with the origin CSP. However, essentially 156 two independent TLS sessions will have to be setup in sequence by the 157 UA, the only trust delegation endorsement, tying two sessions 158 together being the fact that the target URI has been communicated in 159 the redirection message by the authenticated origin CSP over the 160 encrypted tunnel. 162 However, a user could possibly benefit from a stronger explicit 163 mechanism enforcing the redirection and informing end-users of the 164 trust delegation. 166 The Use Case then becomes as follows: during the redirection over 167 TLS, the origin CSP provides a secure mechanism to bind the CSP 168 certificate with a target CDN surrogate certificate. Having 169 independently obtained the target CDN surrogate certificate during 170 the TLS handshake with the surrogate CDN, a UA would then be capable 171 of ensuring (validating) that the redirection is correct and 172 explicitly endorsed by the CSP. 174 Note that the use case may be extended further to a cascading 175 network of CDNs as defined in CDNI. Additionally, the 176 [ID.leung-cdni-uri-signing] draft defines a mechanism to ensure 177 authenticity of the request redirected from the origin CSP. 179 4. Solution Approaches 181 This section outlines some approaches to possible solutions. 183 4.1. HTTPS-based Redirection 185 The following figure (using the notation from [HTTPS-CDN]) 186 illustrates a high level example message flow for an "enhanced" 187 HTTPS-based redirection using an additional client UA validation 188 step: 190 +----+ +--+ +---+ +---+ 191 |User| |UA| |CDN| |CSP| 192 +----+ +--+ +---+ +---+ 193 | | | 1. Trust establishment,| 194 | | | certificate exchange | 195 | | |< - - - - - - - - - - ->| 196 | | | | 197 |2. https://csp.com/.| | | 198 |------------------->| | | 199 | | | | 200 | | 3. start TLS +-+ 201 | | - - - - - - - - - - - - - - - - - - - - ->| | 202 | | | | | 203 | | 4. CSP's Cert | | 204 | |<- - - - - - - - - - - - - - - - - - - - - | | 205 | | | | | 206 | | 5. TLS handshake done | | 207 | |<- - - - - - - - - - - - - - - - - - - - ->| | 208 | | | | | 209 | | 6. HTTP GET | | 210 | |------------------------------------------>| | 211 | | | | | 212 |+-----------------++-+ 7. 3xx, Location:| | | 213 ||trTOKEN indicates|| | https://cdn.csp.com/. | | 214 ||authenticated || | ..?token=trTOKEN | | 215 ||TLS redirection || |<-----------------------------------------| | 216 |+-----------------+| | | +-+ 217 | | | | | 218 | | | 8. start TLS +-+ | 219 | | |- - - - - - - - >| | | 220 | | | | | | 221 | | | 9. CDN's Cert | | | 222 | | |<- - - - - - - - | | | 223 | | | | | | 224 | | |----+ | | | 225 | | | | 10. | | | 226 | | |<---+ Validation | | | 227 | | | | | | 228 | | | | | | 229 | | | 11. TLS handshake done | 230 | +-+ - - - - - - - >| | | 231 | | | | | 232 | | 12. HTTP GET | | | 233 | |----------------->| | | 234 | | | | | 235 | | 13. Content | | | 236 | |<-----------------| | | 237 | | +-+ | 238 | 14. Video | | | 239 |<-------------------| | | 240 | | | | 242 Figure 1: HTTPS-based Request Routing Redirection 244 In this example, a special security token - trTOKEN (TLS redirection 245 token) - is used to indicate the trust delegation that the origin CSP 246 is willing to communicate to the client UA. The token binds together 247 the origin CSP certificate and the target CDN surrogate certificate. 248 It is assumed that the origin CSP and target CDN have previously 249 established a trust relationship, and at a minimum the CDN has 250 provided it's public certificate to the CSP, e.g. by using TLS-based 251 server authentication during content upload to a CDN surrogate or by 252 other means. Alternatively, in stricter scenarios a client-server 253 mutual TLS authentication could be used. 255 Origin CSP server then (e.g. to save space in a target URI) hashes 256 its own certificate and the target CDN certificate, concatenates 257 them, signs and appends to the redirection URI. Redirection URI then 258 is returned to the client UA in the Location header of the 3xx 259 redirect message (or by other means). 261 Having parsed the redirection URI and established the presence of the 262 trTOKEN, client UA extracts both hashes of the origin CSP certificate 263 and the target CDN surrogate certificate. 265 The client UA launches a TLS session with the target CDN surrogate 266 using the redirection URI. During TLS handshake, the target CDN 267 surrogate certificate is obtained, at which point the client UA has 268 the capability to perform an additional validation step including 269 e.g.: 271 - an assertion that the hash of the expected target CDN 272 certificate received in the trTOKEN and the hash computed from the 273 actually received target CDN surrogate certificate match, and 275 - an assertion that the redirection URI and the URI in the target 276 CDN surrogate certificate are the same 278 Having asserted the validity of the redirection, the client UA can 279 then proceed with completing the TLS handshake with confidence that 280 the redirection to the target CDN surrogate has been explicitly 281 endorsed by the origin CSP. Similar mechanism can be used for 282 additional validation in case of the URL rewrite redirection 283 mechanisms. 285 4.2. Relation to CDNI URI Signing 287 CDNI URI Signing [ID.leung-cdni-uri-signing] draft specifies a 288 detailed mechanism to ensure validation of parameters communicated in 289 the redirection URI. However, the Use Case mostly focuses on the 290 validation by the target CDN of the authenticity of the parameters 291 communicated in the redirect URI generated by the origin CSP. CDNI 292 URI Signing could be extended or used to include the certificate 293 information or hashes either in the provided URI Signing Package 294 Attribute, or in an additional Package Attribute (e.g. Redirect 295 Authentication Attribute), reusing much of the mechanisms detailed in 296 the draft. 298 4.3. DNS-based Redirection 300 An approach is proposed in [HTTPS-CDN] for the DANE-based [RFC6698] 301 front-end authentication using the DNS-based redirection. We 302 reproduce a brief overview of the proposal from [HTTPS-CDN] here for 303 information as an example of a possible approach. Please review the 304 original paper for much more detailed explanation and rationale. 306 Using DANE, an origin CSP binds target CDN's certificate with the 307 CSP's own certificate and domain name (see section VI. B. of 308 [HTTPS-CDN]) by adding both certificates to the CSP's TLSA record 309 [RFC6698]. 311 After initiating a TLS connection to target CDN surrogate, and having 312 received CDN's certificate, the UA further issues a DNS query to 313 request origin CSP's TLSA records. 315 UA then is capable of validating both URIs and Certificates with 316 those received in the TLSA record, explicitly ensuring the delegation 317 of trust. 319 +----+ +--+ +---+ +---+ 320 |User| |UA| |CDN| |CSP| 321 +----+ +--+ +---+ +---+ 322 | 1. https://csp.com/. | | | 323 |--------------------->| | | 324 | | | | 325 | | 2. csp.com A? (DNS) | 326 | |- - - - - - - - - - - - - - - - - - - - ->| 327 | | | | 328 | | 3. CNAME csp.cdn.com (DNS redirect) | 329 | |<- - - - - - - - - - - - - - - - - - - - -| 330 | | | | 331 | | 4. start TLS +-+ | 332 | |- - - - - - - - >| | | 333 | | | | | 334 | +-+ 5. CDN's Cert | | | 335 | | |<---------------| | | 336 | | | | | | 337 | | | 6. csp.com TLSA? | 338 | | |---------------------------------------->| 339 | | | | | | 340 | | | 7. TLSA csp.com (CSP's and CDN's Certs) | 341 | | |<----------------------------------------| 342 | | | | | | 343 | | | | | | 344 | | |---+ | | | 345 | | | | 8. | | | 346 | | |<--+ Validation | | | 347 | +-+ | | | 348 | | 9. HTTP GET | | | 349 | |---------------->| | | 350 | | | | | 351 | | 10. Content | | | 352 | |<----------------| | | 353 | | +-+ | 354 | 11. Video | | | 355 |<---------------------| | | 356 | | | | 358 Figure 2: DNS-based Request Routing Redirection using DANE 360 5. Conclusion 362 The current draft presents two possible approaches to explicitly 363 enforce the trust delegation from the origin CSP of the target CDN 364 surrogate in a Request Routing redirection over encrypted TLS tunnel. 365 The approaches will work not only for client to CDN, but also for an 366 inter-CDN connections. 368 The approaches aim at bridging two 2-party end-to-end interactions 369 into one 3-party interaction by providing means for trust delegation 370 from the origin CSP to the target CDN surrogate, and entrusting a 371 client UA with an additional validation step to verify the trust 372 delegation. 374 Both approaches have dependencies on User Agent behaviour to perform 375 an additional validation / authentication step. 377 DNS-based approach additionally requires the use deployment and use 378 of DNSSEC and DANE [RFC6698]. 380 We hope that current draft will serve as the basis for discussion, 381 consideration of possible approach directions, and feasibility 382 assessment of various solutions to address the Request Routing over 383 encrypted TLS connections. 385 6. IANA Considerations 387 This document has no IANA considerations. 389 7. Security Considerations 391 No security issues are considered at this stage. 393 8. Acknowledgements 395 9. Informative References 397 [HTTPS-delegation] I. Oprescu, "HTTPS and delegation of encrypted 398 traffic between interconnected CDNs", Proc. IETF92-Dallas, March 2015 399 Available: 400 https://www.ietf.org/proceedings/92/slides/slides-92-cdni-5.pdf 401 [Accessed: 1-Jul-2015] 403 [RFC3568] B. Cain, A. Barbir, R. Nair, and O. Spatscheck, "Known 404 Content Network (CN) Request-Routing Mechanisms.", RFC 3568, July 405 2003 407 [HTTPS-CDN] J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu, 408 "When HTTPS Meets CDN: A Case of Authentication in Delegated 409 Service," in 2014 IEEE Symposium on Security and Privacy (SP), 2014, 410 pp. 67-82. 412 [SSL-Challenges] J. Clark and P. C. van Oorschot, "SoK: SSL and 413 HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust 414 Model Enhancements," in 2013 IEEE Symposium on Security and Privacy 415 (SP), 2013, pp. 511-525. 417 [ID.leung-cdni-uri-signing] B. Downey, R. van Brandenburg, M. Fisher, 418 K. Leung, and F. L. Faucheur, "URI Signing for CDN Interconnection 419 (CDNI)." , draft-ietf-cdni-uri-signing-04 (work in progress), June 1, 420 2015. 422 [RFC6698] P. Hoffman, J. Schlyter, "The DNS-Based Authentication of 423 Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA." 424 RFC 6698, August 2012 426 Authors' Addresses 428 Sergey Slovetskiy 429 Ericsson 430 8400 boulevard Decarie 431 Montreal, QC H4P 2N2 432 Canada 434 Phone: +1 514 295 9769 435 Email: sergey.slovetskiy@ericsson.com