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

Versions: 00 01

LURK WG                                                  D. Migault, Ed.
Internet-Draft                                                  Ericsson
Intended status: Informational                            March 11, 2017
Expires: September 12, 2017


               LURK Protocol for TLS/DTLS1.2 version 1.0
                         draft-mglt-lurk-tls-01

Abstract

   This document describes the LURK protocol as well as its TLS
   extension designated as LURK/TLS.

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 September 12, 2017.

Copyright Notice

   Copyright (c) 2017 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.






Migault                Expires September 12, 2017               [Page 1]


Internet-Draft                  LURK TLS                      March 2017


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology and Acronyms  . . . . . . . . . . . . . . . . . .   4
   4.  LURK  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  LURK Header . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  Description . . . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  LURK Client Behavior  . . . . . . . . . . . . . . . .   7
       4.1.3.  LURK Server Behavior  . . . . . . . . . . . . . . . .   7
     4.2.  capabilities  . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  Request Payload . . . . . . . . . . . . . . . . . . .   8
       4.2.2.  Response Payload  . . . . . . . . . . . . . . . . . .   8
       4.2.3.  LURK Client Behavior  . . . . . . . . . . . . . . . .   8
       4.2.4.  LURK Server Behavior  . . . . . . . . . . . . . . . .   8
     4.3.  ping  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.3.1.  Request Payload . . . . . . . . . . . . . . . . . . .   8
       4.3.2.  Response Payload  . . . . . . . . . . . . . . . . . .   9
       4.3.3.  LURK Client Behavior  . . . . . . . . . . . . . . . .   9
       4.3.4.  LURK Server Behavior  . . . . . . . . . . . . . . . .   9
     4.4.  Error Message . . . . . . . . . . . . . . . . . . . . . .   9
   5.  LURK/TLS  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  LURK/TLS Header Message . . . . . . . . . . . . . . . . .  10
       5.1.1.  LURK Client Behavior  . . . . . . . . . . . . . . . .  10
       5.1.2.  LURK Server Behavior  . . . . . . . . . . . . . . . .  10
     5.2.  capabilities  . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.1.  Request Payload . . . . . . . . . . . . . . . . . . .  10
       5.2.2.  Response Payload  . . . . . . . . . . . . . . . . . .  10
       5.2.3.  LURK Client Behavior  . . . . . . . . . . . . . . . .  11
       5.2.4.  LURK Server Behavior  . . . . . . . . . . . . . . . .  11
     5.3.  ping  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       5.3.1.  Request Payload . . . . . . . . . . . . . . . . . . .  12
       5.3.2.  Response Payload  . . . . . . . . . . . . . . . . . .  12
       5.3.3.  LURK Client Behavior  . . . . . . . . . . . . . . . .  12
       5.3.4.  LURK Server Behavior  . . . . . . . . . . . . . . . .  12
     5.4.  rsa_master  . . . . . . . . . . . . . . . . . . . . . . .  12
       5.4.1.  Request Payload . . . . . . . . . . . . . . . . . . .  12
       5.4.2.  Response Payload  . . . . . . . . . . . . . . . . . .  13
       5.4.3.  LURK Client Behavior  . . . . . . . . . . . . . . . .  13
       5.4.4.  LURK Server Behavior  . . . . . . . . . . . . . . . .  14
     5.5.  rsa_extended_master . . . . . . . . . . . . . . . . . . .  14
       5.5.1.  Request Payload . . . . . . . . . . . . . . . . . . .  14
       5.5.2.  Response Payload  . . . . . . . . . . . . . . . . . .  15
       5.5.3.  LURK Client Behavior  . . . . . . . . . . . . . . . .  15
       5.5.4.  LURK Server Behavior  . . . . . . . . . . . . . . . .  15
     5.6.  ecdhe . . . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.6.1.  Request Payload . . . . . . . . . . . . . . . . . . .  15
       5.6.2.  ecdhe response payload  . . . . . . . . . . . . . . .  16



Migault                Expires September 12, 2017               [Page 2]


Internet-Draft                  LURK TLS                      March 2017


       5.6.3.  LURK Client Behavior  . . . . . . . . . . . . . . . .  16
       5.6.4.  LURK Server Behavior  . . . . . . . . . . . . . . . .  16
     5.7.  LURK/TLS Options  . . . . . . . . . . . . . . . . . . . .  16
       5.7.1.  with_pfs  . . . . . . . . . . . . . . . . . . . . . .  16
         5.7.1.1.  Request Payload . . . . . . . . . . . . . . . . .  17
         5.7.1.2.  Response Payload  . . . . . . . . . . . . . . . .  17
         5.7.1.3.  LURK Client Behavior  . . . . . . . . . . . . . .  17
         5.7.1.4.  LURK Server Behavior  . . . . . . . . . . . . . .  18
       5.7.2.  with_poo  . . . . . . . . . . . . . . . . . . . . . .  18
         5.7.2.1.  Option Request Payload  . . . . . . . . . . . . .  18
         5.7.2.2.  Option Response Payload . . . . . . . . . . . . .  19
         5.7.2.3.  LURK Client Behavior  . . . . . . . . . . . . . .  19
         5.7.2.4.  LURK Server Behavior  . . . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
     6.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  21
     6.2.  LURK Protocol . . . . . . . . . . . . . . . . . . . . . .  21
     6.3.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     6.4.  ECDHE . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     9.2.  Normative References  . . . . . . . . . . . . . . . . . .  24
   Appendix A.  Example of LURK Exchanges  . . . . . . . . . . . . .  25
     A.1.  LURK/TLS RSA Master Secret  . . . . . . . . . . . . . . .  25
     A.2.  LURK/TLS RSA Extended Master Secret . . . . . . . . . . .  26
     A.3.  LURK/TLS ECDHE Signature  . . . . . . . . . . . . . . . .  28
     A.4.  LURK/TLS/sECDHE Unpredictable . . . . . . . . . . . . . .  29
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  30

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

   This document describes the use of Limited Use of Remote Keys (LURK)
   in the context of TLS1.1 and TLS1.2, with the LURK TLS extension also
   designated as LURK/TLS.  Typically, an Edge Server that terminates a
   TLS session without hosting the secret key performs remote secret key
   cryptographic operations on the Key Server using LURK/TLS as the
   communication protocol between these two entities.  LURK/TLS
   communications are performed between a LURK Client hosted on the Edge
   Server and a LURK Server hosted on the Key Server.
   [I-D.mglt-lurk-tls-use-cases] describes more in depth use cases where
   LURK/TLS may be used.



