[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                      F. Fieau, Ed.
Internet-Draft                                                E. Stephan
Intended status: Standards Track                                  Orange
Expires: January 9, 2017                                    July 8, 2016


           Limited Use of Remote Keys for Interconnected CDNs
               draft-cdni-fieau-lurk-https-delegation-00

Abstract

   Sharing private keys amongst administrative entities raises numerous
   issues for end-users, intermediaries and content origins.  The IETF
   envisions the standardization of protocols to limit the exchange of
   private keys (LURK).  This document presents CDN Interconnection
   (CDNI) use cases based on the Limited Use of Remote Keys (LURK)
   protocol and architecture and identifies a set of requirements.

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 9, 2017.

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




Fieau & Stephan          Expires January 9, 2017                [Page 1]


Internet-Draft                LURK for CDNI                    July 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  CDNI architecture using LURK  . . . . . . . . . . . . . . . .   3
   4.  LURK use cases for CDNI . . . . . . . . . . . . . . . . . . .   6
     4.1.  Use case A: uCDN Key Server . . . . . . . . . . . . . . .   6
     4.2.  Use case B: CSP Key Server  . . . . . . . . . . . . . . .   9
     4.3.  Other use cases . . . . . . . . . . . . . . . . . . . . .  11
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  CDNI Control Interface requirements . . . . . . . . . . .  11
     5.3.  CDNI Footprint and Capabilities Advertisement interface
           requirements  . . . . . . . . . . . . . . . . . . . . . .  12
     5.4.  CDNI Logging Interface requirements . . . . . . . . . . .  12
     5.5.  Key Server Interface requirements . . . . . . . . . . . .  12
   6.  Discussions . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  HTTPS and TLS . . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Cyphersuites in CDNI  . . . . . . . . . . . . . . . . . .  13
     6.3.  PFS . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.4.  TLS version . . . . . . . . . . . . . . . . . . . . . . .  13
     6.5.  Scalability . . . . . . . . . . . . . . . . . . . . . . .  13
     6.6.  Certificates and security . . . . . . . . . . . . . . . .  13
     6.7.  Revocation  . . . . . . . . . . . . . . . . . . . . . . .  14
     6.8.  Certificate provisioning  . . . . . . . . . . . . . . . .  14
     6.9.  CSP side  . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.10. Acquisition . . . . . . . . . . . . . . . . . . . . . . .  14
     6.11. CDNI Control Interface vs CDNI Metadata Interface . . . .  14
   7.  Open issues . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  TLS session resuming  . . . . . . . . . . . . . . . . . .  14
     7.2.  Stack Evolution . . . . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   CDNI requirements [RFC7337] and use cases [RFC6770] specify the
   requirements and use cases of HTTP content delivery between CDNs.
   The intent of this document is to pursue the work by proposing a
   solution for delegating content delivery over secure protocols like



Fieau & Stephan          Expires January 9, 2017                [Page 2]


Internet-Draft                LURK for CDNI                    July 2016


   HTTPS or DTLS.  Conversely to HTTP delivery, HTTPS [RFC2818] allows
   content delivery between Content Service Provider (CSP) and End-users
   with integrity and confidentiality.

   From the CDNI perspective, all parties - UAs, CSPs origin servers,
   and CDNs - are involved in the chain of trust and preserving this
   chain of trust in HTTPS raises concerns.

   Indeed, regarding TLS certificates, CSPs and CDN providers are
   reluctant to share private keys mainly because of legal and security
   issues about private keys.  Therefore the CDNI working group must
   specify a solution that avoids the exchange of private keys between
   CDNs.

   This document leverages the work of the LURK initiative
   [LURK_Mailing_List] and discusses the introduction of a Limited Use
   of Remote Keys (LURK) solution in the CDNI architecture.  It presents
   2 use cases which complement those described in
   [I-D.mglt-lurk-tls-use-cases] and identifies a set of requirements
   for CDNI.  Finally it discusses different options and identifies a
   set of open issues.

   The proposed use cases are based on DNS redirection.  The user agent
   is redirected to a dCDN to establish a TLS session to get HTTPS
   content.  Additional use cases are expected in future versions of the
   draft.

   This version focus on the delivery over HTTPS only.

2.  Terminology

   This document uses terminology from CDNI framework documents such as
   CDNI requirements [RFC7337] and CDNI interface specifications
   documents - CDNI metadata interface [I-D.ietf-cdni-metadata], CDNI
   Control interface [I-D.ietf-cdni-control-triggers] and Logging
   interface [I-D.ietf-cdni-logging].

3.  CDNI architecture using LURK

   This document introduces a Key Server in the CDNI architecture.  The
   general LURK architecture is described in the Session Key interface
   draft [I-D.cairns-tls-session-key-interface].


    +------------+  Handshake  +------------------+    LURK   +------------+
    | TLS Client | <---------> |    TLS Server    | <-------> | Key Server |
    +------------+             +------------------+           +------------+




Fieau & Stephan          Expires January 9, 2017                [Page 3]


Internet-Draft                LURK for CDNI                    July 2016


   Figure 1: General Key Server Architecture

   In CDNI, a LURK interface allows private keys to remain under the
   authority of its owner - typically the CSP or the uCDN - while
   delivering the content over HTTPS.

   The LURK interface can be introduced at different locations in the
   CDNI architecture.  The location of the LURK function depends on the
   use cases.  Additionally, this architecture may support variants
   where the Key server is owned by a third party.


    +------------+  Handshake  +------------------+    LURK   +--------------------------------+
    | TLS Client | <---------> |dCDN TLS Surrogate| <-------> |(uCDN/CSP/3rd Party) Key Server |
    +------------+             +------------------+           +--------------------------------+


   Figure 2: Key Server in CDNI Architecture

   This document complements the LURK architecture of
   [I-D.mglt-lurk-tls-use-cases] with CDNI use cases.  In those use
   cases, content delivery is decoupled from both content acquisition
   and signaling information needed to route and control the request.

   Currently CDNI signaling exchanges occur over the Request Routing
   Redirection interface (information to route the request across CDNs),
   the Metadata interface (per content or group of content information
   about the acquisition and the delivery), the Logging interface
   (exchange of monitoring information about the delivery) and the
   Control interface (information for controlling the lifecycle of the
   aforementioned interfaces).

   The LURK interface for CDNI adds two types of exchange: one for
   acquiring the certificate associated with the origin domain and the
   other for establishing delivery confidentiality and integrity.

   This document presents two use cases of HTTPS delivery which rely on
   a LURK function to avoid exchanging private keys between CDNs:

   A.  uCDN Key server: the CSP has provided his certificate and private
   keys to the uCDN. the uCDN provides the LURK key server and
   interface.

   B.  CSP Key server: the CSP provides the LURK Key Server and
   interface.

   The table below presents the use cases developed in the Section 3.




Fieau & Stephan          Expires January 9, 2017                [Page 4]


Internet-Draft                LURK for CDNI                    July 2016


   +-------------+--------------+----------------+-------------------+
   |Use Case name|UA Redirection|uCDN redirection|CSP Cert delegation|
   +-------------+--------------+----------------+-------------------+
   |UC A: uCDN KS|DNS CNAME     |recursive       |uCDN               |
   +-------------+--------------+----------------+-------------------+
   |UC B: CSP KS |DNS CNAME     |recursive       |No                 |
   +-------------+--------------+----------------+-------------------+


   Figure 3: Use cases description table

   The use cases' call flows are respectful of the CDNI redirection
   [I-D.ietf-cdni-redirection] for the description of redirection
   methods in CDNI.

   They share the same steps.

   The figure below illustrates the framework use cases where the
   surrogate doesn't handle the CSP private keys and where the surrogate
   remotely accesses materials to sign and encrypt information exchanged
   over the TLS connection.


 +----+             +----------+       +----------+                +------+
 | UA |             |surrogate*|       |Key Server|                |Origin|
 +----+             +----------+       +----------+                +------+
   |...                 |                   |                        |
   |1. TLS clientHello  |                   |                        |
   |------------------->|                   |                        |
   |                    |                   |                        |
   |                    |                   |                        |
   |2. TLS serverHello  |+-----------------+|                        |
   |<-------------------||                 ||                        |
   |                    ||                 ||                        |
   |3. Certificate      ||                 ||                        |
   |<-------------------||  LURK Exchanges ||                        |
   |                    ||<--------------->||                        |
   |                    ||                 ||                        |
   |                    ||                 ||                        |
   |                    ||                 ||                        |
   |                    |+-----------------+|                        |
   |4. ServerKeyExchange|                   |                        |
   |<-------------------|                   |                        |
   |... Continued       |                   |                        |


   Figure 4: LURK exchanges in CDNI architecture




Fieau & Stephan          Expires January 9, 2017                [Page 5]


Internet-Draft                LURK for CDNI                    July 2016


4.  LURK use cases for CDNI

   Two use cases are considered in this document to implement LURK in
   CDNI:

   Use Case A.  uCDN Key Server

   Use Case B.  CSP Key Server

4.1.  Use case A: uCDN Key Server

   In this use case, the dCDN has a LURK interface to a Key Server
   hosted at the uCDN side.  It may be typically a case of CDNI regional
   delivery delegation.

   This following example is based on ECDHE cypher suite.  The UA is
   first redirected from the uCDN to a dCDN using a recursive DNS
   redirection.  Then the UA initiates a TLS connection with the dCDN to
   get his content.  Since the dCDN does not store the private keys for
   the requested certificate, it queries the uCDN Key Server (KS) to get
   the credential to establish the TLS session with the User Agent.
   Finally the dCDN can deliver the content in HTTPS to the UA using the
   CSP certificate.

      The UA sends an HTTPS request to the CSP to get a content.

      a. to d.  As seen on figure 5, once the DNS resolution is over,
      i.e., UA was able to resolve dCDN surrogate IP@ steps [a.] to
      [d.], the user agent connects to the dCDN surrogate.  Note that
      DNS cache is not shown on the figure.

      1.  The UA sends a ClientHello, as defined in the TLS protocol
      [RFC5246].  The SNI field of the ClientHello includes the CSP
      domain name.

      2.  The surrogate receives the ClientHello from the UA, and sends
      a ServerHello to the UA.

      3.  The surrogate parses the SNI field, and determines the Key
      Server interface of the CSP domain name.  The surrogate uses this
      piece of information to determine the certificate of the delivery.
      The surrogate sends the public certificate to the UA.  The UA
      validates the certificate.

      4.  The surrogate determines the ECDHE parameters, and requests
      the Key Server to sign these parameters with the CSP private key.
      The request includes the domain name received by the surrogate in
      the SNI field of the ClientHello.



Fieau & Stephan          Expires January 9, 2017                [Page 6]


Internet-Draft                LURK for CDNI                    July 2016


      5.  The Key Server returns the necessary credentials to the dCDN
      surrogate over a secure tunnel.

      6. and 7. the UA and the surrogate exchange public DH parameters
      and compute session keys.

      8.  The UA and the surrogate establish a secure connection.  The
      UA issues its request for content over HTTPS.

      The surrogate then processes the original request.

   Below is an example of the handshake establishment:







































Fieau & Stephan          Expires January 9, 2017                [Page 7]


Internet-Draft                LURK for CDNI                    July 2016


 +----+               +----+            +-------+                 +----+
 | UA |               |dCDN|            |uCDN KS|                 |uCDN|
 +----+               +----+            +-------+                 +----+
   |a. DNS A? FQDN CSP  |                   |                        |
   |---------------------------------------------------------------->|
   |                    |                   |                        |
   |b. DNS CNAME dCDN   |                   |                        |
   |<----------------------------------------------------------------|
   |                    |                   |                        |
   |c. DNS A? dCDN      |                   |                        |
   |------------------->|                   |                        |
   |                    |                   |                        |
   |d. DNS A IP Surrogate                   |                        |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |1. ClientHello (Client Random)          |                        |
   |------------------->|                   |                        |
   |                    |                   |                        |
   |2. ServerHello (Server Random)          |                        |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |3. Certificate (Server certificate)     |                        |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |                    |4. LURK query for Signature (ECDHEParams)   |
   |                    |------------------>|                        |
   |                    |                   |                        |
   |                    |5. LURK response: signature (ECDHEParams)   |
   |                    |<------------------|                        |
   |                    |                   |                        |
   |6. ServerKeyExchange (ECDHParams, Signature)                     |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |7. ClientKeyExchange (clientDHpublic)   |                        |
   |------------------->|                   |                        |
   |Finished            |                   |                        |
   |<------------------>|                   |                        |
   |                    |                   |                        |
   |8. HTTPS request    |                   |                        |
   |------------------->|                   |                        |


   Figure 5: Key Server hosted by uCDN








Fieau & Stephan          Expires January 9, 2017                [Page 8]


Internet-Draft                LURK for CDNI                    July 2016


4.2.  Use case B: CSP Key Server

   This section describes a use case in CDNI where the CSP provides the
   Key Server (KS).

   In this example, the CSP delegates the HTTPS content delivery to an
   uCDN that in turn delegates the HTTPS delivery to a dCDN.  For
   obvious legal or security reasons, the CSP does not want his private
   keys to be stored on all CDNs involved in the interconnection.  In
   that case, the dCDN relies on credentials received from a CSP Key
   Server (KS) to deliver HTTPS content.

   The dCDN cannot here request the KS directly.  Instead, the dCDN LURK
   request will be relayed by the uCDN to the Key Server.  Prior to
   that, the uCDN has to check whether the received LURK request is
   valid, e.g., complies with Content Distribution policies
   [I-D.ietf-cdni-metadata].

   In the following example, the CSP stores his certificates and private
   keys on a Key Server that is able to compute and provide credentials
   for TLS establishment.

      1.  The UA sends a ClientHello to the dCDN's surrogate, as defined
      in the TLS protocol [RFC5246].  The SNI field of the ClientHello
      includes the CSP domain name.

      2.  The dCDN's surrogate receives the ClientHello from the UA, and
      sends a ServerHello to the UA..

      3.  The surrogate parses the SNI field, and determines the Key
      Server interface of the CSP domain name and determine the
      certificate of the delivery.  The surrogate sends the public
      certificate to the UA.  The UA checks the certificate signature
      with the public key.

      4.  The dCDN's surrogate requests the uCDN to sign parameters with
      the private key.

      5.  The uCDN parses the SNI field, and determines the Key Server
      interface of the CSP domain name.  The uCDN relaies the LURK
      request received from the dCDN's surrogate, to the Key Server to
      sign parameters with the private key.

      6.  The Key Server returns the necessary credentials to the uCDN
      surrogate.

      7.  The uCDN returns the necessary credentials to the dCDN's
      surrogate.



Fieau & Stephan          Expires January 9, 2017                [Page 9]


Internet-Draft                LURK for CDNI                    July 2016


      8. and 9. the UA and the surrogate exchange public DH parameters
      and compute session keys.

      10.  The UA and the surrogate establish a secure connection.  The
      UA issues its request for content over HTTPS.

      The surrogate then processes the original request.


 +----+               +----+              +----+                +------+
 | UA |               |dCDN|              |uCDN|                |CSP KS|
 +----+               +----+              +----+                +------+
   | (DNS redirection)  |                   |                        |
   |                    |                   |                        |
   |d. DNS A IP Surrogate                   |                        |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |1. ClientHello (Client Random)          |                        |
   |------------------->|                   |                        |
   |                    |                   |                        |
   |2. ServerHello (Server Random)          |                        |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |3. Certificate (Server certificate)     |                        |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |                    |4. LURK query for Signature (ECDHEParams)   |
   |                    |------------------>|                        |
   |                    |                   |5. LURK query for sign. |
   |                    |                   |----------------------->|
   |                    |                   |                        |
   |                    |                   |6. LURK response        |
   |                    |                   |<-----------------------|
   |                    |                   |                        |
   |                    |7. LURK response: signature (ECDHEParams)   |
   |                    |<------------------|                        |
   |                    |                   |                        |
   |8. ServerKeyExchange (ECDHParams, Signature)                     |
   |<-------------------|                   |                        |
   |                    |                   |                        |
   |9. ClientKeyExchange (clientDHpublic)   |                        |
   |------------------->|                   |                        |
   |Finished            |                   |                        |
   |<------------------>|                   |                        |
   |                    |                   |                        |
   |10. HTTPS request   |                   |                        |
   |------------------->|                   |                        |




Fieau & Stephan          Expires January 9, 2017               [Page 10]


Internet-Draft                LURK for CDNI                    July 2016


   Figure 6: Cascaded delegation with LURK

4.3.  Other use cases

   Other use cases will be described in a further version of this draft.

5.  Requirements

   This section is a first attempt to identify the requirements
   introduced by the delivery of HTTPS content.  Some of the
   requirements are new, whereas others may update existing CDNI
   requirements [RFC7337].

5.1.  General

   LURK-GEN-1: The specification should not require any change in User
   Agent.  This is already stated in [RFC7337]/GEN-2

   Discussion: Despite this is obvious, it is important to notice that
   recent limitation in TLS (version, cyphers...) or HTTP (cyphers)
   documents may constrain User Agent.

   LURK-GEN-2: The user agent should be able to see that the requested
   content is delivered by the CDN using the CSP domain.  Delivery
   domain name SHOULD be the same as the CSP portal domain name (or a
   sub-domain request name)

   LURK-GEN-3: The Certificate delivered by the dCDN and CSP must match
   the domain of the URL [RFC2818].  As an example, it means that no
   certificate error occurs on the UA when the dCDN has redirected the
   UA a dCDN.

   LURK-GEN-4: The dCDN's surrogates which implements LURK interface
   should support the delivery of content of the protocol HTTPS.

   LURK-GEN-5: The dCDNs must be able to present the CSP certificate and
   credentials to the user agent when establishing a TLS session

5.2.  CDNI Control Interface requirements

   LURK-CI-1: The CDNI Control Interface may allow the bootstrapping of
   a Key Server interface.  For example this may include:

   - discovery the Key Server interface endpoint.

   - credentials for Key Server and CDN mutual authentication.

   - TLS version, Certificate types, TLS crypto suites.



Fieau & Stephan          Expires January 9, 2017               [Page 11]


Internet-Draft                LURK for CDNI                    July 2016


   Proposal: add this requirement to the section CDNI Control Interface
   of [RFC7337].

5.3.  CDNI Footprint and Capabilities Advertisement interface
      requirements

   LURK-FC-1: The CDNI Footprint and Capabilities Advertisement
   interface should allow the downstream CDN to communicate to the
   upstream CDN about its capabilities regarding the support of client
   side of the Key Server interface.

5.4.  CDNI Logging Interface requirements

   This section identifies additional requirements related to the CDNI
   Logging interface (LI).

   TLS-LI-1: the CDNI Logging interface should allow a dCDN to report to
   the uCDN logging for deliveries which fail during the establishment
   of the secure connection, e.g., ability to report certificate
   validation error.

   TLS-LI-2: The CDNI Logging interface should allow dCDN to report to
   uCDN logging incomplete deliveries due to encryption errors.
   Discussion: this requirement is mostly a subcase of LI-2 about
   incomplete deliveries.

   LURK-LI-3: the CDNI Logging interface should allow a dCDN to report
   to the uCDN secure connections failures when using LURK interface.

   As an example, the UA can't establish a secure connection to a dCDN
   because either, the credentials provided by a Key Server are invalid,
   or because the Key Server has refused to provide them to the dCDN.

5.5.  Key Server Interface requirements

   LURK-KS-1: A Key Server interface must not allow the exchange private
   keys.  This is the centrality of the LURK interface.

   LURK-KS-2: The Key Server and the requesting CDN must authenticate
   each other, according to the information provided by the CDNI Control
   interface.

   LURK-KS-3: The dCDN Key Server interface must be able to send a LURK
   request to a Key Server.

   As an example (UC A, step 4), the dCDN surrogate determines ECDHE
   parameters (...), and requests the Key Server to sign these




Fieau & Stephan          Expires January 9, 2017               [Page 12]


Internet-Draft                LURK for CDNI                    July 2016


   parameters with the CSP private key.  The request includes the domain
   name received by the surrogate in the SNI field of the ClientHello.

6.  Discussions

6.1.  HTTPS and TLS

   HTTPS contents are delivered with the dCDN credentials.  The
   introduction of a Key Server in the CDNI architecture allows the
   HTTPS content to be delivered with the CSP origin server certificate.
   It conforms to the end-to-end HTTPS framework [RFC7230].

6.2.  Cyphersuites in CDNI

   CDNI WG and LURK WG should use a common set of cyphersuites, or CDNI
   WG should specify or points to the set of suites to support.

   TLS and HTTP2 recommend different set of cypher suites.  CDNI WG
   should clarify which one should be supported in the case of a HTTPS
   delivery based on LURK credentials: HTTP2 Cipher Suite, refer to
   appendix A of [RFC7540] and "backwards-compatibility-security-
   restrictions" in [I-D.draft-ietf-tls-tls13"].

