| Network Working Group | K. Cairns |
| Internet-Draft | Washington State University |
| Intended status: Standards Track | J. Mattsson |
| Expires: January 7, 2016 | R. Skog |
| Ericsson | |
| July 6, 2015 |
Session Key Interface (SKI) for TLS and DTLS
draft-cairns-tls-session-key-interface-00
This document describes a session key interface that can be used for TLS and DTLS. The Heartbleed attack has clearly illustrated the security problems with storing private keys in the memory of the TLS server. Hardware Security Modules (HSM) offer better protection but are inflexible, especially as more (D)TLS servers are running on virtualized servers in data centers.
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 January 7, 2016.
Copyright (c) 2015 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.
Transport Layer Security (TLS) is specified in [RFC5246] and the Datagram Transport Layer Security (DTLS), which is based on TLS, is specified in [RFC6347]. During the TLS handshake, the TLS client and the TLS server exchange a symmetric session key called the premaster secret. From the premaster secret, the client random, and the server random, the endpoints derive a master secret, which in turn is used to derive the traffic encryption keys and IVs. The TLS server is authenticated during this process by presenting a certificate and then proving possession of the private key corresponding to the public key in the certificate.
An important principle in designing security architectures is to limit access to keying material, especially long-lived secrets such as private keys. The Heartbleed attack [HEART] has illustrated the dangers of storing private keys in the memory of the TLS server. One common practice used to protect keys is to delegate the private key operations to a separate entity such as a Hardware Security Module (HSM), something that is supported in many TLS libraries. HSMs provide good security but are inflexible and may be difficult to deploy when the TLS server runs on a virtualized machine in the cloud, especially if the application server that uses TLS moves between different data centers. Furthermore, while HSMs protect against extraction of the private key, they do not protect against misuse in case an adversary gains possession of the HSM itself. One solution to these problems is to use a network-attached HSM, but these use proprietary network protocols tied to the specific HSM vendor. There are several other proprietary session key interfaces deployed but no standardized solution.
The TLS Session Key Interface (SKI) defined in this document makes it possible to store private keys in a highly trusted key server, physically separated from client facing servers. With TLS SKI (see Figure 1), the TLS server is split into two distinct entities called Edge Server and Key Server that communicate over an encrypted and mutually authenticated channel using e.g. TLS. This increases the security by shrinking the attack surface and reducing the damage if the Edge Server is compromised. It also enables secure handling of TLS connections in the cloud. The Edge Server can be placed close to the clients, reducing latency, while the Key Server is placed in a safe location. One important use case is an origin that operates a number of distributed HTTPS servers.
+--------+ Handshake +-------------+ SKI +------------+ | Client | <---------> | Edge Server | <-------> | Key Server | +--------+ +-------------+ +------------+
Figure 1: TLS Session Key Interface Architecture
The public certificates (not private keys) are pre-provisioned in the Edge Server. The Key Server handles all the private key operations. It retains control of the private keys and can at any time reject a request from the Edge Server, e.g. if there is reason to suspect that the Edge Server has been compromised. The interface uses modern web technologies like JSON, CBOR, HTTP, CoAP, TLS, and REST. To minimize latency, the Edge Server SHOULD keep a persistent connection to the Key Server. By making TLS SKI specific to TLS, the number of valid inputs that the Key Server accepts is limited and the risk of having a general signing interface reduced. SKI supports the most commonly used key exchange methods ECDHE_ECDSA, ECDHE_RSA, and RSA, together with X.509 [RFC5280] or raw public key [RFC7250] authentication. It soes not work with PSK or SRP authentication. Even though the industry is quickly moving towards the more secure ECDHE key exchange methods, which provides perfect forward secrecy, static RSA still needs be supported in many deployments.
The Session Key Interface is based on a request-response pattern where the Edge Server sends a SKI Request to the Key Server requesting a specific private key operation that the Edge Server needs to complete a TLS handshake. The Edge Server's request includes data to be processed, the identifier of the private key to be used, and any options necessary for the Key Server to correctly perform the requested operation. The Key Server answers with a SKI Response containing either the requested output data or an error.
Any request-response protocol can be used to carry the SKI payloads. Two obvious choices are the Hypertext Transfer Protocol (HTTP) [RFC7540] and the Constrained Application Protocol (CoAP) [RFC7252]. Which protocol to use is application specific. SKI requests are by default sent to the Request-URI '/ski'. The interface between the Edge Server and the Key Server MUST be protected by a security protocol providing integrity protection, confidentiality, and mutual authentication. If TLS is used, the implementation MUST fulfill at least the security requirements in [RFC7540] Section 9.2.
Two formats are defined for the SKI Payload format: the JavaScript Object Notation (JSON) [RFC7159] and the Concise Binary Object Representation (CBOR) [RFC7049]. In JSON, byte strings are Base64 encoded [RFC4648]. Which format to use is application specific. The payload consists of a single JSON or CBOR object consisting of one or more attribute-value pairs. The following attributes are defined:
The Key Server determines how to handle a SKI request based on the values provided for the 'protocol', 'spki', 'hash', and 'method' attributes. If the Key Server cannot parse the SKI request it MUST respond with a 'malformed request' error. If a private key matching the 'spki' value is not found, the Key Server MUST respond with a 'spki not found' error. If the Edge Server is not authorized to receive a response to the specific request, the Key Server MUST respond with a 'request denied' error.
The Key Server MUST check that the input and output data is valid for the given protocol version and key exchange method:
Most TLS extensions interact seamlessly with SKI, but it is worth noting the few that do not:
A few other TLS extensions may have problems if a TLS client connects to different Edge Servers:
Note: Lengths of hexadecimal and base64 encoded strings in examples are not intended to be realistic. For readability, COSE objects are represented using CBOR's diagnostic notation [RFC7049].
If an ECDHE key exchange method is used, the Edge Server MUST receive the SKI Response before it can send the ServerKeyExchange message. An example message flow is shown in Figure 2.
+--------+ +-------------+ +------------+
| Client | | Edge Server | | Key Server |
+--------+ +-------------+ +------------+
ClientHello (Client Random)
--------------------------------------->
ServerHello (Server Random)
<---------------------------------------
Certificate (Server Certificate)
<---------------------------------------
SKI Request
-------------------->
SKI Response
ServerKeyExchange <--------------------
(ECDHParams, Signature)
<---------------------------------------
ClientKeyExchange (ClientDHPublic)
--------------------------------------->
Finished
<-------------------------------------->
Figure 2: Message Flow for ECDHE Key Exchange
SKI Request:
PUT /ski HTTP/1.1
Host: keyserver.example.com
Content-Type: application/json
Content-Length: 166
{
“protocol”: “TLS 1.2”,
"method": "ECDHE",
“hash”: “SHA-256”,
"spki": "mPgHXSvrW6ygN4uhPnl0W2uGMSbCDjFV1bfkaVT5",
“input”: "Bn1eaonvIyCDFd9Ek8UyghL9SA1FXcDplnk8zNlLXBL4H0FAEFyvFO"
}
SKI Response:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 62
{
“output": "eysh5GCSbIjjHzDt7Co5PUuVnDePbUYI839yv30bJWquwJ3vyADor"
}
SKI Request:
PUT /ski HTTP/1.1
Host: keyserver.example.com
Content-Type: application/json
Content-Length: 128
{
“protocol”: “TLS 1.1”,
"spki": "p8FU0McKWBBLEEFfQbnJPjW3Q6EcZ5t11cKKcuwj",
“input”: "yWCMO9P0yINtHUT17ZO1X1mUgwh1CrTGan9QaAGph9AnCO4HA44nez”
}
SKI Response:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 62
{
“output": "m7nJUltTVMiaQJyDcKPaq0ZOtfuRVnUt1cUx5KoP3w75MqpSelutO"
}
SKI Request:
Header: PUT (T=CON, Code=0.03, MID=0x1337)
Uri-Path: "ski"
Content-Format: 60 (application/cbor)
Payload: {
“protocol”: “TLS 1.0”,
“spki”: h'a1fa7ec57a6a5485756c45ab58b2c992',
“input”: h'd2e61706059a16714e4716853e2917e34'
}
SKI Response:
Header: 2.04 Changed (T=ACK, Code=2.04, MID=0x1337)
Content-Format: 60 (application/cbor)
Payload: { “output”: h'2c8a0001b8295ab44d1930b8efdd9fb40' }
If the static RSA key exchange method is used, the Edge Server MUST receive the SKI Response before it can send the Finished message. An example message flow is shown in Figure 3.
+--------+ +-------------+ +------------+
| Client | | Edge Server | | Key Server |
+--------+ +-------------+ +------------+
ClientHello (Client Random)
--------------------------------------->
ServerHello (Server Random)
<---------------------------------------
Certificate (Server Certificate)
<---------------------------------------
ClientKeyExchange
(Encrypted Premaster Secret)
--------------------------------------->
SKI Request
-------------------->
SKI Response
<--------------------
Finished
<-------------------------------------->
Figure 3: Message Flow for Static RSA Key Exchange
SKI Request:
PUT /ski HTTP/1.1
Host: keyserver.example.com
Content-Type: application/json
Content-Length: 145
{
“protocol”: “TLS 1.2”,
“method”: “RSA",
"spki": "QItwmcEKcuMhCWIdESDPBbZtNgfwS7w84wizTk47",
“input”: "dEHffkdIoi2YhQmsqcum3kDk2cToQqO2JLzJVi4q8pJSvfSUyyhRv7"
}
SKI Response:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 62
{
“output": "CtehRGUae6NQ0daIuClSTg3nW62zqPvYTjnvIV0mt5kM49tIq9uDG"
}
SKI Request:
Header: PUT (T=CON, Code=0.03, MID=0xabba)
Uri-Path: "ski"
Content-Format: 60 (application/cbor)
Payload: {
“protocol”: “TLS 1.2”,
“method”: “RSA”,
“spki”: h'8378d0547da09484b8ae509565b0a595',
“input”: h'9da2d7a363ead429141f4dcad20befb6043'
}
SKI Response:
Header: 2.04 Changed (T=ACK, Code=2.04, MID=0xabba)
Content-Format: 60 (application/cbor)
Payload: { “output” : h'827628ca533a1d1191acb0e106fb' }
This document defines the following. TODO...
The security considerations in [RFC5246], [RFC4492], and [RFC7525] apply to this document as well.
The TLS Session Key Interface increases the security by making it possible to store private keys in a highly trusted location, physically separated from client facing servers. The main feature that separates TLS SKI from traditional TLS is the secure connection between the Edge Server and the Key Server. This connection is relied on to ensure that the servers are mutually authenticated and that the connection between them is private. A compromised Edge Server can still access client data as well as submit requests to the Key Server. However, the risks are reduces since no private keys can be compromised and the Key Server can at any time prevent the Edge Server from starting new TLS connections.
A compromised Edge Server could potentially launch timing side-channel attacks or buffer overflow attacks. And as the Key Server has limited knowledge of the input data it signs or decrypts, a compromised edge server could try to get the Key Server to process maliciously crafted input data resulting in a signed message or the decryption of the PreMasterSecret from another connection. However, these attacks are not introduced by SKI since they could be performed on a compromised traditional TLS server and, with the exception of the signing attack, can even be launched by a TLS client against an uncompromised TLS server.
The authors would like to thank Magnus Thulstrup and Hans Spaak for their valuable comments and feedback.