| Network Working Group | S. Erb |
| Internet-Draft | R. Salz |
| Intended status: Standards Track | Akamai Technologies |
| Expires: November 29, 2016 | May 28, 2016 |
A PFS-preserving protocol for LURK
draft-erb-lurk-rsalg-01
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.
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 November 29, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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 a Server 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.
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.
A Server can contact a KeyOwner at any time to request the state of the KeyOwner. When a Server is notified of a state change in a KeyOwner response message, it MUST then request the state of the KeyOwner.
A KeyOwner will sign requests on behalf of the Server for the signature required for the Server Key Exchange Message. This message includes the client and server random values and key parameters.
The basic premise of RSALG is that in the TLS_RSA_* handshakes:
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.
If an attacker can gain access to a Server, 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.
The PRF inputs to the HMAC-SHA-384 described above are the encrypted PMS, client version and server version.
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
A Server that supports TLS session tickets for multiple KeyOwners SHOULD ensure that the ticket encryption keys are secure in the face of various compromises. Using a hash of the private key as one of the inputs to the session ticket KDF ensures that the traffic for KeyOwner is protected against compromise of, or malicious behavior by, other input parts to the session ticket KDF. It also limits the extent to which compromise of a particular session ticket key effects the Server acting on behalf of multiple KeyOwners.
After receiving a request, the KeyOwner computes an HMAC over a server-supplied salt and a fixed string using the private key for the certificate specified in the request as the hash key.
The fixed string is set by the KeyOwner, for example “LURK SESSION TICKET”.
session_ticket_secret = HMAC-SHA-384(private_key,
server_salt + fixed_string)
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 {
setup_request(0), setup_response(1),
request(2), session_ticket_request(3), response(4), (255)
} Type
struct {
Version version;
Type type;
uint16 length;
} lurk_msg_header;
A setup request message, requesting the state of the KeyOwner looks like this:
struct {
lurk_msg_header header;
uint64 id;
} setup_request;
A setup response message, returning the state of the KeyOwner looks like this:
struct {
uint8 purpose<32>;
opaque ASN.1Cert<1..2^24-1>;
} certificate;
struct {
lurk_msg_header header;
uint64 id;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
certificate certificate_list<0..2^24-1>;
uint8 state<32>;
} setup_response;
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;
TODO: this likely should follow the same format as the first byte of sighashalgo above, also need md5/sha1 combo value here.
A session ticket key input request message looks like this:
struct {
lurk_msg_header header;
uint64 id;
uint8 cert<32>;
uint8 server_salt<48>;
} lurk_session_ticket_request;
A response message, used by both request types, looks like this:
enum {
success(0), invalidParameters(1), certUnavailable(2),
permissionDenied(3), insufficentResources(4), (255)
} ResponseStatus
struct {
lurk_msg_header header;
ResponseStatus status;
uint64 id;
uint8 state<32>;
opaque data<0..2^16-1>;
} lurk_response;
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?
Should we use variant for the different request/response payloads?
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.”
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |