[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         D. Migault
Internet-Draft                                                     K. Ma
Intended status: Standards Track                                Ericsson
Expires: December 30, 2016                                       R. Rich
                                                                  Akamai
                                                               S. Mishra
                                                  Verizon Communications
                                                     O. Gonzales de Dios
                                                              Telefonica
                                                           June 28, 2016


                        LURK TLS/DTLS Use Cases
                    draft-mglt-lurk-tls-use-cases-02

Abstract

   TLS as been designed to setup and authenticate transport layer
   between a TLS Client and a TLS Server.  In most cases, the TLS Server
   both terminates the TLS Connection and owns the authentication
   credentials necessary to authenticate the TLS Connection.

   This document provides use cases where these two functions are split
   into different entities, i.e. the TLS Connection is terminated on an
   Edge Server, while authentication credentials are generated by a Key
   Server, that owns the Private Key.

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 December 30, 2016.








Migault, et al.         Expires December 30, 2016               [Page 1]


Internet-Draft             LURK/TLS Use Cases                  June 2016


Copyright Notice

   Copyright (c) 2016 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.  Requirements notation . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   5.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Containers and Virtual Machines Use Cases . . . . . . . .   5
       5.1.1.  Description . . . . . . . . . . . . . . . . . . . . .   5
       5.1.2.  LURK Expectations . . . . . . . . . . . . . . . . . .   6
     5.2.  Content Provider Use Case . . . . . . . . . . . . . . . .   7
       5.2.1.  Description . . . . . . . . . . . . . . . . . . . . .   7
       5.2.2.  LURK Expectations . . . . . . . . . . . . . . . . . .   7
     5.3.  Content Owner / Content Provider Use Case . . . . . . . .   8
       5.3.1.  Description . . . . . . . . . . . . . . . . . . . . .   8
       5.3.2.  LURK Expectations . . . . . . . . . . . . . . . . . .   8
     5.4.  Content Distribution Network Interconnection  Use Case  .   9
       5.4.1.  Description . . . . . . . . . . . . . . . . . . . . .   9
       5.4.2.  LURK Expectations . . . . . . . . . . . . . . . . . .   9
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  LURK Requirements . . . . . . . . . . . . . . . . . . . .  10
     6.2.  Key Server Requirements . . . . . . . . . . . . . . . . .  10
     6.3.  Edge Server Requirements  . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12






Migault, et al.         Expires December 30, 2016               [Page 2]


Internet-Draft             LURK/TLS Use Cases                  June 2016


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   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.

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

   This document provide use case where authentication of the TLS Server
   involves multiple parties or entities as opposed to a single entity
   in the standard TLS model.

3.  Terminology

   TLS Client:   The TLS Client designates the initiator of the TLS
         session.  The terminology is the one of [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 [RFC5246].

   TLS Server:   The TLS Server designates the endpoint of a TLS session
         initiated by the TLS Client.  In the standard TLS, the TLS
         Server, is both the terminating point of the TLS Connection and
         the entity authenticated by the TLS Client.  This document
         considers that the TLS Server be split into the Edge Server
         terminating the TLS Connection and the Key Server providing the
         necessary capabilities to the TLS Client to proceed with the
         authentication.

   Private Key:   is the cryptographic credential used by the TLD client
         to authenticate the TLS Server.  The purpose of this document



Migault, et al.         Expires December 30, 2016               [Page 3]


Internet-Draft             LURK/TLS Use Cases                  June 2016


         is to enable the Private Key to be hosted in the Key Server,
         that is, outside of the TLS Connection terminating point.

   TLS Connection:   The authenticated TLS Connection between the TLS
         Client and the TLS Server.  In this document, the TLS
         connection terminates on the Edge Server and enables
         authenticating the Private Key hosted on the Key Server.

   Key Server:   The server hosting the Private Key. The Key Server
         provides an interface that enable cryptographic operations to
         be performed remotely by the Edge Servers.

   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 in fact be served
         by an Edge Server likely belonging to a different
         administrative domain.

   Content Owner:   The owner of the content.  This is the entity
         requested by the application of the TLS Client.

   Content Provider:   The entity responsible to deliver the content.
         In some cases, the Content Provider also own its own Content
         Delivery Network.

   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.

4.  Architecture Overview

   Figure 1 provides an overview of the architecture considered by the
   different uses cases exposed in this document.

   The TLS Client initiates a TLS connection with the Edge Server (1)
   which is expected to be authenticated by its Private Key. The Edge
   Server terminates the TLS connection of the TLS Client, but does not
   own the Private Key. Instead, the Private Key is owned by the Key
   Server, which performs all cryptographic operations on behalf of the
   Edge Server.  Upon request from the Edge Server, the Key Server
   provides the authentication credentials to the Edge Server (2).
   These authentication credentials depend on the authentication methods
   agreed between the TLS Client and the Edge Server as well as the
   capabilities of the Key Server.  The Authentication Credentials
   returned by the Key Server enables the Edge Server to complete the
   TLS Handshake and the TLS Client to authenticate the Edge Server as a
   key owner of the Private Key (3).



Migault, et al.         Expires December 30, 2016               [Page 4]


Internet-Draft             LURK/TLS Use Cases                  June 2016


   The above described architecture to split the standard TLS Server
   into two functions: the Edge Server that terminates the TLS
   Connection and the Key Server to host the Private Key and perform all
   necessary cryptographic operations for the authentication.


                              <-----------   TLS Server   ------------>
   +------------+             +-------------+           +-------------+
   | TLS Client | <---------> | Edge Server | <-------> | Key Server  |
   +------------+             +-------------+           +-------------+
                                                        | Private Key |
                                                        +-------------+
        1. TLS Connection Initialization
        --------------------------->
                                   2. Authentication Credentials
                                      (Private Key based
                                      cryptographic operations)
                                   <-------------------------->
        3. Finalization of the TLS
           Connection Handshake
        <-------------------------->

        TLS Connection Established
        <==========================>

             Figure 1: TLS Session Key Interface Architecture

5.  Use cases

5.1.  Containers and Virtual Machines Use Cases

5.1.1.  Description

   In virtual environment application servers may run within virtual
   machines or containers.  When TLS is used to provide an authenticated
   and encrypted communication channel to the application, it is
   currently common that the container or the virtual machine hosts the
   Private Key used for the authentication.  Hosting multiple copies of
   the Private Key through the cloud increases the risk of leaking the
   Private Key.

   For example, virtualization and persistent storage of virtual
   machines or containers image over different places in the cloud may
   result in multiple copies of the Private Key through the cloud.  In
   addition, operating system level virtualization is a virtualization
   method with a very low overhead.  Isolation is performed at the
   process and kernel level, which may provide a smaller isolation
   compared to the one provided by the traditional hypervisors.  With



Migault, et al.         Expires December 30, 2016               [Page 5]


Internet-Draft             LURK/TLS Use Cases                  June 2016


   lighter isolation, containers avoid storing private and highly
   sensitive data such as a Private Key.

5.1.2.  LURK Expectations

   In this scenario, LURK enables the cloud provider to store the
   Private Key in a centralized Key Server that is remotely accessed by
   the different instances of the virtual machines or containers.  As
   containers or virtual machines are not hosting the Private Key, the
   risks of leakage due to a lake of strong isolation or due to a
   replication of the image is reduced.  On the other hand, each
   container or virtual machine is likely to interact with the Key
   Server in an authenticated way, in which case, credentials used for
   the authentication is exposed to risks of leakage that are similar to
   those the Private Key were exposed without LURK.  As a result, LURK
   does not reduces the risk of leakage itself, but transfers the risk
   from the Private Key to the containers or virtual machines'
   authentication credentials.  In fact, the consequence of a leakage of
   authentication credentials is reduced compared to those of the
   leakage of the Private Key. First the authentication credential
   restricts the attacker to the operations enabled by the Key Server
   whereas with the Private Key, the attacker is likely to perform any
   cryptographic operations without any restrictions.  Second, by
   nature, the authentication credentials have internal cloud scope and
   can be specific for each container or each virtual machine, whereas
   the Private Key is used for the authentication outside the cloud and
   is shared by all containers or virtual machines.  As a result, a
   revocation of the Private Key would impact all containers or virtual
   machines as well as TLS Client outside the cloud.  On the other hand,
   the impact of revoking an authentication credential could be limited
   to a single container or virtual machine and without any impact for
   any TLS Clients outside the cloud.  In a nutshell, this makes
   management of the authentication credentials much easier than
   management of the Private Key, and so much easier to mitigate a
   leakage.

   In this scenario, the Key Server as well as the containers or virtual
   machine are expected to be hosted on the same Cloud.  As a result,
   the latency between the Key Server and the containers or the virtual
   machine and the Key Server remains limited and acceptable for the TLS
   Client.  In addition, the containers or virtual machines
   communicating with the Key Server may be different applications
   running on different operating systems.








Migault, et al.         Expires December 30, 2016               [Page 6]


Internet-Draft             LURK/TLS Use Cases                  June 2016


5.2.  Content Provider Use Case

5.2.1.  Description

   A Content Provider may use multiple Edge Servers that are directly
   exposed on the Internet.  Edge Servers present a high risk of
   exposure as they are subject to, for example, misconfigurations as
   well as OS and web applications vulnerabilities at the Edge Server.
   For example, as illustrated by the Heartbleed attack [HEART].
   Specifically, the Heartbleed attack uses a weakness of a software
   implementation that allowed retrieval of the private key used by the
   TLS server.  Such attack would not have been successful if the
   private key was not stored on the Edge Server.  In addition, a Cloud
   Provider may run different implementations of web servers, or OS in
   order to make its infrastructure or service less vulnerable to a
   single point of failure.  On the other hand, the diversity of
   implementations increases the risk of a leakage of the Private Key.

5.2.2.  LURK Expectations

   In this scenario, LURK enables a Content Provider to store the
   critical information in a more secured place such as, the Key Server,
   accessed only by all the authenticated Edge Servers.

   Note that if the Private Key is shared between multiple Edge Servers,
   a leakage occurring at one Edge Server compromises all servers and
   the services.  Section 5.1 describes more in depth the difference
   between a leakage of the authentication credentials of the Edge
   Server versus the Private Key.

   In this scenario, the Key Server is accessed by a limited number of
   Edge Servers which are authenticated.  An Edge Server may present a
   vulnerability, it will not have access to the Private Key. It
   eventually may use the identity of the Edge Server to perform
   cryptographic operations with that Private Key, and means should be
   provided to limit the usability of such use.

   In this scenario, the latency between the Edge Server and the Key
   Server depends on the distribution of the Edge Servers.  When Edge
   Servers are far away from the Key Server, the time to set TLS
   Connection may be impacted by this architecture.  In the event, such
   overhead impacts the quality of service of the TLS Client, the
   Content Provider may use multiple Key Servers to reduce the latency
   of the communication between the Edge Server and the Key Server.
   This scenario assumes that we are within a single administrative
   domain, so the Private Key remains inside the boundaries of such
   domain.  In addition, the use of the Key Server prevents a direct
   access to the Private Key.



Migault, et al.         Expires December 30, 2016               [Page 7]


Internet-Draft             LURK/TLS Use Cases                  June 2016


5.3.  Content Owner / Content Provider Use Case

5.3.1.  Description

   It is common that applications - like a web browser for example - use
   TLS to authenticate a Content Owner designated by a web URL and build
   a secure channel with that Content Owner.

   When the Content Owner is not able to support all the TLS Client
   requests or would like to optimize the delivery of its content, it
   may decide to take advantage of a third party delivery service
   designated a Content Delivery Network (CDN) also designated as the
   Content Provider.  This third party is able to locate the Edge
   Servers closer to the TLS Clients in various different geographical
   locations.

   The Content Owner may still want to be authenticated by TLS Client
   while not terminating the TLS Connection of the TLS Client.  In
   addition, while the Content Owner provides the Content Provider the
   content to deliver it may not agree or want to provide its Private
   Key to the Content Provider.  In fact, the Private Key used to
   authenticate the Content Provider may present more value than the
   content itself.  For example, the content may be accessed by devices
   or clients configured with the public authentication credential.  In
   such cases, the leak of the Private Key and the renewal of the
   Private Key would require to configure all these devices.  Such
   additional configuration are likely to affect the image of the
   Content Provider as well as result in some interruption of the
   service.  The content, on the other hand may have only an ephemeral
   value and the Content Owner, may accept the risks of leakage and
   provide the Content Provider the content in cleartext.
   Alternatively, the content may also be encrypted with DRM, so its
   access remains restricted to authorized users only.

5.3.2.  LURK Expectations

   In this scenario, LURK enables a Content Owner to delegate the
   delivery aspects while still controlling the authentication of the
   Content Owner.  Similarly it enables the Content Provider to remain
   focused only on the delivery aspects of the content, without
   supporting the risks associated to the leakage of the Private Key.
   The Content Provider and the Content Owner are different
   administrative entities.  As a result, the Key Server and the Edge
   Servers may be located in different networks and the communication
   between the Edge Server and the Key Server may introduce some delays.
   Such delay may be acceptable for the TLS Client, especially for long
   term TLS connections.  Otherwise, the Content Owner, may provide the
   Key Server to the Content Provider.  This use case is then very



Migault, et al.         Expires December 30, 2016               [Page 8]


Internet-Draft             LURK/TLS Use Cases                  June 2016


   similar to the one described in Section 5.2.  Note that providing the
   Key Server to the Content Provider in a hardware security module for
   example, still prevents the Content Provider to access the Private
   Key while it is able to serve content.

   In this scenario, the Content Owner is likely to involve multiple
   Content Providers.  In addition, the agreement between the Content
   Provider and the Content Owner may take various forms.  The Content
   provider for example, may provide an infrastructure, or a delivery
   service.  As a result, the Content Owner may not control the
   application or TLS library interacting with the Key Server.

5.4.  Content Distribution Network Interconnection Use Case

5.4.1.  Description

   In the case of Content Distribution Network Interconnection (CDNI)
   [RFC6707], it may also that the company with which the Content Owner
   has contracted may further delegate delivery to another CDN with
   which the Content Owner 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.

5.4.2.  LURK Expectations

   In this scenario, LURK enables a delegation between CDNs of the
   delivery without providing the Private Key which would require
   additional agreement.  As a result, LURK provides more agility in the
   delivery of content.  Similarly to Section 5.3 the delegating CDN may
   provide the content but not the Private Key. If the delegating CDN
   hosts the Key Server it needs to to provide an access to the Key
   Server.  On the other hand, the delegating CDN may not even host the
   Key Server, in which case, it may proxy the communications to the
   upstream CDN or the Content Owner.  Other architecture may also
   enable a direct access to the Key Server by the delegated CDN.

   In this scenario, different CDN are interacting, and the access to
   the Key Server may result in substantial additional latencies.  This
   additional latency should not affect the quality of service of the
   delivery service.  In addition, the motivations for providing content
   to the delegated CDN without providing the Private Key are similar to
   those of Section 5.3.








Migault, et al.         Expires December 30, 2016               [Page 9]


Internet-Draft             LURK/TLS Use Cases                  June 2016


6.  Requirements

   The requirements listed in this section are limited to the LURK
   protocol, that is, the exchanges between the Edge Server and the Key
   Server.

6.1.  LURK Requirements

   This section provides the requirements associated to the protocol
   used by the Edge Server and the Key Server.  In the remaining
   section, this protocol is designated as LURK.

   Multiple implementations of Edge Server, located in different
   administrative domains must be able to interact with multiple
   implementations of Key Servers also located in multiple
   administrative domains.  In addition, the scope of LURK is closely
   related to TLS standardized at the IETF.

   R1:  LURK MUST be standardized at the IETF

   LURK is limited to the Edge Server and the Key Server, so it is
   expected to be transparent to the TLS Client.  In addition, in order
   to be deployed in the short term, any modification on the TLS Client
   should be avoided.

   R2:  LURK MUST NOT impact the TLS Client.

6.2.  Key Server Requirements

   The Key Server holds the Private Key, and interacts with the Edge
   Servers.

   R3:  The Key Server MUST be able to provide the necessary
        authentication credential so the TLS Client and the Edge Server
        set an authenticate TLS Connection with the Private Key.

   R4:  The Key Server MUST NOT leak any information associated to the
        Private Key. In particular the Key Server MUST NOT provide a
        generic singing/encryption oracle.

   R5:  The Key Server SHOULD NOT perform any operation outside the
        authentication of a TLS Connection.

   R6:  The Key Server MUST provide confidential information to the Edge
        Sever over an authenticated and encrypted channel.






Migault, et al.         Expires December 30, 2016              [Page 10]


Internet-Draft             LURK/TLS Use Cases                  June 2016


6.3.  Edge Server Requirements

   R7:  The Edge Server SHOULD be provisioned with the public
        authentication credentials.  Note: Public certificate
        provisioning is outside of LURK.

7.  Security Considerations

   LURK provides a centralized control of the Private Key. This
   centralized control was highly motivated by security to limit the
   risk of leakage of the Private Key while providing some flexibility
   and ability for different parties to interact together.  On the other
   hand, centralizing the authentication at the Key Server provides the
   ability to control the access of content.  More specifically, an
   entity that controls the Key Server is able to prevent an
   authenticated access to the content, by either not responding, or
   providing corrupted authentication credentials such as for example
   corrupted premasters to the Edge Server, or signatures that could not
   be checked by the TLS Client.  Such global control of the access to
   content was not that easy when the content was distributed by a
   distributed network of Edge Servers.  As a result such facility may
   be used by some governments agencies or make the Key Server an
   interesting target for attackers to control the access of the
   content.  Note that even though the Key Server may remain inside an
   domain, as it is being accessed by Edge Servers, attackers may
   perpetrate attacks on the Key Server through these Edge Servers.

8.  IANA Considerations

   There are no IANA considerations in this document.

9.  Acknowledgements

   Thanks are due for insightful feedback on this document to Robert
   Skog, Hans Spaak, Salvatore Loreto, John Mattsson, Alexei Tumarkin,
   Yaron Sheffer, Eric Burger, Stephen Farrell, Richard Brunner,
   Stephane Dault, Dan Kahn Gillmor, Joe Hildebrand, Thomas Fossati,
   Kelsey Cairns.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.




Migault, et al.         Expires December 30, 2016              [Page 11]


Internet-Draft             LURK/TLS Use Cases                  June 2016


   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

10.2.  Informative References

   [HEART]    Codenomicon, "The Heartbleed Bug",
              <http://heartbleed.com/>.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, DOI 10.17487/RFC6707, September
              2012, <http://www.rfc-editor.org/info/rfc6707>.

Authors' Addresses

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC   H4P 2N2
   Canada

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com


   Kevin Ma J
   Ericsson
   43 Nagog Park
   Acton, MA    01720
   USA

   Phone: +1 978-844-5100
   Email: kevin.j.ma@ericsson.com


   Rich Salz
   Akamai

   Email: rsalz@akamai.com


   Sanjay Mishra
   Verizon Communications

   Email: sanjay.mishra@verizon.com




Migault, et al.         Expires December 30, 2016              [Page 12]


Internet-Draft             LURK/TLS Use Cases                  June 2016


   Oscar Gonzales de Dios
   Telefonica

   Email: oscar.gonzalezdedios@telefonica.com















































Migault, et al.         Expires December 30, 2016              [Page 13]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/