Internet DRAFT - draft-bhargavan-tls-resumption-indication
draft-bhargavan-tls-resumption-indication
Network Working Group K. Bhargavan
Internet-Draft A. Delignat-Lavaud
Expires: October 20, 2014 A. Pironti
Inria Paris-Rocquencourt
A. Langley
Google Inc.
M. Ray
Microsoft Corp.
April 18, 2014
Transport Layer Security (TLS) Resumption Indication Extension
draft-bhargavan-tls-resumption-indication-00
Abstract
When a TLS session is resumed via an abbreviated handshake, the
knowledge of the master secret is used to implicitly mutually
authenticate the two peers. However, an attacker can synchronize two
different TLS sessions, so that they share the same master secret,
breaking the resumption authentication property. This specification
defines a TLS extension that cryptographically binds the resumption
abbreviated handshake with its original session, thus preventing this
attack.
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 October 20, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bhargavan, et al. Expires October 20, 2014 [Page 1]
Internet-Draft TLS Resumption Extension April 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 4
4. The secure_resumption Extension . . . . . . . . . . . . . . . 4
4.1. Overwiev . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Extension definition . . . . . . . . . . . . . . . . . . 4
4.3. Client behavior: no resumption desired . . . . . . . . . 4
4.4. Client behavior: resumption desired . . . . . . . . . . . 5
4.4.1. Server behavior: resumption rejected . . . . . . . . 5
4.4.2. Server behavior: resumption accepted . . . . . . . . 5
5. Backward compatibility . . . . . . . . . . . . . . . . . . . 6
5.1. Client not supporting secure_resumption . . . . . . . . . 6
5.2. Server not supporting secure_resumption . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In TLS [RFC5246], a session is established by a full handshake, and
it can be resumed via abbreviated handshakes. Furthermore, several
full or abbreviated hansdshakes can follow over the same connection.
It is well known that, without the secure_renegotiation extension
[RFC5746], handshakes performed over the same connection are not
cryptographically bound: this means that an attacker can initiate a
communication with a server, then ask for renegotiation and plug a
connection originating from a victim client. The server will treat
this as a renegotiation, while the victim client will believe it is
the first handshake over the connection. The secure_renegotiation
extension fixes this by cryptographically binding each handshake
happening on a connection with the previous handshake that happened
on the same connection. Technically, according to [RFC5746], the
Client and Server Hello messages contain the client and server
verify_data generated by the previous handshake in the same
Bhargavan, et al. Expires October 20, 2014 [Page 2]
Internet-Draft TLS Resumption Extension April 2014
connection: if these data do not match at the client and server side,
then a renegotiation attack is detected, and the connection is
aborted.
Complementary, an existing session can be resumed via an abbreviated
handshake as the first handshake over a connection. In this case,
one needs to make sure that the peers resuming the session are indeed
the same as the ones who originated such session. In an abbreviated
TLS handshake, this is achieved by proving the knowledge of the
session master_secret, via the generation of the correct verify_data
content (and its encryption within the Finished message).
However, especially with the RSA key exchange method, an attacker can
easily synchronize two TLS sessions, so that they share the same
master_secret [TRIPLE-HS]. Suppose a client, C, is connecting to an
attacker, A. The attacker wishes to synchronize the client and a
victim server, S, so that both have a session cached with a master
secret and session ID that are known to the attacker.
1. C sends its "ClientHello.random" value to A.
2. A connects to S, using C's "ClientHello.random" value.
3. S responds to A, sending its "ServerHello.random",
"ServerHello.session_id" and certificate chain.
4. A responds to C with its own certificates, but using the server's
"ServerHello.random" and "ServerHello.session_id" values.
5. C proceeds with the key exchange, sending to A the
"pre_master_secret" value, encrypted with A's public key.
6. A decrypts the "pre_master_secret", re-encrypts it with the
server's public key and sends it on to S.
At this point, both sessions (between C and A, and between A and S)
share the same "pre_master_secret", "ClientHello.random" and
"ServerHello.random". Hence, the "master_secret" value will be equal
for the two sessions and it will be associated both at C and S with
the same session ID.
Note that the secure_renegotiation extension does not help in this
case, because both client and server are resuming a session as their
first handshake over the new connection, and hence the
secure_renegotiation values (empty values in this case) will also
match. Indeed, this resumption attack is dual to the renegotiation
one, and as such requires a dual extension to fix the problem.
Bhargavan, et al. Expires October 20, 2014 [Page 3]
Internet-Draft TLS Resumption Extension April 2014
2. Requirements Notation
This document uses the same notation and terminology used in the TLS
Protocol specification [RFC5246].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. The TLS Session Hash
When a full handshake takes place, and thus a new TLS session is
generated, implementations complying with this document MUST compute
the "session_hash", as defined in [session-hash].
Additionally, the session_hash MUST be stored along with the other
session data in the session database, or it MUST be included in the
session ticket, where applicable.
4. The secure_resumption Extension
4.1. Overwiev
This specification introduces a new TLS extension, called
"secure_resumption", that prevents the resumption attack described
above. Basically, this extension cryptographically binds any
abbreviated handshake with the original session the handshake is
trying to resume. Technically, this is achieved by adding to the
Client and Server Hello messages a "session_hash" associated to the
session being resumed.
4.2. Extension definition
The "secure_resumption" extension has type TBD. The "extension data"
field of this extension contains a "SecureResumption" structure:
struct {
opaque secure_resumption<0..255>;
} SecureResumption;
The content of this extension is explained below, together with the
different use case scenarios.
4.3. Client behavior: no resumption desired
When a client sends a Client Hello with empty session_id (and no
session ticket), it means it has no session to resume and is only
willing to establish a new session with the server. In this case,
Bhargavan, et al. Expires October 20, 2014 [Page 4]
Internet-Draft TLS Resumption Extension April 2014
the client MUST NOT send the secure_resumption extension in its
Client Hello message.
With such a Client Hello message, the server will start a new session
and, not seeing any secure_resumption extension, will not include it
in its Server Hello message.
Servers receiving an invalid Client Hello message containing an empty
ClientHello.session_id and a secure_resumption extension MUST NOT
send the secure_resumption extension back in the Server Hello.
Servers MAY abort the connection, or decide to continue ignoring the
secure_resumption extension given by the client.
4.4. Client behavior: resumption desired
When a client wishes to resume a session, it fills the
ClientHello.session_id (or sends a session ticket). In this case, a
client implementing this specification MUST also send a
secure_resumption extension, with SecureResumption.secure_resumption
filled with the session_hash value of the session being resumed.
4.4.1. Server behavior: resumption rejected
If the server rejects the client request to resume a session, it
provides a new ServerHello.session_id and proceeds with a full
handshake. In this case, a server implementing this specification
MUST NOT send a secure_resumption extension, and MUST ignore the
value of the secure_resumption extension sent by the client.
Clients receiving an invalid ServerHello containing a new
ServerHello.session_id value together with a secure_resumption
extension MUST ignore the content of the server provided
secure_resumption extension. Such clients MAY disconnect or continue
with a full handshake.
4.4.2. Server behavior: resumption accepted
If the server accepts to resume the session it MUST check that the
value contained in the ClientHello.secure_resumption extension
matches the locally stored session_hash for the session being
resumed.
If the check fails, the server MUST NOT continue with session
resumption; instead the server MAY abort the connection or start a
full handshake to generate a new session.
If the check succeeds, the server MAY continue with session
resumption. In this case, the server MUST include a
Bhargavan, et al. Expires October 20, 2014 [Page 5]
Internet-Draft TLS Resumption Extension April 2014
ServerHello.secure_resumption extension, filled with the session_hash
for the session being resumed.
4.4.2.1. Client behavior: resumption accepted
When the server accepts resumption, the client MUST check that a
ServerHello.secure_resumption is present, and it MUST check that its
content matches the locally stored session_hash for the session being
resumed.
If the match fails, the client MUST abort the connection. (At this
stage of the handshake, the client cannot ask anymore for a full
handshake, and the server already committed to an abbreviated one,
hence the only solution is to abort and re-start.)
If the match succeeds, the client continues with a normal abbreviated
handshake.
5. Backward compatibility
5.1. Client not supporting secure_resumption
It is easy for servers to identify clients not supporting the
secure_resumption extension: the ClientHello.session_id will be
filled, but no secure_resumption extension will be present. In such
cases, servers implementing this specification MUST refuse the
resumption request and hence continue with a full handshake. Note
that in practice, this disables resumption for all un-patched
clients.
5.2. Server not supporting secure_resumption
With the current definition of the extension, a client gets to know
whether a server supports or not the secure_resumption extension only
after the server has already committed to an abbreviated handshake.
If a client detects an un-patched server wishing to resume, it MUST
abort the session with a handshake_failure fatal alert, and re-start
a new connection proposing a full handshake.
6. Security Considerations
Without this extension, authentication over a resumed session is
based only on the uniqueness of the master_sercret. However, an
attacker can carefully craft two TLS sessions so that they share the
same master_secret, breaking the authentication properties of TLS in
case of resumed sessions.
Bhargavan, et al. Expires October 20, 2014 [Page 6]
Internet-Draft TLS Resumption Extension April 2014
This specification introduces a secure_resumption extension which
cryptographically binds an abbreviated handshake to the session being
resumed, by means of its session_hash. The session_hash value is
unique to each session, as it depends on all the data exchanged to
generate the session, including client and server randomness, their
identities, and the choices of the pre_master_secret.
In principle, the Client and Server Finished.verify_data of the full
handshake generating the session could be used instead of the
session_hash, because both the verify_data and the session_hash
depend on all the data that lead to the session context. However,
the verify_data is typically very short (12 bytes for all currently
defined cipher suites), and so collisions among verify_data of
different sessions are relatively easy to find. In this document, by
using the session_hash, the collision probability reduces to the
collision resistance of the chosen hash algorithm (ciper suite-
dependent for TLS 1.2, and concatenation of MD5 and SHA1 for all
previous TLS versions and SSL 3.0).
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
7.2. Informative References
[TRIPLE-HS]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
A., and P. Strub, "Triple Handshakes and Cookie Cutters:
Breaking and Fixing Authentication over TLS", IEEE
Symposium on Security and Privacy, to appear , 2014.
[session-hash]
Bhargavan, K., Delignat-Lavaud, A., Langley, A., Pironti,
A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", Internet Draft
, 2014.
Bhargavan, et al. Expires October 20, 2014 [Page 7]
Internet-Draft TLS Resumption Extension April 2014
Authors' Addresses
Karthikeyan Bhargavan
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris 75214 CEDEX 13
France
Email: karthikeyan.bhargavan@inria.fr
Antoine Delignat-Lavaud
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris 75214 CEDEX 13
France
Email: antoine.delignat-lavaud@inria.fr
Alfredo Pironti
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris 75214 CEDEX 13
France
Email: alfredo.pironti@inria.fr
Adam Langley
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
Email: agl@google.com
Marsh Ray
Microsoft Corp.
1 Microsoft Way
Redmond, WA 98052
USA
Email: maray@microsoft.com
Bhargavan, et al. Expires October 20, 2014 [Page 8]