Migault                Expires September 12, 2017               [Page 3]


Internet-Draft                  LURK TLS                      March 2017


   The main advantage of LURK/TLS is that it does not require any
   changes on TLS Client and as such, constitutes an appropriate
   solution for legacy devices using TLS1.1 or TLS1.2.  On the other
   hand, LURK/TLS introduces additional exchanges between the Edge
   Server and the Key Server which increases the latency when setting a
   TLS session.  With TLS version greater than 1.2, new TLS extensions
   [draft-rescola-tls-subcerts] are expected to use delegated
   credentials to avoid sharing a given secret key in all Edge Servers
   while removing the latency introduced by LURK/TLS.  Such extensions
   needs some modifications of the TLS Client.

   This document limits the LURK/TLS extension to the following
   authentication methods: RSA [RFC5246], [RFC6347] ECDHE_RSA,
   ECDHE_ECDSA [RFC4279] with TLS1.2 or 1.1.

   LURK/TLS exchanges are expected to be performed over an authenticated
   and encrypted channel such as TLS or IPsec.  LURK/TLS message are
   composed of a LURK Header and a Payload as defined in Figure 1 .

   LURK message are not limited to TLS-related cryptographic operations.
   As a result, the context or extension in which LURK exists is likely
   to evolve over time.  This document is essentially focused on the use
   of LURK in the scope of TLS with the LURK/TLS extension.  As to
   enable future extension, this document also describes generic use of
   LURK, common to any extension also designated as LURK.

   The LURK Header is expected to be common to all future LURK
   extensions and carry sufficient information so the receiver can
   clearly identify the extension as well as the purpose of the message.
   These information will determine the appended Payload.

                   +----------------------------------+
                   |           LURK Header            |
                   +----------------------------------+
                   |                                  |
                   | LURK Payload or LURK/TLS Payload |
                   |                                  |
                   +----------------------------------+

                    Figure 1: LURK Message Description

3.  Terminology and Acronyms

   In addition to the terminology defined in
   [I-D.mglt-lurk-tls-use-cases], this document introduces the following
   terminology:





Migault                Expires September 12, 2017               [Page 4]


Internet-Draft                  LURK TLS                      March 2017


   - LURK Client :   The entity sending LURK requests to the LURK
         Server.  In a TLS context, the LURK Client is expected to be
         hosted on the Edge Server.

   - LURK Server :   The entity receiving LURK request from the LURK
         Client and responding to those requests.  In a TLS context, the
         LURK Server is expected to be hosted on the Key Server.

4.  LURK

4.1.  LURK Header

4.1.1.  Description






































Migault                Expires September 12, 2017               [Page 5]


Internet-Draft                  LURK TLS                      March 2017


enum {
    lurk (0), (255)
} ExtensionDesignation;

struct {
     ExtensionDesignation extension_designation;
     int8 extension_version;
} Extension;

enum {
    request (0), success (1), unsupported_extension (2),
    unsupported_status (4), unsupported_type (5), temporary_failure (6),
    error(7)  (255)
} Status;

enum {
   capabilities (0), ping (1), (255)
}LURKMessageType;

struct {
    select(ExtensionDesignation){
        case "lurk":
            LURKMessageType;
    }
}MessageType;

struct {
    Extension extension;
    Status status;
    MessageType message_type;
    unint32 length;
    uint64 id;
} LURKHeader;

                          LURK Header Description

   extension  describes the extension as well as the version of the
      extension considered.

   status  defines whether the message is a request, a response with the
      associated status.

   message_type  describes the message carried by the header.  Message
      types have specific meanings for each (extension_designation,
      extension_version).

   length  length of the entire message, including header, in bytes.




Migault                Expires September 12, 2017               [Page 6]


Internet-Draft                  LURK TLS                      March 2017


   id identifies the exchange and bind response to query.

4.1.2.  LURK Client Behavior

   This section is focused on LURK, so the extension is set to "lurk".
   This document RECOMMENDS to set the extension_version to 1 as it is
   the only value defined.  However, in order to enable extension
   discovery across different LURK versions, the message_type
   "capabilities" can be used with any extension version.

   The LURK Client is only able to send requests and MUST set the status
   header field to "request".

   Upon receiving a response, the LURK Client MUST check the extension,
   extension_version, message_type and id corresponds to a request that
   has been sent recently.  How long the LURK Client should keep track
   of response is implementation dependent and depends on use cases.
   Message without corresponding request are ignored.

