A PFS-preserving protocol for LURKAkamai Technologiesserb@akamai.comAkamai Technologiesrsalz@akamai.comThis 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.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 .Three entities are involved in this protocol, although only two actuallyparticipate in the protocol exchanges: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: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.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.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 communicates server_random to KeyOwnerBoth Server and KeyOwner compute the following: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”.The formats below are described using the TLS Presentation Language.The following message header appears at the start of every message:
The version of this protocol.
The message type. Details defined below.
Length of the entire message, including header, in bytes.A setup request message, requesting the state of the KeyOwner looks like this:
A unique identifier to allow pipelining and match requests and responses.A setup response message, returning the state of the KeyOwner looks like this:
A unique identifier to allow pipelining and match requests and responses.
A list of supported signature hash algorithms that the KeyOwner supports
(see RFC5246, section 7.4.1.4.1).
TODO: TLSv1.3 considerations
A list of certificate that are supported by the KeyOwner. The purpose field
is a value that MUST be pre-configured by the Server and KeyOwner so a Server
can have context of where to use the corresponding ASN.1Cert. An example pre-configuration
of the purpose field is:
purpose = sha256(hostname)
A hash of the current state of the server. A KeyOwner MUST provide this value
in every response message and MUST update the value to let a Server know to
send a setup_request message. This value MUST be consistant across multiple KeyOwners
with identical configurations. An example of this value:
state = sha256(supported_signature_algorithms + certificate_list)A request message looks like this:
A unique identifier to allow pipelining and match requests and responses.
The identifier for the keypair to be used in this request.
This SHOULD be the SHA256 value of the public key.
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)
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)
The TLS Client Random provided by the clientHello message.
The TLS Server Random provided by the serverHello message.
Note that for RSALG requests, this is actually the digested value of N.
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. TODO - TLSv1.3 considerations.
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.
For rsalg requests, this contains the encrypted PRF. For server_kx
signing requests, this contains the key parameters to sign.A session ticket key input request message looks like this:
A unique identifier to allow pipelining and match requests and responses.
The identifier for the keypair to be used in this request.
This SHOULD be the SHA256 value of the public key.
A server supplied random salt.A response message, used by both request types, looks like this:
The request id for which this is the response.
A 32 byte tag identifying the current state of the server. This is expected
to be the same value found in the setup_response message. If this value is different
the Server MUST send a setup_request message.
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.
For session ticket key requests, the data contains the computed HMAC.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.”Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]