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 Abstract 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. 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 January 7, 2016. Copyright Notice 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 Cairns, et al. Expires January 7, 2016 [Page 1] Internet-Draft TLS SKI July 2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Session Key Interface (SKI) . . . . . . . . . . . . . . . . . 3 2.1. Key Server Processing . . . . . . . . . . . . . . . . . . 5 3. Interaction with TLS Extensions . . . . . . . . . . . . . . . 6 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. ECDHE_ECDSA Key Exchange . . . . . . . . . . . . . . . . 6 4.1.1. SKI Request and Response with JSON/HTTP . . . . . . . 7 4.1.2. SKI Request and Response with CBOR/CoAP . . . . . . . 8 4.2. Static RSA Key Exchange . . . . . . . . . . . . . . . . . 9 4.2.1. SKI Request and Response with JSON/HTTP . . . . . . . 9 4.2.2. SKI Request and Response with CBOR/CoAP . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction 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 Cairns, et al. Expires January 7, 2016 [Page 2] Internet-Draft TLS SKI July 2015 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. 2. Session Key Interface (SKI) 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 Cairns, et al. Expires January 7, 2016 [Page 3] Internet-Draft TLS SKI July 2015 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: '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'. 'spki' REQUIRED in SKI requests. Byte string that identifies the Subject Public Key Info (SPKI) of a X.509 certificate [RFC5280] or a raw public key [RFC7250]. Contains a SHA-256 SPKI Fingerprint as defined in [RFC7469] '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. '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'. '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). Cairns, et al. Expires January 7, 2016 [Page 4] Internet-Draft TLS SKI July 2015 '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). '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'. 2.1. Key Server Processing 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: o 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. o 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. Cairns, et al. Expires January 7, 2016 [Page 5] Internet-Draft TLS SKI July 2015 3. Interaction with TLS Extensions Most TLS extensions interact seamlessly with SKI, but it is worth noting the few that do not: [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. [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. A few other TLS extensions may have problems if a TLS client connects to different Edge Servers: [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. [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. 4. Examples 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]. 4.1. ECDHE_ECDSA Key Exchange 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. Cairns, et al. Expires January 7, 2016 [Page 6] Internet-Draft TLS SKI July 2015 +--------+ +-------------+ +------------+ | 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 4.1.1. SKI Request and Response with JSON/HTTP 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" } Cairns, et al. Expires January 7, 2016 [Page 7] Internet-Draft TLS SKI July 2015 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" } 4.1.2. SKI Request and Response with CBOR/CoAP 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' } Cairns, et al. Expires January 7, 2016 [Page 8] Internet-Draft TLS SKI July 2015 SKI Response: Header: 2.04 Changed (T=ACK, Code=2.04, MID=0x1337) Content-Format: 60 (application/cbor) Payload: { "output": h'2c8a0001b8295ab44d1930b8efdd9fb40' } 4.2. Static RSA Key Exchange 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 4.2.1. SKI Request and Response with JSON/HTTP Cairns, et al. Expires January 7, 2016 [Page 9] Internet-Draft TLS SKI July 2015 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" } 4.2.2. SKI Request and Response with CBOR/CoAP 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' } Cairns, et al. Expires January 7, 2016 [Page 10] Internet-Draft TLS SKI July 2015 5. IANA Considerations This document defines the following. TODO... 6. Security Considerations 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. 7. Acknowledgements The authors would like to thank Magnus Thulstrup and Hans Spaak for their valuable comments and feedback. 8. References [HEART] Codenomicon, "The Heartbleed Bug", . [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. Cairns, et al. Expires January 7, 2016 [Page 11] Internet-Draft TLS SKI July 2015 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, February 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, October 2013. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, June 2014. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, April 2015. Cairns, et al. Expires January 7, 2016 [Page 12] Internet-Draft TLS SKI July 2015 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015. [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. Authors' Addresses Kelsey Cairns Washington State University Pullman, WA 99164-2752 USA Email: kcairns@wsu.edu John Mattsson Ericsson AB SE-164 80 Stockholm Sweden Email: john.mattsson@ericsson.com Robert Skog Ericsson AB SE-164 80 Stockholm Sweden Email: robert.skog@ericsson.com Cairns, et al. Expires January 7, 2016 [Page 13]