4.1.3.  LURK Server Behavior

   The LURK Server checks if the extension is supported.  If the
   extension_designation or its associated extension_version is not
   supported, the LURK Server returns an "unsupported_extension" error.
   However, for interoperability with future extension versions when the
   extension_designation is set to "lurk", the LURK Server MUST ignore
   the extension_version if the message_type is set to "capabilities".

   The LURK Server checks the message_type is both valid and supported
   by the LURK Server.  Validity of a message_type is defined by this
   document while its support by a LURK Server depends on how the LURK
   Server has been configured.  If the message_type is either not valid
   or not supported by the LURK Server, a "unsupported_message_type"
   error is returned.

   The LURK Server checks the status is set to "request", otherwise the
   Key Server returns an "unsupported_status" error.

   When the LURK Server has validated the LURK header, the LURK Server
   processes the request and provide a response payload as well as a
   status.  When the returned status is "success" the response payload
   is the expected response, otherwise when the status reports an error.
   The extension, message_type and id fields of the response MUST have
   the same values as the corresponding request.

   When overloaded, the LURK Server MAY send a temporary_failure error
   to indicate its inability to treat the request.




Migault                Expires September 12, 2017               [Page 7]


Internet-Draft                  LURK TLS                      March 2017


   When another error occurs, the status is set to "error".

4.2.  capabilities

4.2.1.  Request Payload

   A LURK "capabilities" request has no payload.

4.2.2.  Response Payload

   The "capabilities" response payload consists in a list of the
   supported extensions and extension_versions.

   struct {
       LURKSupportedExtension lists_of_supported_extensions<2..2^16-2>;
       opaque lurk_state<32>;
   }LURKCapabilitiesResponsePayload;

                    LURK Capability Payload Description

   extension is defined in Section 4.1

   lurk_state  The hash of the LURKSupportedExtension.  This value is
      returned in error messages as to indicate whether the
      configuration has been updated and if a new LURK capability
      request needs to be sent.

4.2.3.  LURK Client Behavior

   The LURK Client sends a "capabilities" request in a "lurk" extension
   to discover the various extensions and versions supported by the LURK
   Server.

4.2.4.  LURK Server Behavior

   The LURK Server lists the supported extensions and version the
   requester is authorized to request and sends the response.

4.3.  ping

4.3.1.  Request Payload

   A LURK "ping" request has no payload.








Migault                Expires September 12, 2017               [Page 8]


Internet-Draft                  LURK TLS                      March 2017


4.3.2.  Response Payload

   A LURK "ping" response has no payload.

4.3.3.  LURK Client Behavior

   The LURK Client sends a "ping" request to test the reachability of
   the LURK Server.  The reachability is performed within a LURK
   relation.

4.3.4.  LURK Server Behavior

   The LURK Server sends the corresponding response.

4.4.  Error Message

   The error code is indicated by the status when its value differs from
   "request" or "success".

   Error message MAY have no Payload.  Error message MAY also carry a
   state value that indicates a change in the configuration of the LURK
   Server.  The state is expected to reflect any change of the
   configuration associated to the extension.  Generation of the state
   is implementation dependent and out of the scope of this document.
   It can typically be implemented as a counter that is incremented any
   time the extension configuration is updated, or as the hash function
   of the configuration file.

   Upon reception of the state, if the LURK Client has stored the
   previous value, it is expected to compare the two values.  A mismatch
   indicates that extension configuration change and the LURK Client
   SHOULD perform a LURK extension discovery with a "capabilities"
   request.  If the two values matches a extension discovery SHOULD NOT
   be performed.  The absence of ErrorPayload is considered as a
   mismatch.

   struct {
       opaque lurk_state<32> ;
   }ErrorPayload;

                         Error Payload Description

5.  LURK/TLS








Migault                Expires September 12, 2017               [Page 9]


Internet-Draft                  LURK TLS                      March 2017


5.1.  LURK/TLS Header Message

   The LURK/TLS extends LURK in a TLS context.  This document extends
   the ExtensionDesignation structure to LURK/TLS by adding a "tls"
   designation with an associated extension_version set to 1.  Similarly
   it extends MessageType structure with LURKTLSMessageType.

 enum {
     tls(1), (255)
 } ExtensionDesignation;

 enum {
    capabilities (0), ping (1), rsa_master (2), rsa_extended_master (3),
    rsa_master_with_pfs (4), echde (5), ecdhe_with_pfs (6),
    ecdhe_with_poo (7), ecdhe_with_pfs_poo (8), (255)
 }LURKTLSMessageType;

 struct {
     select(ExtensionDesignation){
         case "tls":
             LURKTLSMessageType;
     }
 }MessageType;

                          LURK/TLS Message Header

5.1.1.  LURK Client Behavior

   When sending a request, the LURK Client MUST set extension to "tls",
   extension_version to "1" and status to "request".

   Reception of the response is handled as described in Section 4.1.

5.1.2.  LURK Server Behavior

   The LURK Server proceeds as described in Section 4.1.

5.2.  capabilities

5.2.1.  Request Payload

   A LURK "capabilities" request has no payload.

5.2.2.  Response Payload

   The "capabilities" response payload consists in a list of LURK/TLS
   Capabilities.  A LURK/TLS Capability groups the supported message
   types, certificates and Signature and hash algorithms that are



Migault                Expires September 12, 2017              [Page 10]


Internet-Draft                  LURK TLS                      March 2017


   compatible.  A LURKTLSCapability is defines such as any combination
   of any list member is compatible.

 struct {
     MessageType list_of_message_type<2..2^16-2>;
     Certificates list_of_certificates<2..2^26-2>;
                                            // RFC5246 section 7.4.2
     SignatureAndHashAlgorithm list_of_algo<2..2^16-2>;
                                            // RFC5246 section 7.4.1.4.1
 } LURKTLSCapability;

 struct {
     LURKTLSCapability lists_of_capability<2..2^16-2>;
     opaque state<32>;
 }LURKCapabilitiesResponsePayload;

                    LURK Capability Payload Description

   extension is defined in Section 4.1

   list_of_message_type  the list of message type.

   list_of_certificates  designates the certificates associated to
      message type.  The format is defined in [RFC5246] in section 7.4.2

   list_of_algo  designates supported signature algorithms as well as
      PRF used for the different operations.  Note that the current
      definition does not enable to distinguish between the hash
      functions used outside the extension of signature operations.  The
      format is defined in [RFC5246] section 7.4.1.4.1.

   state  characterizes the LURK/TLS configuration.

