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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2016-05-27
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         D. Migault
Internet-Draft                                                     K. Ma
Intended status: Standards Track                                Ericsson
Expires: November 28, 2016                                       R. Rich
                                                                  Akamai
                                                               S. Mishra
                                                  Verizon Communications
                                                     O. Gonzales de Dios
                                                              Telefonica
                                                            May 27, 2016

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

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 November 28, 2016.

Migault, et al.         Expires November 28, 2016               [Page 1]
Internet-Draft             LURK/TLS Use Cases                   May 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 . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   5.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Containers and Virtual Machines Use Cases . . . . . . . .   5
     5.2.  Content Provider Use Case . . . . . . . . . . . . . . . .   6
     5.3.  Content Owner / Content Provider Use Case . . . . . . . .   7
     5.4.  Content Distribution Network Interconnection  Use Case  .   8
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  LURK Requirements . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Key Server Requirements . . . . . . . . . . . . . . . . .   9
     6.3.  Edge Server Requirements  . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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].

Migault, et al.         Expires November 28, 2016               [Page 2]
Internet-Draft             LURK/TLS Use Cases                   May 2016

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 anymore
   associated with the connection end point.  For example, Content
   Delivery Network are in charge of delivering content they are not
   necessarily owning.

   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.

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 so the TLS Client proceed to the
         authentication.

   Private Key :   is the cryptographic credential used to authenticate
         the TLS Server by the TLS Client.  The purpose of the document
         is to enable the Private Key to be hosted in the Key Server
         outside the TLS Connection terminating point.

   TLS Connection :   The authenticated TLS Connection between the TSL
         Client and the TLS Server.  In this document, the TLS

Migault, et al.         Expires November 28, 2016               [Page 3]
Internet-Draft             LURK/TLS Use Cases                   May 2016

         Connection terminates on the Edge Server and authenticates 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 be in fact served
         by a Edge Server that may belong 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 is the managing the 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 performed 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 depends 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).

   Such architecture consists in splitting the standard TLS Server into
   two functions: the Edge Server that terminates the TLS Connection and
   the Key Server that is hosting the Private Key and performs all
   necessary cryptographic operations for the authentication.

Migault, et al.         Expires November 28, 2016               [Page 4]
Internet-Draft             LURK/TLS Use Cases                   May 2016

                              <-----------   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

   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.  On the other hand, 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 lighter isolation, containers avoid storing
   private and highly sensitive data such as a Private Key.

   As a result, in order to prevent the leak of the Private Key used for
   the TLS authentication, cloud provider may prefer storing the Private
   Key in a centralized Key Server that is remotely access by the
   different instances of the virtual machines or containers.

Migault, et al.         Expires November 28, 2016               [Page 5]
Internet-Draft             LURK/TLS Use Cases                   May 2016

   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.

5.2.  Content Provider Use Case

   A Content Provider may use multiple Edge Servers, that are directly
   exposed on the Internet.  Edge Servers presents a high risk of
   exposure as they are subject for example to misconfiguratons as well
   as all vulnerabilities running on the Edge Server.  This includes, os
   vulnerabilities to web applications vulnerabilities.  as illustrated
   for example by the Heartbleed attack [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.  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 vulnerability.
   On the other hand, the diversity of implementations increases the
   risk of a leakage of the Private Key.

   Note that if the Private Key is shared between multiple Edge Servers,
   a leakage occurring at one Edge Server affect the service.

   A Content Provider, may prefer to store the critical information in a
   more contained place the Key Server, accessed only by all the
   authenticated Edge Servers.

   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 case, such
   overhead impact the quality of service of the TLS Client, the Content
   Provider may use multiple Key Servers in order 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

Migault, et al.         Expires November 28, 2016               [Page 6]
Internet-Draft             LURK/TLS Use Cases                   May 2016

   domain.  In addition, the use of the Key Server prevents a direct
   access to the Private Key.

5.3.  Content Owner / Content Provider Use Case

   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 is provides the Content Provider
   the content to deliver it may not accept 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.

   In this scenario, 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 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 prevent the
   Content Provider to access the Private Key while providing its usage.

Migault, et al.         Expires November 28, 2016               [Page 7]
Internet-Draft             LURK/TLS Use Cases                   May 2016

   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 may provide for example, 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

   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.

   In this case, 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
   teh 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.

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

Migault, et al.         Expires November 28, 2016               [Page 8]
Internet-Draft             LURK/TLS Use Cases                   May 2016

   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.

   LURK is associated to TLS related operations performed by the Key
   Server on behalf of the Edge Server.  On the other hand, interactions
   between the Edge Server and the Key Server also consists enable
   control-plan like operations such as reachability, capabilities
   discovery.

   R3:  LURK MUST provide control plane-like facilities such as
        reachability, keep-alive, and capability discovery.

6.2.  Key Server Requirements

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

   R4:  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.

   R5:  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.

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

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

6.3.  Edge Server Requirements

   R8:  The Edge Server SHOULD be provisioned with the public
        authentication credentials, and so public certificate
        provisioning is outside of LURK.

Migault, et al.         Expires November 28, 2016               [Page 9]
Internet-Draft             LURK/TLS Use Cases                   May 2016

7.  Security Considerations

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>.

   [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

Migault, et al.         Expires November 28, 2016              [Page 10]
Internet-Draft             LURK/TLS Use Cases                   May 2016

   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

   Oscar Gonzales de Dios
   Telefonica

   Email: oscar.gonzalezdedios@telefonica.com

Migault, et al.         Expires November 28, 2016              [Page 11]