A PFS-preserving protocol for LURK
draft-erb-lurk-rsalg-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Samuel Erb , Rich Salz | ||
| Last updated | 2016-03-18 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-erb-lurk-rsalg-00
Network Working Group S. Erb
Internet-Draft R. Salz
Intended status: Standards Track Akamai Technologies
Expires: September 19, 2016 March 18, 2016
A PFS-preserving protocol for LURK
draft-erb-lurk-rsalg-00
Abstract
This document defines a protocol between a content provider and an
external key owner that enables the provider to act as a TLS
termination end-point for the key owner, without having the key
actually being provisioned at the provider.
The protocol between the two preserves forward secrecy, and is also
designed to prevent the use of the key owner as a general-purpose
signing oracle which would make it complicit in attacks against uses
of the very keys it is trying to protect.
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 19, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Erb & Salz Expires September 19, 2016 [Page 1]
Internet-Draft draft-erb-lurk-rsalg March 2016
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Server Key Exchange . . . . . . . . . . . . . . . . . . . 3
3.2. RSALG . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. Implementation Note - Modified Bleichenbacher Attack 4
3.2.2. Implementation Note - Hash Calculation . . . . . . . 4
4. LURK Message Formats . . . . . . . . . . . . . . . . . . . . 5
4.1. Request Message . . . . . . . . . . . . . . . . . . . . . 5
4.2. Response Message . . . . . . . . . . . . . . . . . . . . 6
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Terminology
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 RFC 2119 [RFC2119].
Three entities are involved in this protocol, although only two
actually
participate in the protocol exchanges:
Client <-----> Server <----> KeyOwner
The "KeyOwner" is an entity holding a Certificate and associated
private Key, typically bound to an identity such as a DNS name.
The "server" acts on behalf of the KeyOwner, such as terminating TLS
connections. From external appearances, such as TLS peer name
verification, the server is indistinguishable from the KeyOwner.
The "client" is the end-entity that initiates a connection to the
server.
Erb & Salz Expires September 19, 2016 [Page 2]
Internet-Draft draft-erb-lurk-rsalg March 2016
2. Goals and Non-Goals
It is not a goal to protect against an active attacker who can
decrypt or actively MiTM any of the traffic.
It is not a goal to protect Client-Server traffic in the event of a
full compromise of a KeyOwner private key.
This protocol can support Client-Server communications from SSLv3 up
through TLS 1.2. (TLS 1.3 will have to be evaluated at a later
date.)
Past Client-Server communications must remain private in the event
that access to the KeyOwner is compromised (Perfect Forward Secrecy).
For Server Key Exchange signing requests, this is not an issue. For
RSA decryption requests used by the TLS_RSA_* cipher suites, the
"RSALG" message exchanges described below provide PFS protection.
The protocol should not become a generic signing oracle, even if it
is suboptimal with regard to network bandwidth utilization. This is
done by not simply signing values, but by computing the full
signature hash at the KeyOwner.
3. Protocol Overview
Communication between the Server and KeyOwner MUST be over a
mutually-authenticated TLS connection that uses PFS key exchange.
TLS 1.2 or later SHOULD be used.
3.1. Server Key Exchange
To be provided.
3.2. RSALG
The basic premise of RSALG is that in the TLS_RSA_* handshakes:
o The KeyOwner will not decrypt the PMS and provide it back to the
Server. Instead, the KeyOwner will full compute the Master Secret
(via the PRF function) and provide that.
o The Server will choose a random ephemeral value, N, and provide a
cryptographically-hashed value of (such as SHA256(N)) as its
Server Random value. The Server sends N to KeyOwner which then
computes the same hashed value and uses that hash as its input to
the PRF.
Erb & Salz Expires September 19, 2016 [Page 3]
Internet-Draft draft-erb-lurk-rsalg March 2016
An attacker who later gains access to KeyOwner would be unable to
derive the same Master Secret. This attacker would be able to see
the Client Random, Server Random and encrypted PMS, but would be
unable to replay this to KeyOwner unless they could reverse the
cryptographic hash function used to compute the server random.
3.2.1. Implementation Note - Modified Bleichenbacher Attack
If an attacker can gain access to the KeyOwner, they could mount a
Bleichenbacher attack against it (REF NEEDED). The standard SSL/TLS
defense against the Bleichenbacher attack (generating a string of
random bytes) is not effective here, since an attacker could generate
two requests with identical inputs and learn information about the
validity of the padding by seeing whether it gets a consistent output
in both cases. This is possible because the attacker also controls
(the input to) the server random.
To avoid this variation on the Bleichenbacher attack, KeyOwner should
compute the HMAC-SHA-384 over the PRF inputs as its "invalid"
response, using a private key as the hash key, to ensure that the
output is a deterministic function of the input and cannot be
calculated by the attacker. This private key must be globally unique
per keypair, therefore the RSA private key being used to decrypt the
PMS is an obvious choice.
3.2.2. Implementation Note - Hash Calculation
In TLS 1.2 and earlier, the first four bytes of a server random value
are actually a timestamp. An implementation must use those four
bytes as an input to the hash function as described above, then
overwrite them as input to the PRF calculated by the KeyOwner and the
Server Random value provided to the Client.
Example:
server_random = N
server_random[0..3] = get_time()
Server communicates server_random to KeyOwner
Both Server and KeyOwner compute the following:
saved_time = server_random[0..3]
server_random = sha256(server_random)
server_random[0..3] = saved_time
Erb & Salz Expires September 19, 2016 [Page 4]
Internet-Draft draft-erb-lurk-rsalg March 2016
4. LURK Message Formats
The formats below are described using the TLS Presentation Language.
The following message header appears at the start of every message:
enum {
one(1), (255)
} Version
enum {
request(0), response(1), (255)
} Type
struct {
Version version;
Type type;
uint16 length;
} lurk_msg_header;
version The version of this protocol.
type The message type, either request or response. Details defined
below.
length Length of the entire message, including header, in bytes.
4.1. Request Message
A request message looks like this:
enum {
rsalg(0), server_kx(1), (255)
} ReqType
struct {
lurk_msg_header header;
uint64 id;
ReqType op_type;
uint8 cert<32>;
uint16 client_version;
uint16 server_version;
uint8 client_random<32>;
uint8 server_random<32>;
SignatureAndHashAlgorithm sig_hash_alg;
PRFHashAlgorithm prf_hash_alg;
opaque data<0..2^16-1>;
} lurk_request;
id A unique identifier to allow pipelining and match requests and
responses.
Erb & Salz Expires September 19, 2016 [Page 5]
Internet-Draft draft-erb-lurk-rsalg March 2016
cert The identifier for the keypair to be used in this request.
This SHOULD be the SHA256 value of the public key.
client_version The TLS Version Number provided by the Client in the
clientHello message. Note that for RSALG requests, the value must
be verified (see RFC5264, section 7.4.7.1)
server_version The TLS Version Number provided by the Server in the
serverHello message. Note that for RSALG requests, the value must
be verified (see RFC5264, section 7.4.7.1)
client_random The TLS Client Random provided by the clientHello
message.
server_random The TLS Server Random provided by the serverHello
message. Note that for RSALG requests, this is actually the
digested value of N.
sig_hash_alg For server_kx requests, this is the signature hash
value that the Server will use (see RFC5246, section 7.4.1.4.1).
For rsalg requests, this field is ignored and SHOULD be NULL.
prf_hash_alg For rsalg requests, this identifies the PRF function to
use. For server_kx requests, this field is ignored and SHOULD be
NULL.
TODO: this likely should follow the same format as the first byte of
sighashalgo above, also need md5/sha1 combo value here.
data For rsalg requests, this contains the encrypted PRF. For
server_kx signing reqeusts, this contains the key parameters to
sign.
4.2. Response Message
A response message looks like this:
enum {
success(0), invalidParameters(1), certUnavailable(2),
permissionDenied(3), insufficentResources(4), (255)
} ResponseStatus
struct {
lurk_msg_header header;
RseponseStatus status;
uint64 id;
opaque data<0..2^16-1>;
} lurk_response;
Erb & Salz Expires September 19, 2016 [Page 6]
Internet-Draft draft-erb-lurk-rsalg March 2016
id The request id for which this is the response.
data For any status other than success, the data is ignored and MUST
be NULL. For rsalg requests, the data contains the master secret.
For server_kx requests, the data contains the signed hash.
5. Open Issues
The KeyOwner could choose the TLS server random. This makes RSALG
even less likely to be useful as an oracle, but has turned out to be
difficult to integrate into existing TLS/SSL libraries.
Should the lurk_request and lurk_response messages be padded out to
eight-byte alignment?
6. Acknowledgements
We acknowledge the cooperation of Charlie Gero and Phil Lisiecki of
Akamai Technologies, and their disclosure of US Patent Application
20150106624, "Providing forward secrecy in a terminating TLS
connection proxy."
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Authors' Addresses
Samuel Erb
Akamai Technologies
Email: serb@akamai.com
Rich Salz
Akamai Technologies
Email: rsalz@akamai.com
Erb & Salz Expires September 19, 2016 [Page 7]