5.2.3.  LURK Client Behavior

   The LURK Client is expected to perform a capability request in order
   to determine the possible operations.  Note that Capabilities are
   indicative.

   The LURK Client is expected to keep the state value to be able to
   detect a change in the LURK Server configuration when an error
   occurs.

5.2.4.  LURK Server Behavior

   The capabilities are defined by the LURK Server from its
   configuration file.




Migault                Expires September 12, 2017              [Page 11]


Internet-Draft                  LURK TLS                      March 2017


5.3.  ping

5.3.1.  Request Payload

   A LURK/TLS "ping" request has no payload.

5.3.2.  Response Payload

   A LURK/TLS "ping" response has no payload.

5.3.3.  LURK Client Behavior

   The LURK Client sends a "ping" request to test the reachability of
   the LURK Server.  The reachability is performed within a LURK/TLS
   relation.

5.3.4.  LURK Server Behavior

   The LURK Server sends the corresponding response.

5.4.  rsa_master

5.4.1.  Request Payload

enum {
    sha256_32 (0), (255)
}KeyPairIdType;

struct {
    KeyPairIdType type;
    opaque data; // length defined by the type
} KeyPairID;

struct {
    KeyPairID key_id;
    Random client_random;           // see RFC5246 section 7.4.1.2
    Random server_random;
    ProtocolVersion tls_version;    // see RFC5246 section 6.2.1
}LURKTLSBase;

struct {
    LURKTLSBase base;
    PRFAlgorithm master_prf;              // see RFC5246 section 6.1
    EncryptedPreMasterSecret  pre_master; // see RFC5246 section 7.4.7.1
                                          // Length depends on the key.
} LURKTLSRSAMasterRequestPayload;

                  rsa_master request payload description



Migault                Expires September 12, 2017              [Page 12]


Internet-Draft                  LURK TLS                      March 2017


   key_id  The identifier of the RSA key.  This document defines
      sha256_32 format which takes the 32 first bits of the hash of the
      public key using sha256.

   master_prf  the Pseudo Random Function Algorithm to generate the
      master secret as defined in [RFC5246] Section 6.1.

   client_random  The random value associated to the TLS Client as
      defined in [RFC5246] Section 7.4.1.2.

   server_random  The random value associated to the TLS Server as
      defined in [RFC5246] Section 7.4.1.2.

   tls_version  The TLS version set by the TLS Client as defined in
      [RFC5246] Section 6.2.1.

   EncryptedPreMasterSecret  The encrypted master secret as defined in
      [RFC5246] Section 7.4.7.1.

5.4.2.  Response Payload

   The Response Payload corresponds to the master secret.

   struct {
       opaque master[0..47];
   } LURKTLSRSAMasterResponsePayload;

                  LURK TLS RSA Master Secret Description

   rsa_master extends the Status structure with the following error
   codes:

   enum {
       unvalid_key_pair_id_format (128), unvalid_key_pair_id (129),
       unvalid_encrypted_master_length (130) unvalid_prf (131),
       unvalid_tls_version (131), unvalid_payload_format (132), (255)
   } Status;

5.4.3.  LURK Client Behavior

   A rsa_master request is sent so the LURK Server can derive the master
   secret used by the TLS session.  Upon receipt of the master_secret
   the Edge Server can generate the session keys and finish the TLS key
   exchange protocol.







Migault                Expires September 12, 2017              [Page 13]


Internet-Draft                  LURK TLS                      March 2017


5.4.4.  LURK Server Behavior

   Upon receipt of a rsa_master request, the LURK Server proceeds
   according to the following steps:

   (1)  Checking LURKTLSBase:

        (a)  The LURK Server checks the RSA key pair is available
             (key_id).  If the format of the key pair identifier is not
             understood, an unvalid_keypair_id_format error is returned.
             If the designated key pair is not available an
             unvalid_keypair_id error is returned.

        (b)  The LURK Server checks the length of the encrypted
             premaster secret and so the length of the payload.  In case
             of length mismatch and unvalid_payload_format is returned.
             Note that the length can be derived from the public key, so
             the error only reveals public information.

        (c)  If the TLS version is not supported or is different from
             1.1 or 1.2 an unsupported_tls_version error is returned.

   (2)  The LURK Server checks the prf.  If it does not support the PRF,
        an unvalid_prf is returned.

   (3)  the LURK Server decrypts the encrypted premaster secret as
        described in [RFC5246] section 7.4.7.1.  When a PKCS1.5 format
        error is detected, or a mismatch between the TLS versions
        provided as input and the one indicated in the encrypted
        premaster secret, the Key Server returns a randomly generated
        master secret.

   (4)  If the pre master is appropriately decrypted, then the master
        secret is computed as described in [RFC5246] section 8.1 using
        the PRF, client_random, and server_random provided by the LURK
        Client.

   (5)  The LURK Server returns a master secret in a
        LURKTLSRSAMasterResponsePayload.

5.5.  rsa_extended_master

5.5.1.  Request Payload








Migault                Expires September 12, 2017              [Page 14]


