One document matched: draft-cairns-tls-session-key-interface-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- Edited by John Mattsson for use with xml2rfc -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-cairns-tls-session-key-interface-00">
<front>
<title abbrev="TLS SKI">Session Key Interface (SKI) for TLS and DTLS</title>
<author initials='K' surname="Cairns" fullname='Kelsey Cairns'>
<organization abbrev="Washington State University">Washington State University</organization>
<address>
<postal>
<street>Pullman, WA 99164-2752</street>
<country>USA</country>
</postal>
<email>kcairns@wsu.edu</email>
</address>
</author>
<author initials='J.M' surname="Mattsson" fullname='John Mattsson'>
<organization abbrev="Ericsson">Ericsson AB</organization>
<address>
<postal>
<street>SE-164 80 Stockholm</street>
<country>Sweden</country>
</postal>
<email>john.mattsson@ericsson.com</email>
</address>
</author>
<author initials='R.S' surname="Skog" fullname='Robert Skog'>
<organization abbrev="Ericsson">Ericsson AB</organization>
<address>
<postal>
<street>SE-164 80 Stockholm</street>
<country>Sweden</country>
</postal>
<email>robert.skog@ericsson.com</email>
</address>
</author>
<date />
<area />
<workgroup />
<keyword />
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Transport Layer Security (TLS) is specified in <xref target="RFC5246"/> and the Datagram Transport Layer Security (DTLS), which is based on TLS, is specified in <xref target="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.</t>
<t>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 <xref target="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.</t>
<t>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 <xref target="arch"/>), 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.</t>
<figure anchor="arch" title="TLS Session Key Interface Architecture">
<artwork align="center"><![CDATA[
+--------+ Handshake +-------------+ SKI +------------+
| Client | <---------> | Edge Server | <-------> | Key Server |
+--------+ +-------------+ +------------+
]]></artwork></figure>
<t>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 <xref target="RFC5280"/> or raw public key <xref target="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.</t>
</section>
<section title="Session Key Interface (SKI)">
<t>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.</t>
<t>Any request-response protocol can be used to carry the SKI payloads. Two obvious choices are the Hypertext Transfer Protocol (HTTP) <xref target="RFC7540"/> and the Constrained Application Protocol (CoAP) <xref target="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.</t>
<t>Two formats are defined for the SKI Payload format: the JavaScript Object Notation (JSON) <xref target="RFC7159"/> and the Concise Binary Object Representation (CBOR) <xref target="RFC7049"/>. In JSON, byte strings are Base64 encoded <xref target="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:</t>
<t><list style="hanging">
<t hangText="'protocol'">REQUIRED in SKI requests. Specifies the protocol version negotiated in the handshake between Client and Edge Server. Can take one of the values 'TLS 1.0', 'TLS 1.1', 'TLS 1.2', 'DTLS 1.0', or 'DTLS 1.2'.</t>
<t hangText="'spki'">REQUIRED in SKI requests. Byte string that identifies the Subject Public Key Info (SPKI) of a X.509 certificate <xref target="RFC5280"/> or a raw public key <xref target="RFC7250"/>. Contains a SHA-256 SPKI Fingerprint as defined in <xref target="RFC7469"/></t>
<t hangText="'method'">Included in SKI requests to indicate the key exchange method. Can take one of the values 'ECDHE' or 'RSA'. MAY be omitted if the default value 'ECDHE' is used.</t>
<t hangText="'hash'">Included in SKI requests. MUST be used if a hash algorithm other than the default hash algorithm has been negotiated using the "signature_algorithms" extension. Can take one of the values 'SHA-224', 'SHA-256', 'SHA-384', or 'SHA-512'.</t>
<t hangText="'input'">REQUIRED in SKI requests. Byte string containing the input data to the private key operation. For static RSA it contains the encrypted premaster secret (EncryptedPreMasterSecret). For ECDHE it contains the data to be signed (ClientRandom + ServerRandom + ServerECDHParams).</t>
<t hangText="'output'">Included in successful SKI responses. Byte string containing the output data from the private key operation. For static RSA it contains the premaster secret (PreMasterSecret). For ECDHE is contains the signature (Signature).</t>
<t hangText="'error'">Included in SKI responses to indicate a fatal error. Can take one of the values 'request denied', 'spki not found', 'malformed request', or 'unspecified error'. SHALL not be sent together with 'output'.</t>
</list></t>
<section title="Key Server Processing">
<t>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.</t>
<t>The Key Server MUST check that the input and output data is valid for the given protocol version and key exchange method:
<list style="symbols">
<t>When the key exchange method is 'ECDHE', the corresponding operation is to sign the given input data. Before doing so, the Key Server MUST check that the ECDH public key and associated domain parameters are valid and that the input data has the expected length. If the input data is not valid or has the wrong size, the Key Server MUST reply with a 'malformed request' error. If any other error occurs during the signing process, the server responds with an 'unspecified error' error. If signing is successful, the server responds with the output data set to the result of the signing operation.</t>
<t>When the key exchange method is 'RSA', the corresponding operation is to decrypt the given input data. In this case, the Key Server MUST check that the output data has the expected length and that the protocol version is valid. If the output data is not valid or has the wrong size, the Key Server MUST reply with a 'malformed request' error. If any other error occurs during the decryption process, the server responds with an 'unspecified error' error. If decryption is successful and the output is valid, the server responds with the output data set to the result of the decryption operation.</t>
</list></t>
</section>
</section>
<section title="Interaction with TLS Extensions">
<t>Most TLS extensions interact seamlessly with SKI, but it is worth noting the few that do not:</t>
<t><list>
<t><xref target="RFC6091"/> defines the use of OpenPGP certificates with TLS. As OpenPGP certificates do not have a SPKI field, SKI will not work with this extension unless the public key identification mechanism is updated.</t>
<t><xref target="RFC6962"/> certificate transparency conflict with the proposed version of SKI since it requires signing of timestamps, while SKI only allows signing of valid ECDHE parameters.</t>
</list></t>
<t>A few other TLS extensions may have problems if a TLS client connects to different Edge Servers:</t>
<t><list>
<t><xref target="RFC5077"/> defines session resumption with session tickets. As this extension uses a secret key stored on the server issuing the ticket, it only works if the resumption Edge Server has the same secret key.</t>
<t><xref target="RFC5746"/> defines the renegotiation_info extension for secure renegotiation. As this extension is facilitated by binding the renegotiation to the previous connection, it only works if the renegotiation is done to the same Edge Server.</t>
</list></t>
</section>
<section title="Examples">
<t>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 <xref target="RFC7049"/>.</t>
<section title="ECDHE_ECDSA Key Exchange">
<t>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 <xref target="ecdhe"/>.</t>
<figure anchor="ecdhe" title="Message Flow for ECDHE Key Exchange">
<artwork align="center"><![CDATA[
+--------+ +-------------+ +------------+
| Client | | Edge Server | | Key Server |
+--------+ +-------------+ +------------+
ClientHello (Client Random)
--------------------------------------->
ServerHello (Server Random)
<---------------------------------------
Certificate (Server Certificate)
<---------------------------------------
SKI Request
-------------------->
SKI Response
ServerKeyExchange <--------------------
(ECDHParams, Signature)
<---------------------------------------
ClientKeyExchange (ClientDHPublic)
--------------------------------------->
Finished
<-------------------------------------->
]]></artwork></figure>
<section title="SKI Request and Response with JSON/HTTP">
<figure>
<preamble>SKI Request:</preamble>
<artwork><![CDATA[
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"
}
]]></artwork></figure>
<figure>
<preamble>SKI Response:</preamble>
<artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 62
{
“output": "eysh5GCSbIjjHzDt7Co5PUuVnDePbUYI839yv30bJWquwJ3vyADor"
}
]]></artwork></figure>
<figure>
<preamble>SKI Request:</preamble>
<artwork><![CDATA[
PUT /ski HTTP/1.1
Host: keyserver.example.com
Content-Type: application/json
Content-Length: 128
{
“protocol”: “TLS 1.1”,
"spki": "p8FU0McKWBBLEEFfQbnJPjW3Q6EcZ5t11cKKcuwj",
“input”: "yWCMO9P0yINtHUT17ZO1X1mUgwh1CrTGan9QaAGph9AnCO4HA44nez”
}
]]></artwork></figure>
<figure>
<preamble>SKI Response:</preamble>
<artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 62
{
“output": "m7nJUltTVMiaQJyDcKPaq0ZOtfuRVnUt1cUx5KoP3w75MqpSelutO"
}
]]></artwork></figure>
</section>
<section title="SKI Request and Response with CBOR/CoAP">
<figure>
<preamble>SKI Request:</preamble>
<artwork><![CDATA[
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'
}
]]></artwork></figure>
<figure>
<preamble>SKI Response:</preamble>
<artwork><![CDATA[
Header: 2.04 Changed (T=ACK, Code=2.04, MID=0x1337)
Content-Format: 60 (application/cbor)
Payload: { “output”: h'2c8a0001b8295ab44d1930b8efdd9fb40' }
]]></artwork></figure>
</section>
</section>
<section title="Static RSA Key Exchange">
<t>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 <xref target="rsa"/>.</t>
<figure anchor="rsa" title="Message Flow for Static RSA Key Exchange">
<artwork align="center"><![CDATA[
+--------+ +-------------+ +------------+
| Client | | Edge Server | | Key Server |
+--------+ +-------------+ +------------+
ClientHello (Client Random)
--------------------------------------->
ServerHello (Server Random)
<---------------------------------------
Certificate (Server Certificate)
<---------------------------------------
ClientKeyExchange
(Encrypted Premaster Secret)
--------------------------------------->
SKI Request
-------------------->
SKI Response
<--------------------
Finished
<-------------------------------------->
]]></artwork></figure>
<section title="SKI Request and Response with JSON/HTTP">
<figure>
<preamble>SKI Request:</preamble>
<artwork><![CDATA[
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"
}
]]></artwork></figure>
<figure>
<preamble>SKI Response:</preamble>
<artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 62
{
“output": "CtehRGUae6NQ0daIuClSTg3nW62zqPvYTjnvIV0mt5kM49tIq9uDG"
}
]]></artwork></figure>
</section>
<section title="SKI Request and Response with CBOR/CoAP">
<figure>
<preamble>SKI Request:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
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'
}
]]></artwork></figure>
<figure>
<preamble>SKI Response:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
Header: 2.04 Changed (T=ACK, Code=2.04, MID=0xabba)
Content-Format: 60 (application/cbor)
Payload: { “output” : h'827628ca533a1d1191acb0e106fb' }
]]></artwork></figure>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>This document defines the following. TODO...</t>
</section>
<section title="Security Considerations">
<t>The security considerations in <xref target="RFC5246"/>, <xref target="RFC4492"/>, and <xref target="RFC7525"/> apply to this document as well.
</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Magnus Thulstrup and Hans Spaak for their valuable comments and feedback.</t>
</section>
</middle>
<back>
<references>
<?rfc include="reference.RFC.4492.xml"?>
<?rfc include="reference.RFC.4648.xml"?>
<?rfc include="reference.RFC.5054.xml"?>
<?rfc include="reference.RFC.5077.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.5280.xml"?>
<?rfc include="reference.RFC.5746.xml"?>
<?rfc include="reference.RFC.6091.xml"?>
<?rfc include="reference.RFC.6347.xml"?>
<?rfc include="reference.RFC.6962.xml"?>
<?rfc include="reference.RFC.7049.xml"?>
<?rfc include="reference.RFC.7159.xml"?>
<?rfc include="reference.RFC.7250.xml"?>
<?rfc include="reference.RFC.7252.xml"?>
<?rfc include="reference.RFC.7469.xml"?>
<?rfc include="reference.RFC.7525.xml"?>
<?rfc include="reference.RFC.7540.xml"?>
<reference anchor="HEART" target="http://heartbleed.com/">
<front>
<title>The Heartbleed Bug</title>
<author>
<organization>Codenomicon</organization>
</author>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
<!--
-->
| PAFTECH AB 2003-2026 | 2026-04-24 04:20:25 |