One document matched: draft-mglt-lurk-tls-use-cases-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Edited by John Mattsson for use with xml2rfc -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-mglt-lurk-tls-use-cases-00">

<front>

<title abbrev="TLS Split Use Cases">TLS/DTLS Content Provider Edge Server Split Use Case</title>

   <author fullname="Daniel Migault" initials="D." surname="Migault">
      <organization> Ericsson </organization>
      <address>
        <postal>
          <street> 8400 boulevard Decarie </street>
          <city> Montreal, QC </city>
          <code> H4P 2N2 </code>
          <country> Canada </country>
        </postal>
        <phone> +1 514-452-2160 </phone>
        <email> daniel.migault@ericsson.com </email>
      </address>
    </author>

   <author fullname="Kevin Ma J" initials="K." surname="Ma">
      <organization> Ericsson </organization>
      <address>
        <postal>
          <street> 43 Nagog Park </street>
          <city> Acton, MA  </city>
          <code> 01720 </code>
          <country> USA </country>
        </postal>
        <phone> +1 978-844-5100 </phone>
        <email> kevin.j.ma@ericsson.com </email>
      </address>
    </author>

<date />

<area />

<workgroup />

<keyword />

<abstract>

<t>TLS as been designed to setup and authenticate transport layer between endpoints.</t> 
<t>A lot of applications are using TLS in order to set communications between the applications end points.</t>
<t>As long as applications end points and transport end points were combined into the same host, application authentication could be combined with the transport authentication.</t>
<t>As the current internet is decoupling the transport and application layers, such model may not be applicable anymore. In other words, TLS authentication cannot be handled on behalf of the application authentication.</t>
<t>This document describes use cases where the authentication of the transport layer differs from the authentication performed at the application layer.</t>
</abstract>

</front>

<middle>

<section title="Introduction">

<t>TLS has been designed for end-to-end security between a TLS Server and a TLS Client. As TLS is widely used to provide an authenticated channel between applications, the following models assumes that applications end points and connectivity end point are combined. In that case, authentication of the connection end point and authentication of the application end point could be combined and assimilated as a single authentication.</t>

<t>Such assumption for the TLS model may not be true especially in the current web architecture where application content is not anymore associated with the connection end point. For example, Content Delivery Network are in charge of delivering content they are not necessarily owning.</t> 

<t>This document provides use case where authentication of of the TLS Server involves multiple parties or entities as opposed to a single entity in the standard TLS model. Such uses cases are designated a split use cases to point out that authentication is split between multiple entities.</t>

</section>

<section title="Terminology" anchor="sec-term">
<t>
<list hangIndent="6" style="hanging">
    <t hangText="TLS Client: ">The TLS Client designates the initiator of the TLS session. The terminology is the one of <xref target="RFC5246"/>. The current document considers that the TLS Client and the application initiating the session are hosted on the same host. If not they are hosted on the same administrative domain with a trust relation between the TLS Client and the application. In other words, the client endpoint is considered to be a single entity as described initially in  <xref target="RFC5246"/>.</t>
    <t hangText="TLS Server: ">The TLS Server designates the endpoint of a TLS session initiated by the TLS Client. This document considers that application end points and the TLS session end point my be hosted on different nodes, and may belong to different administrative domains.</t>
    <t hangText="Edge Server: ">The Edge Server designates a node that handles traffic for a Content Provider. A TLS Client initiates a TLS session to authenticate a Content provider, but may be in fact served by a Edge Server that may belong to a different administrative domain.</t>
    <t hangText="Content Provider: ">The owner of the content. This is the entity requested by the application of the TLS Client.</t>
    <t hangText="Content Delivery Network (CDN): ">designates a organization in charge of managing delivery of a content on behalf of a Content Provider. In most cases, the CDN is a different organization than the Content Provider.</t>
</list>
</t>
</section>

<section title="Cloud Use Case" anchor="sec-cloud-use-case">
<t>It is common that applications - like a web browser for example - use TLS to authenticate a Content Provider designated by a web URL and build a secure channel with that Content Provider.</t>  

<t>TLS provides end-to-end security between the two end points of the communication. In our case, the two end points are the web browser also designated as TLS Client and the other end point is the TLS Server hosting the content. When the TLS Server is the Content Provider, the web browser or the TLS Client can use TLS to set an authenticated and secure channel between the web browser and the Content Provider using TLS. On the other hand, TLS can hardly be used in a secure, scalable way when the TLS Server differs from the Content Provider.</t>
 