Internet-Draft                  LURK TLS                      March 2017


 struct{
     KeyPairID key_id
     ProtocolVersion tls_version          // see RFC5246 section 6.2.1
     PRFAlgorithm master_prf              // see RFC5246 section 6.1
     EncryptedPreMasterSecret  pre_master // see RFC5246 section 7.4.7.1
     opaque session_hash<2...2^16-2>
 }LURKTLSExtendedMasterRSARequestPayload;

                    rsa_extended_master request payload

   key_id, tls_version, master_prf, pre_master  are defined in
      Section 5.4.1.

   session_hash  The hash of the TLS handshake session as described in
      [RFC7627] section 3.

5.5.2.  Response Payload

   rsa_extended_master response payload has a similar structure as the
   rsa_master response payload Section 5.4.2.

5.5.3.  LURK Client Behavior

   A rsa_extended_master request is sent so the LURK Server can derive
   the master secret used by the TLS session.  Upon receipt of the
   master_secret the Edge Server can generate the session keys and
   finish the TLS key exchange protocol.

5.5.4.  LURK Server Behavior

   The LURK Server proceeds as described in Section 5.4.4 except that
   the generation of the extended master is processed as described in
   [RFC7627].

5.6.  ecdhe

5.6.1.  Request Payload

   struct {
       LURKTLSBase base;
       ServerECDHParams ecdhe_params;  // RFC4492 section 5.4
   } LURKTLSECDHERequestPayload;

                     ecdhe request payload Description

   base  is defined in Section 5.4.1.





Migault                Expires September 12, 2017              [Page 15]


Internet-Draft                  LURK TLS                      March 2017


   ecdhe_params  contains the ECDHE public key and associated domain
      parameters as defined in [RFC4492] section 5.4.

5.6.2.  ecdhe response payload

   struct {
       Signature signed_params;  // RFC4492 section 5.4
   } LURKTLSECDHEResponsePayloads;

   signed_params  signature applied to the hash of the ecdhe_params as
      well as client_random and server_random as described in [RFC4492]
      section 5.4.

5.6.3.  LURK Client Behavior

   The LURK Client sends an ecdhe request so the LURK Server signs the
   ecdhe_params.  The LURK Client expects to receive a signature, and
   upon receiving the signature, the LURK Client SHOULD validate the
   signature.  If the signature does not match an error SHOULD be
   reported.

5.6.4.  LURK Server Behavior

   "ecdhe" extends the Status structure with the following error codes:

enum {
    unsupported_ec_type (133), unsupported_ec_basistype (134),
    unsupported_ec_curve (135), unsupported_ec_point_format (136), (255)
}Status;

   Upon receiving an ecdhe request, the LURK Server proceeds as follows:

   (1)  Check base as described in Section 5.4.4

   (2)  The LURK Server MUST perform some format check of the
        ecdhe_params before signing them.  If the ecdhe_params does not
        follow the expected structure, the LURK Server SHOULD be able to
        respond with an unsupported_ec_type, unsupported_ec_basistype,
        unsupported_ec_curve, unsupported_ec_point_format or
        unvalid_payload_format.

5.7.  LURK/TLS Options

5.7.1.  with_pfs







Migault                Expires September 12, 2017              [Page 16]


Internet-Draft                  LURK TLS                      March 2017


5.7.1.1.  Request Payload

   enum {
       sha256(0), (255);
   }PFSprf;

   struct {
       PFSprf pfs_prf;
   }PFSRequest;

                   with_pfs request payload description

   pfs_prf  the hash function used to preserve Perfect Forward Secrecy
      as described in Section 5.7.1.3 and Section 5.7.1.4.

5.7.1.2.  Response Payload

   This option has no associated response Payload.

5.7.1.3.  LURK Client Behavior

   A message type with "with_pfs" indicated the Perfect Forward Secrecy
   payload MUST be append to the LURK/TLS request payload.  This
   document considers that rsa_master and ecdhe can set this option.

   The LURK Client set the pfs option in order to avoid that an attacker
   monitoring a TLS key exchange between the TLS Client and the Edge
   Server is able to send the appropriated request to the LURK Server.
   More specifically, this option builds the server_random with a hash
   function.  An attacker monitoring the TLS key exchange will not be
   able to compute the input that generates the server_random, and as
   such will not be able to send a corresponding request to the LURK
   Server.

   This option can be used with any request payload that carry a
   server_random field.

   When this option is set, the value in the LURK/TLS Payload
   server_random MUST NOT be used as the value for the
   server.Hello.random.  Instead the value of the server_random field is
   used as a seed to generate the value used for server.Hello.random to
   generate the (extended) master secrets or the signature of the
   ecdhe_params.

   The seed MUST follow the Random structure defined in [RFC5246]
   section 7.4.1.2 which carry the gmt_unix_time in the first four
   bytes.  The ServerHello.random value is generated from the seed as
   follows:



Migault                Expires September 12, 2017              [Page 17]


Internet-Draft                  LURK TLS                      March 2017


   gmt_unix_time = seed[0..3];
   server_random = PRF(seed + "lurk/tls pfs option"
                            + PRF(lurk_tls_header));
   server_random[0..3] = gmt_unix_time;

                  Generating ServerHello.random from seed

5.7.1.4.  LURK Server Behavior

   "with_pfs" extends the Status structure with the following error
   codes:

   enum {
       unsupported_pfs_prf (137), (255)
   } Status;

   When the server receives a message type set with "with_pfs", the LURK
   Server proceeds as follows:

   a)  The LURK Server first performs checks of the main payload
       (rsa_master, ecdhe)

   b)  The LURK Server checks the "pfs" option is present.  If the
       option is not present, the LURK Server MUST return an
       "unsupported_type" error.

   c)  The LURK Server checks it supports the "pfs_prf", otherwise it
       returns an unsupported_pfs_prf error.

   d)  The LURK Server computes the ServerHello.random value as
       described in Section 5.7.1.3.  The value for seed is indicated by
       the server_random field of the request Payload.

   e)  The LURK Server proceeds to the main payload with the
       appropriated ServerHello.random.