6.3.  PFS

   Should the delivery be PFS proof?

6.4.  TLS version

   Which version of TLS should be supported by LURK: TLS/LTS, TLS1.2,
   TLS1.3?

6.5.  Scalability

   For each TLS session initialization on the dCDNs, the dCDNs need to
   request the KS to get the necessary credentials.  To be scalable, the
   KS may need to be replicated.

6.6.  Certificates and security

   At least one private key per CSP is stored on the KS.  Therefore the
   use of a KS avoids the complexity of duplicating private keys on
   uncontrolled servers.  This also allows the uCDN to maintain a single
   domain name for the CDN interconnection.







Fieau & Stephan          Expires January 9, 2017               [Page 13]


Internet-Draft                LURK for CDNI                    July 2016


6.7.  Revocation

   In the case of an HTTPS delegation revocation, a dCDN has no longer
   the delegation right to deliver a content for a given CSP.  The uCDN
   would then deny access to CSP certificates and credentials derived
   from private keys, and therefore the dCDN would not be able to
   establish the TLS session without triggering a warning on UA Side.

6.8.  Certificate provisioning

   The dCDN may have to retrieve at least once the CSP public
   certificate related to the targeted domain name.  The certificates
   may be cached on the dCDN for a given duration.  .

   Is certificate provisioning in the scope of CDNI as it seems
   implementation dependant?  Which interface provides the certificates
   to the uCDN (Control, Metadata, LURK, ..)?

