Internet DRAFT - draft-slovetskiy-cdni-https-delegation-approaches
draft-slovetskiy-cdni-https-delegation-approaches
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