5.7.2.  with_poo

5.7.2.1.  Option Request Payload












Migault                Expires September 12, 2017              [Page 18]


Internet-Draft                  LURK TLS                      March 2017


   enum {
       sha256_128(0), sha256_256(1), (255)
   }PFSprf

   struct {
       PooPRF poo_prf;
       ECPoint rG;  //RFC4492 section 5.4
       ECPoint tG;
   } OptionPooRequest;

                    Option Request Payload Description

   poo_prf  pseudo random function used to generate the necessary
      randoms to proof ownership of the private key as described in
      Section 5.7.2.3 and Section 5.7.2.4.  This document defines
      sha256_128 and sha256_256 which apply the sha256 hash function and
      respectively return the 128 or 256 first bits of the resulting
      hash.

   rG, tG  are points generated as described in Section 5.7.2.3 and
      Section 5.7.2.4.

5.7.2.2.  Option Response Payload

   There is no response payload associated to this option.

5.7.2.3.  LURK Client Behavior

   A message type with "with_poo" indicated the LURK Client adds a Proof
   of Ownership of the private part of the public ECDH key provided.
   This option is intended to prevent the LURK Server to sign bytes that
   do not correspond to a ECDHE public key.

   The "with_poo" option is only valid associated to an ecdhe main
   payload.  With the message type ecdhe_with_poo, the poo payload is
   directly appended to the ecdhe payload. with the message type
   "ecdhe_with_pfs_poo" the poo payload is appended to the
   ecdhe_with_pfs payload.

   bG the ECDH public sent in ecdhe_params of the
      LURKTLSECDHERequestPayload. b is a random secret generated by the
      LURK Client and G the base point of the curve.  The base is
      explicitly specified in the ECParameters structure for curves of
      type "explicit_prime" or "explicit_char2".  For curves of type
      "named_curves" G is part of the definition of the curve.

   r  a random number chosen by the LURK Client.




Migault                Expires September 12, 2017              [Page 19]


Internet-Draft                  LURK TLS                      March 2017


   c  a random number that is not controlled by the LURK Client.  The
      LURK Client generates this value using foo_prf.  The input of the
      hash function is the entire LURK/TLS request payload to which the
      poo option has been removed.  The length of the LURK header
      remains unchanged, that is considering the poo option is included,
      and the server_random when present is replaced by the
      ServerHello.random values.  More specifically, when used in
      combination of the pfs option, ServerHello.random is computed
      primarily.

   The LURK Client computes t = cb + r and sends rG, tG, c, bG.  The
   values rG, tG and c are sent in the poo option while bG is sent in
   the ServerECDHParams structure of the LURKTLSECDHERequestPayload
   Section 5.6.

   Note r and c may be treated as "very short-term secrets" but MUST
   remain non-predictable.  It is RECOMMENDED to use a length equivalent
   to the expected level of security, that is 128 bit length (resp. 256
   bit length) for a 128 (resp 256) bit security level.  Given b, we
   RECOMMEND r and c to be at least half the size of b.

5.7.2.4.  LURK Server Behavior

   "with_poo" extends the Status structure with the following error
   codes:

   enum {
       unsupported_poo_prf (138), unvalid_poo (139), (255)
   } Status;

   When the server receives a message type set with "with_pfs", the LURK
   Server proceeds as follows:

   a)  The LURK Server first performs checks of ecdhe request payload

   b)  The LURK Server checks the "poo" option is present.  If the
       option is not present, the LURK Server MUST return an
       "unsupported_type" error.

   c)  The LURK Server checks it supports the poo_prf.  If it does not
       support poo_prf, an "unsupported_poo_prf" is returned.

   d)  The LURK Server removes the poo payload from the received packet
       and computes c with poo_prf and the remaining payload.

   e)  The LURK Server computes c(bG) + rG and compares the output with
       tG.  If c(bG) + rG = tG is not verified, an "unvalid_poo" error
       is returned.



Migault                Expires September 12, 2017              [Page 20]


Internet-Draft                  LURK TLS                      March 2017


   f)  If the pfs option has been set as well, ServerHello.random is
       computed as described in Section 5.7.1.4

   g)  The LURK Server proceed to the ecdhe request as defined in
       Section 5.6

6.  Security Considerations

   This section provides security considerations regarding the LURK
   protocol as well as the trust model.

6.1.  Trust Model

   LURK defines a protocol where the Edge Server terminates the TLS
   session while it does not host the private key. ,As a result, the TLS
   Client does not authenticate the Edge Server itself but instead it
   authenticates the Key Server on behalf of the Edge Server.  The
   standard TLS trust model has these two functions co-hosted into the
   TLS Server.  As a result, in order to rely on the standard TLS trust
   model, the communication between the LURK Server and the LURK Client
   MUST be secured and trusted.  This document RECOMMENDS that LURK
   messages are exchanged over an authenticated and encrypted channel
   protected with IPsec or TLS.  Trust is is enforced by setting LURK
   sessions with trusted Edge Servers as well as by mechanisms such pfs
   or poo, to limit the possibilities of unlegitimate request.

   As described in [I-D.mglt-lurk-tls-use-cases], the main advantage of
   this model is that it prevents the private keys to be hosted on
   multiple domains or Edge Servers, exposed on the Internet and thus
   presenting a consequent risks of leaking the private key.  As a
   result, this architecture provides a higher control on the private
   key.  In addition, it also enable to better monitor the key usage,
   and as such may better detect any distributed attacks

   The disadvantage of this architecture is that the Key Servers
   represent a bottle neck and thus MUST remain available.

