Internet DRAFT - draft-mglt-lurk-tls
draft-mglt-lurk-tls
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]
