CDNI Working Group S. Slovetskiy Internet-Draft Ericsson Intended status: Informational July 06, 2015 Expires: January 7, 2016 Approaches to HTTPS-based Request Routing and Delegation draft-slovetskiy-cdni-https-delegation-approaches-00 Abstract This document provides a basic non exhaustive background and discusses potential approaches to the issue of correct delegation of the encrypted (TLS-based) traffic requests between CDNs in inter CDN networks and during interactions between client UAs, CSPs, and CDNs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. The Use Case 3. Problem Scope 4. Solution Approaches 4.1. HTTPS-based Redirection 4.2. Relation to CDNI URI Signing 4.3. DNS-based Redirection 5. Conclusion 6. IANA Considerations 7. Security Considerations 8. Acknowledgements 9. Informative References Authors' Addresses 1. Introduction The potential issue of handling the delegation of encrypted traffic between interconnected CDNs has been recently raised at IETF92 CDNI meeting in Dallas, see [HTTPS-delegation]. Brief survey indicates that there is a multitude of ad hoc approaches for handling TLS-based traffic in CDN environment. However, many of the currently adopted practices seem to have problems of various nature, inhibiting and compromising security, scalability, and ease of operation and maintenance (see e.g. [HTTPS-CDN] and [SSL-Challenges]). The nature of the problems is in the end-to-end nature of the HTTPs/TLS and the fundamentally 3-party nature of interactions between clients, origins, and CDN nodes, where there is a need for the origin to delegate content delivery and trust to CDN network and assure this trust to a user (client). This document is intended as a starting point for discussion. The focus is on the Application Layer level request redirects, whereas other methods are acknowledged. 2. The Use Case This section discusses the Use Case and provides some relevant background information. The Use Case is a typical CDN Request-Routing, but now with all connections encrypted over TLS. The user (UA) initiates a request to the origin server (CSP) for a specific content item, whereas the origin CSP subsequently redirects the user UA to a target CDN surrogate content server, therefore delegating the content delivery to a 3-rd party - CDN. There are multiple Request-Routing mechanisms used in practice, many of which are introduced in [RFC3568]. Most popular can be loosely classified as follows: - DNS-based redirection - HTTP-based redirection - URI rewriting Out of those three, both HTTP redirection and URL rewriting seem to be able to handle the request redirections over TLS transparently and without side effects to the user, whereas DNS-based redirects may have certificate validation problems. Even if no security warning has been issued to the user, there still may be cases when the communication has not been properly secured, see e.g. illuminating survey and categorization of security issues with HTTPS in [SSL-Challenges]. We also gratefully acknowledge a recent survey of the problem and current practices, which has been done in [HTTPS-CDN]. In many places we follow the logic and reiterate some conclusions. 3. Problem Scope When using TLS as an underlying security and encryption mechanism, the end-to-end nature of TLS is enforced, involving two parties in the secure communication. Involving CDN brings a third party in the secure communication process, for which TLS, generally speaking, has not been designed. In the case of DNS-based redirection, the actual redirect happens before the establishment of the TLS tunnel. The problem is that the user UA expects the origin CSP's certificate, but instead obtains the target CDN surrogate's certificate during the TLS handshake. Mismatch between the expected origin CSP URI and the received target CDN URI designated in the obtained certificate causes certificate validation warnings at the UA. Eventually a client UA displays a warning to the end user requiring additional steps, which compromises user satisfaction. In the case of the HTTP-based redirection, TLS set-up happens before the first HTTP request is sent, therefore, the subsequent traffic including request URI and query parameters will be encrypted, making it impossible to signal UA intent to the CSP before the establishment of the TLS tunnel. Therefore, CSP's server would be unable to do any preliminary analysis of the request before the completion of the TLS tunnel setup. Generally speaking, the HTTP-based redirection should not raise any warnings for the user. First, the TLS session is established between the UA and the origin CSP, authenticating the CSP. Then, the CSP uses HTTP mechanisms for redirection, (usually 3xx messages, e.g. 302 Found) embedding the new target URI (for CDN surrogate) in the Location header. UA then sets up a separate TLS session with the CDN surrogate, validating the CDN certificate. Trust relationship is implied since the redirection message has been received over the authenticated TLS tunnel with the origin CSP. However, essentially two independent TLS sessions will have to be setup in sequence by the UA, the only trust delegation endorsement, tying two sessions together being the fact that the target URI has been communicated in the redirection message by the authenticated origin CSP over the encrypted tunnel. However, a user could possibly benefit from a stronger explicit mechanism enforcing the redirection and informing end-users of the trust delegation. The Use Case then becomes as follows: during the redirection over TLS, the origin CSP provides a secure mechanism to bind the CSP certificate with a target CDN surrogate certificate. Having independently obtained the target CDN surrogate certificate during the TLS handshake with the surrogate CDN, a UA would then be capable of ensuring (validating) that the redirection is correct and explicitly endorsed by the CSP. Note that the use case may be extended further to a cascading network of CDNs as defined in CDNI. Additionally, the [ID.leung-cdni-uri-signing] draft defines a mechanism to ensure authenticity of the request redirected from the origin CSP. 4. Solution Approaches This section outlines some approaches to possible solutions. 4.1. HTTPS-based Redirection The following figure (using the notation from [HTTPS-CDN]) illustrates a high level example message flow for an "enhanced" HTTPS-based redirection using an additional client UA validation step: +----+ +--+ +---+ +---+ |User| |UA| |CDN| |CSP| +----+ +--+ +---+ +---+ | | | 1. Trust establishment,| | | | certificate exchange | | | |< - - - - - - - - - - ->| | | | | |2. https://csp.com/.| | | |------------------->| | | | | | | | | 3. start TLS +-+ | | - - - - - - - - - - - - - - - - - - - - ->| | | | | | | | | 4. CSP's Cert | | | |<- - - - - - - - - - - - - - - - - - - - - | | | | | | | | | 5. TLS handshake done | | | |<- - - - - - - - - - - - - - - - - - - - ->| | | | | | | | | 6. HTTP GET | | | |------------------------------------------>| | | | | | | |+-----------------++-+ 7. 3xx, Location:| | | ||trTOKEN indicates|| | https://cdn.csp.com/. | | ||authenticated || | ..?token=trTOKEN | | ||TLS redirection || |<-----------------------------------------| | |+-----------------+| | | +-+ | | | | | | | | 8. start TLS +-+ | | | |- - - - - - - - >| | | | | | | | | | | | 9. CDN's Cert | | | | | |<- - - - - - - - | | | | | | | | | | | |----+ | | | | | | | 10. | | | | | |<---+ Validation | | | | | | | | | | | | | | | | | | 11. TLS handshake done | | +-+ - - - - - - - >| | | | | | | | | | 12. HTTP GET | | | | |----------------->| | | | | | | | | | 13. Content | | | | |<-----------------| | | | | +-+ | | 14. Video | | | |<-------------------| | | | | | | Figure 1: HTTPS-based Request Routing Redirection In this example, a special security token - trTOKEN (TLS redirection token) - is used to indicate the trust delegation that the origin CSP is willing to communicate to the client UA. The token binds together the origin CSP certificate and the target CDN surrogate certificate. It is assumed that the origin CSP and target CDN have previously established a trust relationship, and at a minimum the CDN has provided it's public certificate to the CSP, e.g. by using TLS-based server authentication during content upload to a CDN surrogate or by other means. Alternatively, in stricter scenarios a client-server mutual TLS authentication could be used. Origin CSP server then (e.g. to save space in a target URI) hashes its own certificate and the target CDN certificate, concatenates them, signs and appends to the redirection URI. Redirection URI then is returned to the client UA in the Location header of the 3xx redirect message (or by other means). Having parsed the redirection URI and established the presence of the trTOKEN, client UA extracts both hashes of the origin CSP certificate and the target CDN surrogate certificate. The client UA launches a TLS session with the target CDN surrogate using the redirection URI. During TLS handshake, the target CDN surrogate certificate is obtained, at which point the client UA has the capability to perform an additional validation step including e.g.: - an assertion that the hash of the expected target CDN certificate received in the trTOKEN and the hash computed from the actually received target CDN surrogate certificate match, and - an assertion that the redirection URI and the URI in the target CDN surrogate certificate are the same Having asserted the validity of the redirection, the client UA can then proceed with completing the TLS handshake with confidence that the redirection to the target CDN surrogate has been explicitly endorsed by the origin CSP. Similar mechanism can be used for additional validation in case of the URL rewrite redirection mechanisms. 4.2. Relation to CDNI URI Signing CDNI URI Signing [ID.leung-cdni-uri-signing] draft specifies a detailed mechanism to ensure validation of parameters communicated in the redirection URI. However, the Use Case mostly focuses on the validation by the target CDN of the authenticity of the parameters communicated in the redirect URI generated by the origin CSP. CDNI URI Signing could be extended or used to include the certificate information or hashes either in the provided URI Signing Package Attribute, or in an additional Package Attribute (e.g. Redirect Authentication Attribute), reusing much of the mechanisms detailed in the draft. 4.3. DNS-based Redirection An approach is proposed in [HTTPS-CDN] for the DANE-based [RFC6698] front-end authentication using the DNS-based redirection. We reproduce a brief overview of the proposal from [HTTPS-CDN] here for information as an example of a possible approach. Please review the original paper for much more detailed explanation and rationale. Using DANE, an origin CSP binds target CDN's certificate with the CSP's own certificate and domain name (see section VI. B. of [HTTPS-CDN]) by adding both certificates to the CSP's TLSA record [RFC6698]. After initiating a TLS connection to target CDN surrogate, and having received CDN's certificate, the UA further issues a DNS query to request origin CSP's TLSA records. UA then is capable of validating both URIs and Certificates with those received in the TLSA record, explicitly ensuring the delegation of trust. +----+ +--+ +---+ +---+ |User| |UA| |CDN| |CSP| +----+ +--+ +---+ +---+ | 1. https://csp.com/. | | | |--------------------->| | | | | | | | | 2. csp.com A? (DNS) | | |- - - - - - - - - - - - - - - - - - - - ->| | | | | | | 3. CNAME csp.cdn.com (DNS redirect) | | |<- - - - - - - - - - - - - - - - - - - - -| | | | | | | 4. start TLS +-+ | | |- - - - - - - - >| | | | | | | | | +-+ 5. CDN's Cert | | | | | |<---------------| | | | | | | | | | | | 6. csp.com TLSA? | | | |---------------------------------------->| | | | | | | | | | 7. TLSA csp.com (CSP's and CDN's Certs) | | | |<----------------------------------------| | | | | | | | | | | | | | | |---+ | | | | | | | 8. | | | | | |<--+ Validation | | | | +-+ | | | | | 9. HTTP GET | | | | |---------------->| | | | | | | | | | 10. Content | | | | |<----------------| | | | | +-+ | | 11. Video | | | |<---------------------| | | | | | | Figure 2: DNS-based Request Routing Redirection using DANE 5. Conclusion The current draft presents two possible approaches to explicitly enforce the trust delegation from the origin CSP of the target CDN surrogate in a Request Routing redirection over encrypted TLS tunnel. The approaches will work not only for client to CDN, but also for an inter-CDN connections. The approaches aim at bridging two 2-party end-to-end interactions into one 3-party interaction by providing means for trust delegation from the origin CSP to the target CDN surrogate, and entrusting a client UA with an additional validation step to verify the trust delegation. Both approaches have dependencies on User Agent behaviour to perform an additional validation / authentication step. DNS-based approach additionally requires the use deployment and use of DNSSEC and DANE [RFC6698]. We hope that current draft will serve as the basis for discussion, consideration of possible approach directions, and feasibility assessment of various solutions to address the Request Routing over encrypted TLS connections. 6. IANA Considerations This document has no IANA considerations. 7. Security Considerations No security issues are considered at this stage. 8. Acknowledgements 9. Informative References [HTTPS-delegation] I. Oprescu, "HTTPS and delegation of encrypted traffic between interconnected CDNs", Proc. IETF92-Dallas, March 2015 Available: https://www.ietf.org/proceedings/92/slides/slides-92-cdni-5.pdf [Accessed: 1-Jul-2015] [RFC3568] B. Cain, A. Barbir, R. Nair, and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms.", RFC 3568, July 2003 [HTTPS-CDN] J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu, "When HTTPS Meets CDN: A Case of Authentication in Delegated Service," in 2014 IEEE Symposium on Security and Privacy (SP), 2014, pp. 67-82. [SSL-Challenges] J. Clark and P. C. van Oorschot, "SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements," in 2013 IEEE Symposium on Security and Privacy (SP), 2013, pp. 511-525. [ID.leung-cdni-uri-signing] B. Downey, R. van Brandenburg, M. Fisher, K. Leung, and F. L. Faucheur, "URI Signing for CDN Interconnection (CDNI)." , draft-ietf-cdni-uri-signing-04 (work in progress), June 1, 2015. [RFC6698] P. Hoffman, J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA." RFC 6698, August 2012 Authors' Addresses Sergey Slovetskiy Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514 295 9769 Email: sergey.slovetskiy@ericsson.com