6.2.  LURK Protocol

   LURK message can be carried over UDP, and some responses can present
   significant larger response payloads than the request payloads.  As a
   result when non authenticated, LURK could be used for reflection
   attacks.  When used over UDP or any session-less transport layers, we
   RECOMMEND the communication to be authenticated, to prevent an
   attacker to use the LURK Server as a reflector.

   The LURK/TLS capabilities requests can present a high ratio of
   payload size, however, this request is not triggered by the TLS



Migault                Expires September 12, 2017              [Page 21]


Internet-Draft                  LURK TLS                      March 2017


   Client but is only used for management purpose by the Edge Server.
   If a compromised Edge Server uses this request to perform an attack,
   the LURK Server SHOULD be able to delay the treatment, and SHOULD be
   able to respond with a "temporary_failure" error.

   In order to avoid that the LURK Server operation are being used
   outside the extension of LURK, the LURK Server includes specific
   context in the pfs option.

6.3.  RSA

   With a LURK architecture, the RSA private key is expected to be
   hosted on a restricted number of Key Servers and these Key Servers
   are expected to be less exposed to attacks than Edge Servers.  As a
   result, the LURK architecture reduces the leak of RSA private key.
   Such property is especially important as TLS session authenticated
   with RSA are not Perfect Forward Secured (PFS).  In addition, the Key
   Server provides the master secret and the premaster secret remains
   unknown to the Edge Server.  This makes recovery of the private key
   harder as even a compromised Edge Server will not be able to perform
   cryptanalysis attacks based on the encrypted and corresponding clear
   text.

   On the other hand, the LURK architecture may present weakness against
   perfect forward secrecy.  An attacker observing a standard TLS1.2 key
   exchange using an RSA authentication is not able to replay the
   session.  In fact, the TLS server is active in the key exchange.  It
   provides a random number that makes each session unique with a high
   probability.  This is not anymore the case with the LURK architecture
   where the Edge Server provides with "rsa_master" and
   "rsa_extended_master" all the necessary parameters to generate the
   master secret.  As a result, an attacker that observes a TLS key
   exchange and that gain access to the Key Server will be able to
   recompute the master secret.  "rsa_master_with_pfs" address this
   concern and prevent an attacker to replay a request.  An attacker
   observing the TLS key exchange will observe as the hash of a number
   as the secret server while the number is provided to the Key Server
   to generate the secret number.  The attacker is unlikely to replay
   the request unless it can reverse the hash function.

   As PFS issues are inherent to RSA we RECOMMEND the Edge Server to use
   other authentication methods such as ECDHE when possible.  When RSA
   needs to be used, we RECOMMEND to use "rsa_master_pfs" and to have
   "rsa_master" deactivated.  The current document does not provide PFS
   protection for rsa_extended_master".

   Note that having the Key Server generating the server random on its
   own without any input from the Edge Server would also achieve the PFS



Migault                Expires September 12, 2017              [Page 22]


Internet-Draft                  LURK TLS                      March 2017


   in a similar way as standard TLS does.  The pfs options achieves
   similar properties while enabling a LURK Client to replay a request.

   The Standard TLS1.2 is robust against Bleichenbacher attack as it
   provides no means to detect if the error comes from a TLS version
   mismatch or from the premaster format.  This properties remain with
   LURK, and so LURK does not present vulnerabilities toward
   Bleichenbacher attack, and cannot be used as a decryption oracle.

6.4.  ECDHE

   The LURK Server signs ECDH parameters and as such a LURK Server
   deploying ecdhe may appear as as a signing oracle for the specific
   string:

SHA(ClientHello.random + ServerHello.random +
                                              ServerKeyExchange.params);

   Note that an attacker willing to sign a specific string, needs to
   find the randoms values and ECDH parameters such that SHA result in a
   collision.  Even tough this problem does not seem an easy problem,
   the current document address this issue by reducing the LURK Client
   latitude to chose the parameters values.  First, the pfs option
   prevents the LURK Client to specify the server random.  The pfs
   option use a safe hash function.  In addition, the poo option proves
   the ownership of the private counter part of the public parameters.
   Such option limits the values provided as the ECDH parameters to
   effectively working parameters rather than random byte that match the
   ECDH format.

7.  IANA Considerations

8.  Acknowledgments

   We would like to thank for their very useful feed backs: Yaron
   Sheffer, Yoav Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric
   Rescola Mat Naslung, Rich Salz.  Many ideas in this document are from
   [I-D.erb-lurk-rsalg].

   We would also like to thank those that have supported LURK or raised
   interesting discussions.  This includes among others Robert Skog,
   Hans Spaak, Salvatore Loreto, John Mattsson, Alexei Tumarkin, Yaron
   Sheffer, Richard Brunner, Stephane Dault, Dan Kahn Gillmor, Joe
   Hildebrand, Kelsey Cairns.







Migault                Expires September 12, 2017              [Page 23]


Internet-Draft                  LURK TLS                      March 2017


9.  References

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

   [RFC4279]  Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)",
              RFC 4279, DOI 10.17487/RFC4279, December 2005,
              <http://www.rfc-editor.org/info/rfc4279>.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492,
              DOI 10.17487/RFC4492, May 2006,
              <http://www.rfc-editor.org/info/rfc4492>.

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

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <http://www.rfc-editor.org/info/rfc7627>.

9.2.  Normative References

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

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






Migault                Expires September 12, 2017              [Page 24]


