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.


Table of Contents

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.

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:

- 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

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

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.

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

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

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

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.

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

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

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:

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

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

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.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005.
[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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012.
[RFC7627] Bhargavan, K., 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.

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", Internet-Draft draft-mglt-lurk-tls-use-cases-02, June 2016.
[I-D.erb-lurk-rsalg] Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", Internet-Draft draft-erb-lurk-rsalg-01, May 2016.

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

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

A.2. LURK/TLS RSA Extended Master Secret

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
        

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