idnits 2.17.1
draft-cairns-tls-session-key-interface-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 135: '... MUST meet. Section 5 describes the...'
RFC 2119 keyword, line 371: '...on using the SKI MUST be mutually auth...'
RFC 2119 keyword, line 383: '... SKI MUST be designed with strong ac...'
RFC 2119 keyword, line 417: '...the Edge Servers MUST be logged and au...'
RFC 2119 keyword, line 420: '...rom Edge Servers MUST be globally moni...'
(22 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 235 has weird spacing: '... Client are t...'
== Line 238 has weird spacing: '... Server are t...'
== Line 245 has weird spacing: '... Server hosts...'
== Line 552 has weird spacing: '...essages is th...'
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHALL not' in this paragraph:
'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'.
-- The document date (October 19, 2015) is 3083 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '28' on line 539
== Unused Reference: 'RFC5054' is defined on line 1000, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'HEART'
** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 2546 (Obsoleted by RFC 2772)
** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017)
** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)
** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347)
** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422)
** Downref: Normative reference to an Informational RFC: RFC 5054
** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Downref: Normative reference to an Informational RFC: RFC 6091
** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)
** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162)
** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949)
** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325)
** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)
Summary: 18 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group K. Cairns
3 Internet-Draft Washington State University
4 Intended status: Standards Track J. Mattsson
5 Expires: April 21, 2016 R. Skog
6 D. Migault
7 Ericsson
8 October 19, 2015
10 Session Key Interface (SKI) for TLS and DTLS
11 draft-cairns-tls-session-key-interface-01
13 Abstract
15 This document describes a session key interface that can be used for
16 TLS and DTLS. The Heartbleed attack has clearly illustrated the
17 security problems with storing private keys in the memory of the TLS
18 server. Hardware Security Modules (HSM) offer better protection but
19 are inflexible, especially as more (D)TLS servers are running on
20 virtualized servers in data centers.
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on April 21, 2016.
39 Copyright Notice
41 Copyright (c) 2015 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
59 4. TLS Session Key Interface Architecture . . . . . . . . . . . 5
60 4.1. Architecture Overview . . . . . . . . . . . . . . . . . . 6
61 4.2. Security Analysis . . . . . . . . . . . . . . . . . . . . 6
62 4.2.1. Edge Server . . . . . . . . . . . . . . . . . . . . . 6
63 4.2.2. Key Server . . . . . . . . . . . . . . . . . . . . . 8
64 4.2.3. Communication and SKI . . . . . . . . . . . . . . . . 9
65 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 9
66 5. Session Key Interface (SKI) . . . . . . . . . . . . . . . . . 10
67 5.1. SKI Protocol Overview . . . . . . . . . . . . . . . . . . 12
68 5.1.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 12
69 5.1.2. Ephemeral Diffie Hellman . . . . . . . . . . . . . . 14
70 5.2. SKI Specification . . . . . . . . . . . . . . . . . . . . 14
71 5.2.1. Key Server Processing . . . . . . . . . . . . . . . . 16
72 6. Interaction with TLS Extensions . . . . . . . . . . . . . . . 16
73 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
74 7.1. ECDHE_ECDSA Key Exchange . . . . . . . . . . . . . . . . 17
75 7.1.1. SKI Request and Response with JSON/HTTP . . . . . . . 17
76 7.1.2. SKI Request and Response with CBOR/CoAP . . . . . . . 19
77 7.2. Static RSA Key Exchange . . . . . . . . . . . . . . . . . 19
78 7.2.1. SKI Request and Response with JSON/HTTP . . . . . . . 20
79 7.2.2. SKI Request and Response with CBOR/CoAP . . . . . . . 20
80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
86 1. Introduction
88 Transport Layer Security (TLS) is specified in [RFC5246] and the
89 Datagram Transport Layer Security (DTLS), which is based on TLS, is
90 specified in [RFC6347]. During the TLS handshake, the TLS client and
91 the TLS server exchange a symmetric session key called the premaster
92 secret. From the premaster secret, the client random, and the server
93 random, the endpoints derive a master secret, which in turn is used
94 to derive the traffic encryption keys and IVs. The TLS server is
95 authenticated during this process by presenting a certificate and
96 then proving possession of the private key corresponding to the
97 public key in the certificate.
99 An important principle in designing security architectures is to
100 limit access to keying material, especially long-lived secrets such
101 as private keys. The Heartbleed attack [HEART] has illustrated the
102 dangers of storing private keys in the memory of the TLS server.
104 The TLS Session Key Interface (SKI) defined in this document makes it
105 possible to store private keys in a highly trusted key server,
106 physically separated from client facing servers. With TLS SKI (see
107 Figure 1), the TLS Server is split into two distinct entities called
108 Edge Server and Key Server that communicate over an encrypted and
109 mutually authenticated channel using e.g. TLS. The Edge Server can
110 be placed close to the clients, reducing latency, while the Key
111 Server is placed in a safe location. One important use case is an
112 origin that operates a number of distributed HTTPS servers. The
113 public certificates (not private keys) are pre-provisioned in the
114 Edge Server. The Key Server handles all the private key operations.
115 It retains control of the private keys and can at any time reject a
116 request from the Edge Server, e.g. if there is reason to suspect that
117 the Edge Server has been compromised.
119 The interface SKI uses modern web technologies like JSON, CBOR, HTTP,
120 CoAP, TLS, and REST. SKI supports the most commonly used key
121 exchange methods DHE_RSA, ECDHE_ECDSA, ECDHE_RSA, and RSA, together
122 with X.509 [RFC5280] or raw public key [RFC7250] authentication. It
123 does not work with PSK or SRP authentication. Even though the
124 industry is quickly moving towards the more secure ECDHE key exchange
125 methods, which provides perfect forward secrecy, static RSA still
126 needs be supported in many deployments.
128 The remaining of the document is as follows. Section 2 defines the
129 terms used in this document. Section 3 describes the problem
130 statement and the need to centralize the private key operations to a
131 centralized Key Server as well as a standard interface to
132 interoperate with the Key Server. The resulting architecture is
133 detailed in Section 4 followed by a security analysis and security
134 requirements the different components as well as the SKI interface
135 MUST meet. Section 5 describes the SKI and defines a specific SKI
136 implementation based on HTTP and JSON. Section 6 position the SKI
137 toward the different TLS extensions, and Section 7 illustrates the
138 described SKI with examples.
140 2. Terminology
142 TLS Client
144 TLS Server
146 Edge Server
148 Key Server
150 SKI
152 3. Problem Statement
154 With TLS, a TLS Client can set up an authenticated and encrypted
155 channel with a TLS Server. Authentication of the TLS Server as well
156 as the negotiation of the TLS Session Keys are performed during the
157 TLS hand shake. The TLS hand shake as described in [RFC5246] details
158 two methods: RSA and ephemeral Diffie Hellman. In both case, the TLS
159 Server is expected to perform some cryptographic operations based on
160 a private key and thus requires to have access to the private key.
161 When a single server is involved, the key is expected to be hosted by
162 the server. However, numerous web applications cannot be hosted by a
163 single TLS Server. Most of the time multiple TLS Servers are needed.
164 In addition, multiple cloud provider or hosting providers provides
165 resource elasticity by instantiating TLS Servers and placing these
166 servers at the edge of the network in order to address the demand and
167 reduce latency. The various instances of TLS Server may be inside a
168 singe domain or across multiple domains like a private cloud combined
169 with other third party cloud providers.
171 As each instance of the TLS Server needs to be able to perform some
172 cryptographic operation with the private key, a number of ways may be
173 envisioned:
175 - 1) The cryptographic material, e.g. the private key is shared
176 between all TLS Server instances
178 - a) Cryptographic material is copied into the various
179 instances of the TLS Server
181 - b) Cryptographic material is outsourced and accessed by all
182 instances of TLS Servers
184 - 2) The cryptographic material is not shared and each instance has
185 its own cryptographic material
187 At first, hosting private key in memory of the TLS Server exposes the
188 cryptographic material to leakage as illustrated by the Heartbleed
189 attack [HEART]. One common practice used to protect keys is to
190 delegate the private key operations to a separate entity such as a
191 Hardware Security Module (HSM), something that is supported in many
192 TLS libraries. HSMs provide good security but are inflexible and may
193 be difficult to deploy when the TLS server runs on a virtualized
194 machine in the cloud, especially if the application server that uses
195 TLS moves between different data centers. Furthermore, while HSMs
196 protect against extraction of the private key, they do not protect
197 against misuse in case an adversary gains possession of the HSM
198 itself. In fact, an attacker taking control of the HSM can use the
199 HSM to encrypt (resp. decrypt) any clear text (resp. encrypted text).
200 Similarly, the use of a network-attached HSM does not prevent a
201 corrupted client to have provide the full access to encryption /
202 decryption unless some control access is performed to the data
203 provided. In general, access control policies on the data encrypted
204 / decrypted by the HSM are not provided. In addition, communication
205 protocols of HSM are specific HSM vendor. There are several other
206 proprietary session key interfaces deployed but no standardized
207 solution.
209 Then, copying private keys in multiple instances increases the
210 surface of attack is even increases the surface of attack with the
211 number of instances of TLS Server. One way to limit the surface of
212 attack is to use a public / private key generated for each instance
213 of TLS Server. More specifically, when a TLS Server instance is
214 corrupted, the and the attacker get access to the private key, this
215 key cannot be used for another instance. However, splitting keys per
216 instance comes also with some additional drawbacks. For example,
217 session resumption does not work between multiple instances of TLS
218 Servers. In addition, all newly generated public keys of each TLS
219 Servers needs to be signed by the Certificate Authority, which comes
220 with an additional management overhead.
222 The proposed TLS Session Key Interface Architecture proposes to have
223 a common cryptographic material hold by the Key Server shared by all
224 instances of the TLS Servers. In addition, the interface between the
225 TLS Severs and the Key Server is limited enforced to strong access
226 control policies so to limit the scope of use of the encryption /
227 decryption capabilities of the Server Key.
229 4. TLS Session Key Interface Architecture
230 4.1. Architecture Overview
232 The TLS Session Key Interface Architecture is composed of three main
233 components as described in Figure 1:
235 TLS Client are typically all web browsers or any TLS Client
236 initiating an handshake with the TLS Server.
238 Edge Server are the TLS Server part seen by the TLS Client. It is
239 designated as an Edge Server as it does not host the private
240 key of the TLS Server. Instead, when the private key is
241 involved, the cryptographic operation is performed by the Key
242 Server. Edge Servers are expected to be placed close to the
243 TLS Client in order to reduce the latency.
245 Key Server hosts the private key and performs the cryptographic
246 operations on behalf of the Edge Server. Note that the Key
247 Server may be connected to a HSM for example. In addition,
248 they may be a single Key Server or multiple Key Servers.
250 In order to implement the SKI, the servers implementations and TLS
251 libraries should make private key operation non blocking.
253 +------------+ Handshake +-------------+ SKI +------------+
254 | TLS Client | <---------> | Edge Server | <-------> | Key Server |
255 +------------+ +-------------+ +------------+
257 Figure 1: TLS Session Key Interface Architecture
259 4.2. Security Analysis
261 4.2.1. Edge Server
263 Edge Servers are serving the TLS traffic of the TLS Clients. Edge
264 Servers performs all necessary operations except the cryptographic
265 operations involving the private keys associated to the TLS Server.
267 If an Edge Server becomes compromised, an attacker is still likely to
268 perform some operations with the private key of the TLS Server by
269 interacting with the Key Server. The corrupted Edge Server may, for
270 example, generate the TLS master secrets and impersonates the Edge
271 Server. However, such attacks are not different from those that
272 existed on TLS Server.
274 The presented architecture presents the following advantages. First
275 the private key remains protected and cannot be retrieved by the
276 attacker. This was obviously not the case when the key was hosted on
277 the corrupted TLS Server. Then, the attack is contained to the
278 communications involving the Edge Servers. The corrupted Edge Server
279 does not compromise the other Edge Servers in the same way as when
280 the private key of the TLS Server is copied on all Edge Servers.
281 With the presented architecture, addressing the attack locally to the
282 corrupted Edge Server is sufficient. Note that in the case Edge
283 Servers are dynamically provisioned, it is likely that the
284 vulnerability found on one Edge Server may be also be found on other
285 Edge Servers. Such consideration are out of scope of the proposed
286 architecture, and are inherent to deployment cloning VMs or
287 instantiating VMs with an identical configuration. At last, Edge
288 Servers are not working on their own and still require some
289 communications with a centralized Key Server. Such communications
290 with the Key Server may also be used to qualify the activities of the
291 Edge Servers, and thus used to detect any abnormal behaviors. This
292 of course requires the Key Server to log and monitor the Edge
293 Servers' activities.
295 If an Edge Server becomes compromised, an attacker may perform
296 attacks such as chosen plain text attacks if it can request clear
297 text data to be encrypted or chosen cipher text attacks in case it
298 can provide encrypted data and get the corresponding clear text. One
299 way to limit such attacks is to monitor the activity of the Edge
300 Servers, and raise an alarm when suspicious activity has been
301 detected. In case the Edge Server has been tagged with a suspicious
302 activity, further investigations and audit may be performed on line
303 if the Edge Server is still running or off line otherwise. One way
304 to increase the difficulty of performing such attack is to make the
305 chosen text harder. This could be handled at the API level for
306 example, as detailed in Section 4.2.3.
308 A similar attack may be performed in an orchestrated way, for example
309 when multiple Edge Servers are compromised and are collaborating.
310 Collaboration may be used to perform a chosen plain text attack or a
311 chosen cipher text attack for example. The advantage of using
312 multiple compromised Edge Servers, is that the various requests are
313 less likely to be detected than if being sent by a single Edge
314 Server. Such attacks may be detected by monitoring the traffic not
315 on a per-Edge Server basis, but instead globally, and for example
316 look at the randomness distribution of the provided clear text or
317 cipher text.
319 If a Edge Server has been compromised and its private key has be
320 retrieved by the attacker, the attacker, is then able to send request
321 to the Key Server on behalf of the Edge Server. If the credentials
322 are not bound to the IP addresses, the queries attack may even be
323 performed from another host or IP address than the Edge Server.
325 4.2.2. Key Server
327 The Key Server is a crucial element of the architecture which
328 centralizes all the cryptographic operations involving the private
329 key of the TLS Server. The responsibility of the Key Server is top
330 keep the private key secret, while keeping the service available.
332 Although the Figure 1 represents only one Key Server, the
333 architecture may have multiple Key Servers in order to address the
334 traffic load or in order to provide high availability. Increasing
335 the number of Key Servers increases the surface of attack and so the
336 risk of leakage for the private key.
338 Even though the number of Key Servers may increase it number is
339 expected to remain way below the number of Edge Servers of TLS
340 Servers with a copy of the private key. As a result, the risks are
341 still reduced by several orders of magnitudes.
343 Increasing the number may also require some coordinated monitoring.
344 In fact, a single Key Server provides some centralized way to control
345 the cryptographic operations requested globally and for each
346 individual Edge Server. With multiple Key Servers, such analyze may
347 not be performed solely within the Key Server. Instead, logging data
348 may be outsourced to another component that performs the analysis.
350 If Key Server becomes compromised, the attacker is able to decrypt
351 any cypher text encrypted with the public key. More especially, an
352 attacker is able to read the server and client randoms as well as the
353 pre-master secret and then generate the session key. This is true
354 for on path traffic, but also for recorded traffic. For that purpose
355 it is recommended to favor key exchanges that enforce perfect forward
356 secrecy. In other words RSA is not recommended as specified in
357 section F.1.1.2 of [RFC5246].
359 Key Servers centralize all cryptographic operations performed with
360 the private key of the TLS Servers. This provides the Key Servers a
361 bottle neck position. If the Key Servers undergo a DoS or DDoS
362 attack, they can prevent the Edge Servers to set TLS sessions. Key
363 Servers should be over provisioned, and should be able to rate limit
364 requests from Edge Servers. In addition to authenticated traffic,
365 the Edge Server should be able to detect when traffic is being
366 replayed or when the identity of an Edge Server has been usurped -
367 like the Edge Server being stolen its private key.
369 4.2.3. Communication and SKI
371 The communication using the SKI MUST be mutually authenticated and
372 encrypted in order to have a malicious node hijacking the
373 communication or pretending its is a legitimate Edge Server and
374 serving TLS Clients.
376 Similarly, the communication between Edge Servers and Key Server
377 should be encrypted in order to avoid a malicious nodes to collect a
378 collection of clear text with their associated encrypted text and
379 eventually perform a replay attack.
381 TLS or IPsec are good candidates too secure the SKI communication.
383 SKI MUST be designed with strong access control in order to limit the
384 scope of actions performed by an authorized Edge Servers. This may
385 be performed by checking the properties of the inputs as well as
386 defining which inputs and actions are permitted.
388 Inputs provided to the Key Servers should be considered in order to
389 reduce the surface of attack. Suppose the Edge Server needs to
390 encrypt the hash of two random number. One way could do is first let
391 the Edge Server hash the two random number and then ask the Key
392 Server to encrypt the resulting hash. Such design exposes the Key
393 Server to clear text attack as, any fixed value value could be fixed
394 to the hash. On the other hand, the Edge Server could also provide
395 the two numbers to the Key Server, which in turn perform the hash
396 followed by the encryption. Doing so provides less control to the
397 Edge Server for choosing the clear text. Note also that in the
398 second case, the Key Server is performing more operations, and
399 communications may involve more data to be carried. As a result,
400 security and performance may be balanced.
402 Similarly, parameters provided should be strictly controlled in order
403 to narrow the scope of clear text / cipher text chosen attacks, and
404 when possible, length or syntax should be checked. In addition, when
405 an error occurs, the Key Server should limit the information provided
406 to the Edge Server. For example, it may be better to simply reject
407 the request with a general error message that does not specify the
408 specific error encountered, so this information may not be used by
409 the attacker. On the other hand, th error should be logged
410 precisely, so it may be used during the analysis.
412 4.3. Security Requirements
414 Here are the following requirements or recommendations regarding the
415 architecture.
417 REQ 1: The activity of the Edge Servers MUST be logged and audited
418 in order to detect suspicious activity.
420 REQ 2: The request from Edge Servers MUST be globally monitored in
421 order to detect some orchestrated attacks not detected at the
422 Edge Server level.
424 REQ 3: RSA based authentication is not recommended to preserve TLS
425 Client privacy and confidentiality in case of Key Server
426 leakage.
428 REQ 4: The communication between the Edge Server and the Key Server
429 MUST be mutually authenticated and encrypted. The use of
430 perfect forward secrecy cypher suites is recommended.
432 REQ 5: SKI MUST be designed to limit the possible operations
433 performed by the Edge Server. This involves strict control
434 of the parameters as well as specific design to avoid clear
435 text or cipher attacks.
437 REQ 6: SKI MUST NOT provide the Edge Server extra information in
438 case an error occurs.
440 REQ 7: SKI and Key Server MUST be monitored and logged to enable
441 further investigation and analysis.
443 5. Session Key Interface (SKI)
445 TLS provides different methods in order to agree on the pre_master
446 secret. One way - designated as "rsa" in [RFC5246] - consists in the
447 TLS Client provides the pre_master secret encrypted in a Client Key
448 Exchange message. The TLS Client encrypts the pre_master with the
449 public key previously provided by the server in a Server Certificate
450 message.
452 Other methods are based on the Diffie Hellman approach, which
453 provides perfect forward secrecy. As described in section F.1.1.3 of
454 [RFC4346], the TLS Server can either provide fixed Diffie Hellman
455 parameters in a Server Certificate message or provide ephemeral
456 Diffie Hellman parameters. In the first case, the TLS Client may
457 authenticate the Server Certificate with a DSA, RSA, ECDSA signature.
458 The TLS Server provides certificates the TLS Client is able to check.
459 In other words, the signature uses hash function and signature
460 algorithms supported by the TLS Client. When Diffie Hellman is not
461 authenticated, then the Diffie Hellman value is not provided in the
462 Server Certificate message. Instead, it is provided in an additional
463 Key Server Exchange message. In the second case, when ephemeral
464 Diffie Hellman values are provided the value is embedded in a Key
465 Server Exchange message with an additional Signature structure. The
466 Signature is computed by the TLS Server over the hash of the
467 ephemeral Diffie Hellman key together with a set of temporary values
468 (the ClientHello.random and the ServerHello.random) to avoid replay
469 attacks. The TLS Server provides the signature in accordance to the
470 hash and signature function supported by the TLS Client as well as
471 the key provided by the TLS Server in the Certificate message.
473 As a result, the private key of the TLS Server is only involved when
474 the following key exchanges algorithm (KeyExchangeAlgorithm) are
475 agreed between the TLS Client and the Edge Server:
477 RSA when the pre_master is entirely generated by the TLS_Client and
478 encrypted by the TLS Client in a Client Key Exchange message.
479 This authentication method is defined in [RFC5246].
481 DHE_RSA when the hash of the ephemeral Diffie Hellman key associated
482 to the temporary values is signed with the RSA private key. This
483 is defined in [RFC5246].
485 ECDHE_RSA Similar as above but with Elliptic Curve Diffie Hellman
486 values with an RSA signature. This method is defined in
487 [RFC4492].
489 ECDHE_ECDSA Similar as above but with elliptic curve signature.
490 This method is defined in [RFC4492].
492 The following document only considers these key exchange protocols.
493 If another key exchange protocol is negotiated, as currently defined,
494 there is no need to perform cryptographic operations involving the
495 private key. As a result, such key exchange protocols do not require
496 the Edge Server to interact with the Key Server, and are not
497 considered in this document. Instead, Edge Server should be
498 provisioned with the appropriated certificates.
500 DISCUSSION: It is not clear to me why DHE_DSS does not sign the
501 DHParameters.
503 This section designs the SKI. Section 5.1 provides an overview of
504 the SKI. More specifically, it describes the information that is
505 communicated between the Edge Server and the Key Server, but does not
506 provide any details on the protocols used to exchange these
507 information, nor how the private key is being identified. This is
508 left to Section 5.2 provides a specific implementation based on JSON
509 and HTTP.
511 5.1. SKI Protocol Overview
513 This section describes the interactions between the TLS Client, the
514 Edge Server and the Key Server when either RSA or ephemeral Diffie
515 Hellman (DHE_RSA, ECDHE_RSA or ECDHE_ECDSA) key agreement have been
516 agreed between the TLS Client an dthe Edge Server.
518 The description of this section applies for TLS 1.0 [RFC2246], TLS
519 1.1 [RFC4346], TLS 1.2 [RFC5246], DTLS 1.0 [RFC4347], DTLS 1.1
520 [RFC4347] and DTLS 1.2 [RFC6347].
522 5.1.1. RSA
524 In TLS1.2 [RFC5246] every session has a "master_secret" generated
525 from a pre_master. [RFC5246] and [RFC7627] defines different ways to
526 generate the master_secret from the pre_master. However, the way the
527 pre_master is agreed remains similar.
529 For information, in [RFC5246], the master_secret is generated as
530 follows:
532 master_secret = PRF(pre_master_secret, "master secret",
533 ClientHello.random + ServerHello.random)
534 [0..47];
536 where:
537 struct {
538 uint32 gmt_unix_time; # 4 bytes
539 opaque random_bytes[28];
540 } Random;
542 master_secret
544 [RFC7627] defines the Extended Master Secret Extension where the
545 "master_secret" is defined as follows:
547 master_secret = PRF(pre_master_secret, "extended master secret",
548 session_hash)
549 [0..47];
550 where:
551 - session_hash = Hash(handshake_messages)
552 - handshake_messages is the concatenation of all the exchanged
553 Handshake structures, as defined in Section 7.4 of [RFC5246].
554 - Hash is as defined in Section 7.4.9 of [RFC5246]
556 As defined in section 8.1.1 [RFC2546], the pre_master is 48-byte
557 generated by the TLS Client. The two first bytes indicates the TLS
558 version and MUST be the same value as the one provided by the
559 ClientHello.client_version, and the remaining 46 bytes are expected
560 to be random.
562 The pre_master is encrypted with the public key of the TLS Server as
563 a EncryptedPreMasterSecret structure sent in the Client Key Exchange
564 Message as described in section 7.4.7.1 [RFC5246]. The encryption
565 follows for compatibility with previous TLS version RSAES-PKCS1-v1_5
566 scheme described in [RFC3447], which results in a 256 byte encrypted
567 message for a 2048-bit RSA key or 128 byte encrypted message for a
568 1024 bit RSA key.
570 <---------- 256 bytes ------------------------------>
571 <-- 205 bytes --> <- 48 bytes ->
572 <- TLS ->
573 version
574 +----+----+------------------+----+-----+-----+--------+
575 | 00 | 02 | non-zero padding | 00 | maj | min | random |
576 +----+----+------------------+----+-----+-----+--------+
578 PKCS#1 padding for pre_master secret encrypted with 2048-bit RSA key
580 Upon receiving a Client Key Exchange Message with a
581 KeyExchangeAlgorithm set to rsa, the Edge Server sends a request for
582 the pre_master to the Key Server. The request provides the
583 EncryptedPreMasterSecret as well as the ClientHello.client_version.
585 Upon receiving the EncryptedPreMasterSecret and the
586 ClientHello.client_version, the Key Server decrypts the
587 EncryptedPreMasterSecret following [RFC3447]. If the decryption is
588 successful, the Key Server MUST check the version indicated in the
589 two first bytes corresponds to the ClientHello.client_version as well
590 as the length of the clear text pre_master. If one of the test
591 fails, the Key Server MUST return an 'malformed request' error. If
592 any other error occurs an 'unspecified error' MUST be returned. If
593 it is successful, the Key Server returns the clear text of the
594 pre_master.
596 Upon receiving the response or the error, the Edge Server proceeds as
597 defined in [RFC2546]. If the pre_master is provided, the Edge Server
598 computes the master_secret as defined in [RFC5246] or in [RFC7627].
599 If an error is returned, the Edge Server continue the exchange with a
600 randomly generated pre_master.
602 DISCUSSION: if SKI is the interface between the Edge Server and the
603 Key Server, maybe we could return the master_secret directly. Maybe
604 an architecture with a Master Oracle and Key Server would better
605 split the function between owning the private key - and only
606 decrypting - and providing the master with associate TLS syntax
607 checking.
609 5.1.2. Ephemeral Diffie Hellman
611 [RFC5246] defines how the TLS Client and the Edge Server agrees for
612 DHE_RSA. When the KeyExchangeAlgorythm has been agreed to dhe_rsa,
613 as defined in section 7.4.3 of [RFC5246], the ServerKeyExchange
614 message contains ServerDHParams as well as the Signature.
616 [RFC4492] defines the extension that enables the TLS Client and the
617 Edge Server to agree ECDHE_RSA or ECDHE_ECDSA for the key exchange
618 algorithm. When the KeyExchangeAlgorythm has been agreed to
619 ec_diffie_hellman between the TLS Client and the Edge Server, as
620 detailed in section 5.4 of [RFC4492], the ServerKeyExchange contains
621 the ServerECDHParams and Signature.
623 In order to build the signature, the Edge Server provides Key Server
624 the type of the key (ECHDE or DHE), the corresponding public key, the
625 hash function, the signature algorithm to be used (RSA, or ECDSA),
626 the ClientHello.random and the ServerHello.random.
628 Upon receiving the public key, the Key Server checks random numbers
629 are 32bit long, and checks the validity of the public key. If the
630 input data is not valid or has the wrong size, the Key Server MUST
631 reply with a 'malformed request' error. Otherwise the Key Server
632 hash and signs the output. If any error occurs during the signing
633 process, the server responds with an 'unspecified error' error. If
634 signing is successful, the server responds with the output data set
635 to the result of the signing operation.
637 Upon receiving the response or the error, the Edge Server proceeds as
638 defined in [RFC2546]. If the pre_master is provided, the Edge Server
639 computes the master_secret as defined in [RFC5246] or in [RFC7627].
640 If an error is returned, the Edge Server continue the exchange with a
641 randomly generated pre_master.
643 5.2. SKI Specification
645 The Session Key Interface is based on a request-response pattern
646 where the Edge Server sends a SKI Request to the Key Server
647 requesting a specific private key operation that the Edge Server
648 needs to complete a TLS handshake. The Edge Server's request
649 includes data to be processed, the identifier of the private key to
650 be used, and any options necessary for the Key Server to correctly
651 perform the requested operation. The Key Server answers with a SKI
652 Response containing either the requested output data or an error.
654 Any request-response protocol can be used to carry the SKI payloads.
655 Two obvious choices are the Hypertext Transfer Protocol (HTTP)
656 [RFC7540] and the Constrained Application Protocol (CoAP) [RFC7252].
657 Which protocol to use is application specific. SKI requests are by
658 default sent to the Request-URI '/ski'. The interface between the
659 Edge Server and the Key Server MUST be protected by a security
660 protocol providing integrity protection, confidentiality, and mutual
661 authentication. If TLS is used, the implementation MUST fulfill at
662 least the security requirements in [RFC7540] Section 9.2.
664 Two formats are defined for the SKI Payload format: the JavaScript
665 Object Notation (JSON) [RFC7159] and the Concise Binary Object
666 Representation (CBOR) [RFC7049]. In JSON, byte strings are Base64
667 encoded [RFC4648]. Which format to use is application specific. The
668 payload consists of a single JSON or CBOR object consisting of one or
669 more attribute-value pairs. The following attributes are defined:
671 'protocol' REQUIRED in SKI requests. Specifies the protocol version
672 negotiated in the handshake between Client and Edge Server. Can
673 take one of the values 'TLS 1.0', 'TLS 1.1', 'TLS 1.2', 'DTLS
674 1.0', or 'DTLS 1.2'.
676 'spki' REQUIRED in SKI requests. Byte string that identifies the
677 Subject Public Key Info (SPKI) of a X.509 certificate [RFC5280] or
678 a raw public key [RFC7250]. Contains a SHA-256 SPKI Fingerprint
679 as defined in [RFC7469]
681 'method' Included in SKI requests to indicate the key exchange
682 method. Can take one of the values 'ECDHE' or 'RSA'. MAY be
683 omitted if the default value 'ECDHE' is used.
685 'hash' Included in SKI requests. MUST be used if a hash algorithm
686 other than the default hash algorithm has been negotiated using
687 the "signature_algorithms" extension. Can take one of the values
688 'SHA-224', 'SHA-256', 'SHA-384', or 'SHA-512'.
690 'input' REQUIRED in SKI requests. Byte string containing the input
691 data to the private key operation. For static RSA it contains the
692 encrypted premaster secret (EncryptedPreMasterSecret). For ECDHE
693 it contains the data to be signed (ClientRandom + ServerRandom +
694 ServerECDHParams).
696 'output' Included in successful SKI responses. Byte string
697 containing the output data from the private key operation. For
698 static RSA it contains the premaster secret (PreMasterSecret).
699 For ECDHE is contains the signature (Signature).
701 'error' Included in SKI responses to indicate a fatal error. Can
702 take one of the values 'request denied', 'spki not found',
703 'malformed request', or 'unspecified error'. SHALL not be sent
704 together with 'output'.
706 5.2.1. Key Server Processing
708 The Key Server determines how to handle a SKI request based on the
709 values provided for the 'protocol', 'spki', 'hash', and 'method'
710 attributes. If the Key Server cannot parse the SKI request it MUST
711 respond with a 'malformed request' error. If a private key matching
712 the 'spki' value is not found, the Key Server MUST respond with a
713 'spki not found' error. If the Edge Server is not authorized to
714 receive a response to the specific request, the Key Server MUST
715 respond with a 'request denied' error.
717 DISCUSSION: For TLS1.0/DTLS1.0 only uses MD5 and SHA-1 are defined.
718 SHA-256 only appears in TLS1.2. I suspect there are some additional
719 checks to be done, or maybe that is fine to have TLS1.0 with these
720 algorithms.
722 6. Interaction with TLS Extensions
724 Most TLS extensions interact seamlessly with SKI, but it is worth
725 noting the few that do not:
727 [RFC6091] defines the use of OpenPGP certificates with TLS. As
728 OpenPGP certificates do not have a SPKI field, SKI will not work
729 with this extension unless the public key identification mechanism
730 is updated.
732 [RFC6962] certificate transparency conflict with the proposed
733 version of SKI since it requires signing of timestamps, while SKI
734 only allows signing of valid ECDHE parameters.
736 A few other TLS extensions may have problems if a TLS client connects
737 to different Edge Servers:
739 [RFC5077] defines session resumption with session tickets. As
740 this extension uses a secret key stored on the server issuing the
741 ticket, it only works if the resumption Edge Server has the same
742 secret key.
744 [RFC5746] defines the renegotiation_info extension for secure
745 renegotiation. As this extension is facilitated by binding the
746 renegotiation to the previous connection, it only works if the
747 renegotiation is done to the same Edge Server.
749 7. Examples
751 Note: Lengths of hexadecimal and base64 encoded strings in examples
752 are not intended to be realistic. For readability, COSE objects are
753 represented using CBOR's diagnostic notation [RFC7049].
755 7.1. ECDHE_ECDSA Key Exchange
757 If an ECDHE key exchange method is used, the Edge Server MUST receive
758 the SKI Response before it can send the ServerKeyExchange message.
759 An example message flow is shown in Figure 2.
761 +--------+ +-------------+ +------------+
762 | Client | | Edge Server | | Key Server |
763 +--------+ +-------------+ +------------+
765 ClientHello (Client Random)
766 --------------------------------------->
767 ServerHello (Server Random)
768 <---------------------------------------
769 Certificate (Server Certificate)
770 <---------------------------------------
771 SKI Request
772 -------------------->
773 SKI Response
774 ServerKeyExchange <--------------------
775 (ECDHParams, Signature)
776 <---------------------------------------
777 ClientKeyExchange (ClientDHPublic)
778 --------------------------------------->
779 Finished
780 <-------------------------------------->
782 Figure 2: Message Flow for ECDHE Key Exchange
784 7.1.1. SKI Request and Response with JSON/HTTP
785 SKI Request:
787 POST /ski HTTP/1.1
788 Host: keyserver.example.com
789 Content-Type: application/json
790 Content-Length: 166
792 {
793 "protocol": "TLS 1.2",
794 "method": "ECDHE",
795 "hash": "SHA-256",
796 "spki": "mPgHXSvrW6ygN4uhPnl0W2uGMSbCDjFV1bfkaVT5",
797 "input": "Bn1eaonvIyCDFd9Ek8UyghL9SA1FXcDplnk8zNlLXBL4H0FAEFyvFO"
798 }
800 SKI Response:
802 HTTP/1.1 200 OK
803 Content-Type: application/json
804 Content-Length: 62
806 {
807 "output": "eysh5GCSbIjjHzDt7Co5PUuVnDePbUYI839yv30bJWquwJ3vyADor"
808 }
810 SKI Request:
812 POST /ski HTTP/1.1
813 Host: keyserver.example.com
814 Content-Type: application/json
815 Content-Length: 128
817 {
818 "protocol": "TLS 1.1",
819 "spki": "p8FU0McKWBBLEEFfQbnJPjW3Q6EcZ5t11cKKcuwj",
820 "input": "yWCMO9P0yINtHUT17ZO1X1mUgwh1CrTGan9QaAGph9AnCO4HA44nez"
821 }
823 SKI Response:
825 HTTP/1.1 200 OK
826 Content-Type: application/json
827 Content-Length: 62
829 {
830 "output": "m7nJUltTVMiaQJyDcKPaq0ZOtfuRVnUt1cUx5KoP3w75MqpSelutO"
831 }
833 7.1.2. SKI Request and Response with CBOR/CoAP
835 SKI Request:
837 Header: POST (T=CON, Code=0.03, MID=0x1337)
838 Uri-Path: "ski"
839 Content-Format: 60 (application/cbor)
840 Payload: {
841 "protocol": "TLS 1.0",
842 "spki": h'a1fa7ec57a6a5485756c45ab58b2c992',
843 "input": h'd2e61706059a16714e4716853e2917e34'
844 }
846 SKI Response:
848 Header: 2.04 Changed (T=ACK, Code=2.04, MID=0x1337)
849 Content-Format: 60 (application/cbor)
850 Payload: { "output": h'2c8a0001b8295ab44d1930b8efdd9fb40' }
852 7.2. Static RSA Key Exchange
854 If the static RSA key exchange method is used, the Edge Server MUST
855 receive the SKI Response before it can send the Finished message. An
856 example message flow is shown in Figure 3.
858 +--------+ +-------------+ +------------+
859 | Client | | Edge Server | | Key Server |
860 +--------+ +-------------+ +------------+
862 ClientHello (Client Random)
863 --------------------------------------->
864 ServerHello (Server Random)
865 <---------------------------------------
866 Certificate (Server Certificate)
867 <---------------------------------------
868 ClientKeyExchange
869 (Encrypted Premaster Secret)
870 --------------------------------------->
871 SKI Request
872 -------------------->
873 SKI Response
874 <--------------------
875 Finished
876 <-------------------------------------->
878 Figure 3: Message Flow for Static RSA Key Exchange
880 7.2.1. SKI Request and Response with JSON/HTTP
882 SKI Request:
884 POST /ski HTTP/1.1
885 Host: keyserver.example.com
886 Content-Type: application/json
887 Content-Length: 145
889 {
890 "protocol": "TLS 1.2",
891 "method": "RSA",
892 "spki": "QItwmcEKcuMhCWIdESDPBbZtNgfwS7w84wizTk47",
893 "input": "dEHffkdIoi2YhQmsqcum3kDk2cToQqO2JLzJVi4q8pJSvfSUyyhRv7"
894 }
896 SKI Response:
898 HTTP/1.1 200 OK
899 Content-Type: application/json
900 Content-Length: 62
902 {
903 "output": "CtehRGUae6NQ0daIuClSTg3nW62zqPvYTjnvIV0mt5kM49tIq9uDG"
904 }
906 7.2.2. SKI Request and Response with CBOR/CoAP
908 SKI Request:
910 Header: POST (T=CON, Code=0.03, MID=0xabba)
911 Uri-Path: "ski"
912 Content-Format: 60 (application/cbor)
913 Payload: {
914 "protocol": "TLS 1.2",
915 "method": "RSA",
916 "spki": h'8378d0547da09484b8ae509565b0a595',
917 "input": h'9da2d7a363ead429141f4dcad20befb6043'
918 }
920 SKI Response:
922 Header: 2.04 Changed (T=ACK, Code=2.04, MID=0xabba)
923 Content-Format: 60 (application/cbor)
924 Payload: { "output" : h'827628ca533a1d1191acb0e106fb' }
926 8. IANA Considerations
928 This document defines the following. TODO...
930 9. Security Considerations
932 The security considerations in [RFC5246], [RFC4492], and [RFC7525]
933 apply to this document as well.
935 The TLS Session Key Interface increases the security by making it
936 possible to store private keys in a highly trusted location,
937 physically separated from client facing servers. The main feature
938 that separates TLS SKI from traditional TLS is the secure connection
939 between the Edge Server and the Key Server. This connection is
940 relied on to ensure that the servers are mutually authenticated and
941 that the connection between them is private. A compromised Edge
942 Server can still access client data as well as submit requests to the
943 Key Server. However, the risks are reduces since no private keys can
944 be compromised and the Key Server can at any time prevent the Edge
945 Server from starting new TLS connections.
947 A compromised Edge Server could potentially launch timing side-
948 channel attacks or buffer overflow attacks. And as the Key Server
949 has limited knowledge of the input data it signs or decrypts, a
950 compromised edge server could try to get the Key Server to process
951 maliciously crafted input data resulting in a signed message or the
952 decryption of the PreMasterSecret from another connection. However,
953 these attacks are not introduced by SKI since they could be performed
954 on a compromised traditional TLS server and, with the exception of
955 the signing attack, can even be launched by a TLS client against an
956 uncompromised TLS server.
958 10. Acknowledgements
960 The authors would like to thank Magnus Thulstrup and Hans Spaak for
961 their valuable comments and feedback.
963 11. References
965 [HEART] Codenomicon, "The Heartbleed Bug",
966 .
968 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
969 RFC 2246, DOI 10.17487/RFC2246, January 1999,
970 .
972 [RFC2546] Durand, A. and B. Buclin, "6Bone Routing Practice",
973 RFC 2546, DOI 10.17487/RFC2546, March 1999,
974 .
976 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
977 Standards (PKCS) #1: RSA Cryptography Specifications
978 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
979 2003, .
981 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
982 (TLS) Protocol Version 1.1", RFC 4346,
983 DOI 10.17487/RFC4346, April 2006,
984 .
986 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
987 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
988 .
990 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
991 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
992 for Transport Layer Security (TLS)", RFC 4492,
993 DOI 10.17487/RFC4492, May 2006,
994 .
996 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
997 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
998 .
1000 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
1001 "Using the Secure Remote Password (SRP) Protocol for TLS
1002 Authentication", RFC 5054, DOI 10.17487/RFC5054, November
1003 2007, .
1005 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
1006 "Transport Layer Security (TLS) Session Resumption without
1007 Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
1008 January 2008, .
1010 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1011 (TLS) Protocol Version 1.2", RFC 5246,
1012 DOI 10.17487/RFC5246, August 2008,
1013 .
1015 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1016 Housley, R., and W. Polk, "Internet X.509 Public Key
1017 Infrastructure Certificate and Certificate Revocation List
1018 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1019 .
1021 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
1022 "Transport Layer Security (TLS) Renegotiation Indication
1023 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
1024 .
1026 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
1027 for Transport Layer Security (TLS) Authentication",
1028 RFC 6091, DOI 10.17487/RFC6091, February 2011,
1029 .
1031 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1032 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
1033 January 2012, .
1035 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1036 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
1037 .
1039 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
1040 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
1041 October 2013, .
1043 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
1044 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
1045 2014, .
1047 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
1048 Weiler, S., and T. Kivinen, "Using Raw Public Keys in
1049 Transport Layer Security (TLS) and Datagram Transport
1050 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
1051 June 2014, .
1053 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
1054 Application Protocol (CoAP)", RFC 7252,
1055 DOI 10.17487/RFC7252, June 2014,
1056 .
1058 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
1059 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
1060 2015, .
1062 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
1063 "Recommendations for Secure Use of Transport Layer
1064 Security (TLS) and Datagram Transport Layer Security
1065 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
1066 2015, .
1068 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
1069 Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
1070 DOI 10.17487/RFC7540, May 2015,
1071 .
1073 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
1074 Langley, A., and M. Ray, "Transport Layer Security (TLS)
1075 Session Hash and Extended Master Secret Extension",
1076 RFC 7627, DOI 10.17487/RFC7627, September 2015,
1077 .
1079 Authors' Addresses
1081 Kelsey Cairns
1082 Washington State University
1083 Pullman, WA 99164-2752
1084 USA
1086 Email: kcairns@wsu.edu
1088 John Mattsson
1089 Ericsson AB
1090 SE-164 80 Stockholm
1091 Sweden
1093 Email: john.mattsson@ericsson.com
1095 Robert Skog
1096 Ericsson AB
1097 SE-164 80 Stockholm
1098 Sweden
1100 Email: robert.skog@ericsson.com
1102 Daniel Migault
1103 Ericsson
1104 8400 boulevard Decarie
1105 Montreal, QC H4P 2N2
1106 Canada
1108 Phone: +1 514-452-2160
1109 Email: daniel.migault@ericsson.com