Internet-Draft                  LURK TLS                      March 2017


Appendix A.  Example of LURK Exchanges

A.1.  LURK/TLS RSA Master Secret

 TLS Client          Edge Server         Key Server

 ClientHello
    server_version
    client_random
    cipher_suite
        TLS_RSA_*, ...
 -------->

                     ServerHello
                         tls_version
                         server_random
                         Cipher_suite=TLS_RSA
                     Certificate
                         RSA Public Key
                     ServerHelloDone
                     <--------

 ClientKeyExchange
     EncryptedPremasterSecret
 [ChangeCipherSpec]
 Finished
 -------->


                     LURKTLS Request Header
                     LURKTLSMasterRSARequestPayload
                         key_id
                         client_random
                         edge_server_random
                         tls_version
                         master_prf
                         EncryptedPremasterSecret
                     -------->

                                  1. Computing Master Secret
                                  master_secret = master_prf(\
                                  pre_master_secret + "master secret" +\
                                  client_random +\
                                  edge_server_random)[0..47];

                                         LURKTLS Response Header
                                         LURKTLSMasterResponsePayload
                                             master



Migault                Expires September 12, 2017              [Page 25]


Internet-Draft                  LURK TLS                      March 2017


                                         <--------

                     [ChangeCipherSpec]
                         Finished
                     <--------
 Application Data      <------->     Application Data

A.2.  LURK/TLS RSA Extended Master Secret











































Migault                Expires September 12, 2017              [Page 26]


Internet-Draft                  LURK TLS                      March 2017


   TLS Client          Edge Server         Key Server

   ClientHello
      tls_version
      cipher_suite
          TLS_RSA_*, ...
      Extension 0x0017
   -------->

                       ServerHello
                           edge_server_version
                           cipher_suite=TLS_RSA
                           Extension 0x0017
                       Certificate
                           RSA Public Key
                       ServerHelloDone
                       <--------
   ClientKeyExchange
       EncryptedPremasterSecret
   [ChangeCipherSpec]
   Finished
   -------->

                       LURKTLS Request Header
                       LURKTLSExtendedMasterRSAInputPayload
                           key_id
                           tls_version
                           master_prf
                           session_hash
                           EncryptedPreMasterSecret
                       -------->

                                    1. Computing Master Secret
                                    master_secret = master_prf(
                                    pre_master_secret +\
                                    "extended master secret" +\
                                    session_hash)[0..47]

                                           LURKTLS Response Header
                                           LURKTLSMasterPayload
                                               master
                                           <--------

                       [ChangeCipherSpec]
                           Finished
                       <--------
   Application Data      <------->     Application Data




Migault                Expires September 12, 2017              [Page 27]


Internet-Draft                  LURK TLS                      March 2017


A.3.  LURK/TLS ECDHE Signature

  TLS Client          Edge Server         Key Server

  ClientHello
     tls_version
     client_random
     cipher_suite
         TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ...
         Extension Supported EC, Supported Point Format
  -------->

                      LURKTLS Request Header
                      LURKTLSECDHEInputPayload
                          key_id
                          client_random
                          edge_server_random
                          tls_version
                          ecdhe_params
                      -------->
                                   1. Generating the signature
                                   signature = ECDSA(client_random +\
                                   edge_server_random + echde_params)

                                          LURKTLS Response Header
                                          LURKTLSDigitallySignedPayloads
                                              signature
                                          <--------

                      ServerHello
                          edge_server_version
                          edge_server_random
                          Cipher_suite=TLS_ECDHE_ECDSA
                          Extension Supported EC, Supported Point Format
                      Certificate
                          ECDSA Public Key
                      ServerKeyExchange
                          ecdhe_params
                          signature
                      ServerHelloDone
                      <--------


  ClientKeyExchange
  [ChangeCipherSpec]
  Finished
  -------->
                      [ChangeCipherSpec]



Migault                Expires September 12, 2017              [Page 28]


Internet-Draft                  LURK TLS                      March 2017


                      Finished
                      <--------
  Application Data      <------->     Application Data

A.4.  LURK/TLS/sECDHE Unpredictable

TLS Client          Edge Server         Key Server

ClientHello
   server_version
   client_random
   cipher_suite
       TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ...
       Extension Supported EC, Supported Point Format
-------->

                    LURKTLS Header (Query)
                    LURKTLSECDHEInputPayload
                        key_id
                        client_random
                        edge_server_random
                        version
                        signature_scheme
                        ecdhe_params
                        prf
                    -------->
                                 1. Generates a random nonce
                                 2. Compute modified edge_server_random
                                 modified_server_random = \
                                       prf(padding + context +\
                                       zero-byte + edge_server_random +\
                                        once)[32]
                                 3. Generate the signature
                                 signature = ECDSA(client_random +\
                                 modified_server_random + echde_params)

                                        LURKTLS Header (Response)
                                        LURKTLSDigitallySignedPayloads
                                            signature
                                            mofified_edge_server_random
                                        <--------


                    ServerHello
                        edge_server_version
                        modified_edge_server_random
                        cipher_suite=TLS_ECDHE_ECDSA
                        Extension Supported EC, Supported Point Format



Migault                Expires September 12, 2017              [Page 29]


Internet-Draft                  LURK TLS                      March 2017


                    Certificate
                        ECDSA Public Key
                    ServerKeyExchange
                        ecdhe_params
                        signature
                    ServerHelloDone
                    <--------
ClientKeyExchange
[ChangeCipherSpec]
Finished
-------->
                    [ChangeCipherSpec]
                    Finished
                    <--------
Application Data      <------->     Application Data

Author's Address

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

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

























Migault                Expires September 12, 2017              [Page 30]


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