6.9.  CSP side

   With regard to the use case B, the CSP may provide a Key server.  As
   a consequence the requirement [RFC7337]/GEN-3 should be updated
   accordingly.

6.10.  Acquisition

   Usage of the LURK interface when acquiring content: when the dCDN
   acquires content directly from the origin server, would it have to
   request first the KS to get the uCDN credentials ?

6.11.  CDNI Control Interface vs CDNI Metadata Interface

   What should be carried by the CI or the MI ?

7.  Open issues

7.1.  TLS session resuming

   Not yet addressed in this document, contributors are welcome.

7.2.  Stack Evolution

   Contents might be delivered over other protocols than TCP and than
   HTTP/1.1 in a close future.  The CDNI WG must discuss the support of
   HTTPS delivery over TLS/LTS, TLSv3, DTLS, QUIC and HTTP2.






Fieau & Stephan          Expires January 9, 2017               [Page 14]


Internet-Draft                LURK for CDNI                    July 2016


8.  IANA Considerations

   This document has no IANA considerations.

9.  Security Considerations

   The entire document is about security.

10.  Acknowledgments

   Many thanks to Benoit Gaussen who contributed to this draft.

11.  References

11.1.  Normative References

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

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

   [RFC6770]  Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
              P., Ma, K., and G. Watson, "Use Cases for Content Delivery
              Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
              November 2012, <http://www.rfc-editor.org/info/rfc6770>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <http://www.rfc-editor.org/info/rfc7337>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <http://www.rfc-editor.org/info/rfc7540>.