<t>Suppose that the content of the Content Provider cannot be hosted by a single server. This may be the case for example when a single server is not anymore sufficient to address all the load of the TLS Clients. In this case, the load may be split between multiple instance of servers. Similarly, a Content Provider may chose to place multiple instance of the servers with a limited subset of the content at different places in the network in order to avoid traffic to be conveyed through the whole data center or the content provider infrastructure. In most of the cases, these instances of the servers are places at the edge of the infrastructure. Another reason for having multiple instances may be that the content provider cannot host the entirety of its content on one single server. In that case it may opt for hosting the content on various servers to which the application can be directly connected.</t>

   
<t>When the Content Provider cannot present a single server, the web applications can connect to, it clearly appears that the Content Provider the application is trying to set an authenticated TLS session with and the TLS end point may differ. In the latter case, the TLS end points are designated as Edge Servers. These Edge Servers are used for connectivity and should operate transparently for the application. In other words, the application requires that authentication of the application layer be performed at the transport layer.</t>

<t>In order to enable the web application to authenticate the Content Provider using TLS, two options may be considered:
<list style="format %c):" >
<t>Each Edge Server shares the authentication credential associated to the Content Provider. This case results in each Edge Server usurping the identity of the Content Provider.</t>
<t>The authentication credentials of the Content Provider are kept secret, and any TLS session between a web application and an Edge Server involves some interaction between the Edge Server and the Content Provider.</t>  
</list>
<xref target="sec-discussion"/> evaluates these two possibilities.</t>

  

</section>

<section title="Content Delivery Network Use Case">

<t>The Content Delivery Network Use case is similar as the Cloud use case exposed in <xref target="sec-cloud-use-case"/>. The main difference is that the Edge Servers are not anymore under the responsibility of the Content provider. Instead, the Content Provider has subscribed to a company with a different administrative domain to manage the Edge Server on behalf of the Content Provider. </t>
<t>In the case of Content Distribution Network Interconnection (CDNI) <xref target="RFC6707"/>, it may also that the company with which the Content Provider has contracted may further delegate delivery to another CDN with which the Content Provider has no official business relationship. Even if the Content Provider trusts the upstream CDN, and perhaps has strong legal contracts in place, it has no control over, and possibly no legal recourse against, the further downstream CDNs.</t>

<t>The same options as in <xref target="sec-cloud-use-case"/> apply, but in case of sharing authentication credential of the Content Provider, these credentials are shared outside the administrative borders of the Content Provider.</t>
</section>

<section title="Authentication in Split Scenarios" anchor="sec-discussion">
<t>Access by the Edge Server to the private or secret information of the Content Provider may be performed either by sharing the information between the Content Provider and the Edge Servers or by using an interface between the Edge Servers and the Content Provider.</t>

<t>Sharing secret information between the Content Provider and the Edge Servers increases the risk of leaking information. The risk of leaking information exists as Edge Servers are exposed on the Internet which present a high surface of potential attack as illustrated for example by the Heartbleed attack <xref target="HEART"/>. More specifically, the Heartbleed attack uses a weakness of a software implementation to retrieve the private key used by the TLS server. Such attack would not for example has been so successful if the private key was not stored on the Edge Server.</t>

<t>In addition, the risk increases with the number of Edge Servers and the number of organizations sharing these secrets. In fact when the Edge Servers increases and are managed by multiple organizations, it becomes hard for the Content Provider to control the conformance of the Edge Servers to the security policies enforced by the Content Provider, or to detect when a leakage occurs. At last, from a security point of view, this may be not acceptable the Content Provider .</t>

<t>Currently an interface between the Edge Server and the Content Provider has not been standardized. This may prevent a Content Provider to interact with multiple CDNs, or multiple CDNs to interoperate. In addition, such interface may be used within a CDN in order to manage its own Edge Servers. The absence of a standard interface and the lack of interoperability may also result in the Content Provider sharing the confidential information with a third party organization. This may be not acceptable in a security point of view.</t> 

</section>

<section title="Security Considerations">

<t>One motivation for split scenario is to avoid spreading authentication credentials of the Content Provider in multiple Edge Servers, and so to reduce the leak of such credentials.</t>

<t>On the other hand, preventing the authentication credentials to be hosted  on the Edge Servers do not necessarily prevent any leakage. In fact, the Edge Servers and the Content Providers are likely to use a specific channel that provide access to the credentials. It is of primary importance to design this channel to avoid the Content Provider to reveal any information about the private key. More specifically, even though a Edge Server may become corrupted or under the control of an attacker, the attacker should not be able to be able to disclose the authentication credentials.</t>
   
</section>

<section title="IANA Considerations">
<t>There are no IANA considerations in this document.</t>
</section>

<section title="Acknowledgements">
<t>Thanks are due for insightful feedback on this document to Robert Skog, Salvatore Loreto, John Mattson and Rich Salz.</t> 
</section>


</middle>

<back>

<references title="Normative References">
    <?rfc include="reference.RFC.5246.xml"?>
    <?rfc include="reference.RFC.6707.xml"?>
</references>

<references title="Informative References">
    <reference anchor="HEART" target="http://heartbleed.com/">
        <front>
        <title>The Heartbleed Bug</title>
        <author>
        <organization>Codenomicon</organization>
        </author>
        <date/>
        </front>
    </reference>
</references>
</back>

</rfc>
<!-- 
 -->