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]