Fieau & Stephan          Expires January 9, 2017               [Page 15]


Internet-Draft                LURK for CDNI                    July 2016


11.2.  Informative References

   [I-D.cairns-tls-session-key-interface]
              Cairns, K., Mattsson, J., Skog, R., and D. Migault,
              "Session Key Interface (SKI) for TLS and DTLS", draft-
              cairns-tls-session-key-interface-01 (work in progress),
              October 2015.

   [I-D.erb-lurk-rsalg]
              Erb, S. and R. Salz, "A PFS-preserving protocol for LURK",
              draft-erb-lurk-rsalg-01 (work in progress), May 2016.

   [I-D.ietf-cdni-control-triggers]
              Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
              Triggers", draft-ietf-cdni-control-triggers-15 (work in
              progress), May 2016.

   [I-D.ietf-cdni-logging]
              Faucheur, F., Bertrand, G., Oprescu, I., and R.
              Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
              logging-27 (work in progress), June 2016.

   [I-D.ietf-cdni-metadata]
              Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "CDN Interconnection Metadata", draft-ietf-cdni-
              metadata-18 (work in progress), June 2016.

   [I-D.ietf-cdni-redirection]
              Niven-Jenkins, B. and R. Brandenburg, "Request Routing
              Redirection interface for CDN Interconnection", draft-
              ietf-cdni-redirection-18 (work in progress), April 2016.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-13 (work in progress),
              May 2016.

   [I-D.mglt-lurk-tls-use-cases]
              Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios,
              "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use-
              cases-02 (work in progress), June 2016.

   [LURK_Mailing_List]
              "LURK Mailing List", <https://mailarchive.ietf.org/arch/
              search/?email_list=lurk>.






Fieau & Stephan          Expires January 9, 2017               [Page 16]


Internet-Draft                LURK for CDNI                    July 2016


Authors' Addresses

   Frederic Fieau (editor)
   Orange
   40-48, avenue de la Republique
   Chatillon  92320
   France

   Email: frederic.fieau@orange.com


   Emile Stephan
   Orange
   2, avenue Pierre Marzin
   Lannion  22300
   France

   Email: emile.stephan@orange.com

































Fieau & Stephan          Expires January 9, 2017               [Page 17]