idnits 2.17.1 draft-bhargavan-tls-resumption-indication-00.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2014) is 3654 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Bhargavan 3 Internet-Draft A. Delignat-Lavaud 4 Expires: October 20, 2014 A. Pironti 5 Inria Paris-Rocquencourt 6 A. Langley 7 Google Inc. 8 M. Ray 9 Microsoft Corp. 10 April 18, 2014 12 Transport Layer Security (TLS) Resumption Indication Extension 13 draft-bhargavan-tls-resumption-indication-00 15 Abstract 17 When a TLS session is resumed via an abbreviated handshake, the 18 knowledge of the master secret is used to implicitly mutually 19 authenticate the two peers. However, an attacker can synchronize two 20 different TLS sessions, so that they share the same master secret, 21 breaking the resumption authentication property. This specification 22 defines a TLS extension that cryptographically binds the resumption 23 abbreviated handshake with its original session, thus preventing this 24 attack. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 20, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 62 3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 4 63 4. The secure_resumption Extension . . . . . . . . . . . . . . . 4 64 4.1. Overwiev . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.2. Extension definition . . . . . . . . . . . . . . . . . . 4 66 4.3. Client behavior: no resumption desired . . . . . . . . . 4 67 4.4. Client behavior: resumption desired . . . . . . . . . . . 5 68 4.4.1. Server behavior: resumption rejected . . . . . . . . 5 69 4.4.2. Server behavior: resumption accepted . . . . . . . . 5 70 5. Backward compatibility . . . . . . . . . . . . . . . . . . . 6 71 5.1. Client not supporting secure_resumption . . . . . . . . . 6 72 5.2. Server not supporting secure_resumption . . . . . . . . . 6 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 7.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 In TLS [RFC5246], a session is established by a full handshake, and 82 it can be resumed via abbreviated handshakes. Furthermore, several 83 full or abbreviated hansdshakes can follow over the same connection. 84 It is well known that, without the secure_renegotiation extension 85 [RFC5746], handshakes performed over the same connection are not 86 cryptographically bound: this means that an attacker can initiate a 87 communication with a server, then ask for renegotiation and plug a 88 connection originating from a victim client. The server will treat 89 this as a renegotiation, while the victim client will believe it is 90 the first handshake over the connection. The secure_renegotiation 91 extension fixes this by cryptographically binding each handshake 92 happening on a connection with the previous handshake that happened 93 on the same connection. Technically, according to [RFC5746], the 94 Client and Server Hello messages contain the client and server 95 verify_data generated by the previous handshake in the same 96 connection: if these data do not match at the client and server side, 97 then a renegotiation attack is detected, and the connection is 98 aborted. 100 Complementary, an existing session can be resumed via an abbreviated 101 handshake as the first handshake over a connection. In this case, 102 one needs to make sure that the peers resuming the session are indeed 103 the same as the ones who originated such session. In an abbreviated 104 TLS handshake, this is achieved by proving the knowledge of the 105 session master_secret, via the generation of the correct verify_data 106 content (and its encryption within the Finished message). 108 However, especially with the RSA key exchange method, an attacker can 109 easily synchronize two TLS sessions, so that they share the same 110 master_secret [TRIPLE-HS]. Suppose a client, C, is connecting to an 111 attacker, A. The attacker wishes to synchronize the client and a 112 victim server, S, so that both have a session cached with a master 113 secret and session ID that are known to the attacker. 115 1. C sends its "ClientHello.random" value to A. 117 2. A connects to S, using C's "ClientHello.random" value. 119 3. S responds to A, sending its "ServerHello.random", 120 "ServerHello.session_id" and certificate chain. 122 4. A responds to C with its own certificates, but using the server's 123 "ServerHello.random" and "ServerHello.session_id" values. 125 5. C proceeds with the key exchange, sending to A the 126 "pre_master_secret" value, encrypted with A's public key. 128 6. A decrypts the "pre_master_secret", re-encrypts it with the 129 server's public key and sends it on to S. 131 At this point, both sessions (between C and A, and between A and S) 132 share the same "pre_master_secret", "ClientHello.random" and 133 "ServerHello.random". Hence, the "master_secret" value will be equal 134 for the two sessions and it will be associated both at C and S with 135 the same session ID. 137 Note that the secure_renegotiation extension does not help in this 138 case, because both client and server are resuming a session as their 139 first handshake over the new connection, and hence the 140 secure_renegotiation values (empty values in this case) will also 141 match. Indeed, this resumption attack is dual to the renegotiation 142 one, and as such requires a dual extension to fix the problem. 144 2. Requirements Notation 146 This document uses the same notation and terminology used in the TLS 147 Protocol specification [RFC5246]. 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 3. The TLS Session Hash 155 When a full handshake takes place, and thus a new TLS session is 156 generated, implementations complying with this document MUST compute 157 the "session_hash", as defined in [session-hash]. 159 Additionally, the session_hash MUST be stored along with the other 160 session data in the session database, or it MUST be included in the 161 session ticket, where applicable. 163 4. The secure_resumption Extension 165 4.1. Overwiev 167 This specification introduces a new TLS extension, called 168 "secure_resumption", that prevents the resumption attack described 169 above. Basically, this extension cryptographically binds any 170 abbreviated handshake with the original session the handshake is 171 trying to resume. Technically, this is achieved by adding to the 172 Client and Server Hello messages a "session_hash" associated to the 173 session being resumed. 175 4.2. Extension definition 177 The "secure_resumption" extension has type TBD. The "extension data" 178 field of this extension contains a "SecureResumption" structure: 180 struct { 181 opaque secure_resumption<0..255>; 182 } SecureResumption; 184 The content of this extension is explained below, together with the 185 different use case scenarios. 187 4.3. Client behavior: no resumption desired 189 When a client sends a Client Hello with empty session_id (and no 190 session ticket), it means it has no session to resume and is only 191 willing to establish a new session with the server. In this case, 192 the client MUST NOT send the secure_resumption extension in its 193 Client Hello message. 195 With such a Client Hello message, the server will start a new session 196 and, not seeing any secure_resumption extension, will not include it 197 in its Server Hello message. 199 Servers receiving an invalid Client Hello message containing an empty 200 ClientHello.session_id and a secure_resumption extension MUST NOT 201 send the secure_resumption extension back in the Server Hello. 202 Servers MAY abort the connection, or decide to continue ignoring the 203 secure_resumption extension given by the client. 205 4.4. Client behavior: resumption desired 207 When a client wishes to resume a session, it fills the 208 ClientHello.session_id (or sends a session ticket). In this case, a 209 client implementing this specification MUST also send a 210 secure_resumption extension, with SecureResumption.secure_resumption 211 filled with the session_hash value of the session being resumed. 213 4.4.1. Server behavior: resumption rejected 215 If the server rejects the client request to resume a session, it 216 provides a new ServerHello.session_id and proceeds with a full 217 handshake. In this case, a server implementing this specification 218 MUST NOT send a secure_resumption extension, and MUST ignore the 219 value of the secure_resumption extension sent by the client. 221 Clients receiving an invalid ServerHello containing a new 222 ServerHello.session_id value together with a secure_resumption 223 extension MUST ignore the content of the server provided 224 secure_resumption extension. Such clients MAY disconnect or continue 225 with a full handshake. 227 4.4.2. Server behavior: resumption accepted 229 If the server accepts to resume the session it MUST check that the 230 value contained in the ClientHello.secure_resumption extension 231 matches the locally stored session_hash for the session being 232 resumed. 234 If the check fails, the server MUST NOT continue with session 235 resumption; instead the server MAY abort the connection or start a 236 full handshake to generate a new session. 238 If the check succeeds, the server MAY continue with session 239 resumption. In this case, the server MUST include a 240 ServerHello.secure_resumption extension, filled with the session_hash 241 for the session being resumed. 243 4.4.2.1. Client behavior: resumption accepted 245 When the server accepts resumption, the client MUST check that a 246 ServerHello.secure_resumption is present, and it MUST check that its 247 content matches the locally stored session_hash for the session being 248 resumed. 250 If the match fails, the client MUST abort the connection. (At this 251 stage of the handshake, the client cannot ask anymore for a full 252 handshake, and the server already committed to an abbreviated one, 253 hence the only solution is to abort and re-start.) 255 If the match succeeds, the client continues with a normal abbreviated 256 handshake. 258 5. Backward compatibility 260 5.1. Client not supporting secure_resumption 262 It is easy for servers to identify clients not supporting the 263 secure_resumption extension: the ClientHello.session_id will be 264 filled, but no secure_resumption extension will be present. In such 265 cases, servers implementing this specification MUST refuse the 266 resumption request and hence continue with a full handshake. Note 267 that in practice, this disables resumption for all un-patched 268 clients. 270 5.2. Server not supporting secure_resumption 272 With the current definition of the extension, a client gets to know 273 whether a server supports or not the secure_resumption extension only 274 after the server has already committed to an abbreviated handshake. 275 If a client detects an un-patched server wishing to resume, it MUST 276 abort the session with a handshake_failure fatal alert, and re-start 277 a new connection proposing a full handshake. 279 6. Security Considerations 281 Without this extension, authentication over a resumed session is 282 based only on the uniqueness of the master_sercret. However, an 283 attacker can carefully craft two TLS sessions so that they share the 284 same master_secret, breaking the authentication properties of TLS in 285 case of resumed sessions. 287 This specification introduces a secure_resumption extension which 288 cryptographically binds an abbreviated handshake to the session being 289 resumed, by means of its session_hash. The session_hash value is 290 unique to each session, as it depends on all the data exchanged to 291 generate the session, including client and server randomness, their 292 identities, and the choices of the pre_master_secret. 294 In principle, the Client and Server Finished.verify_data of the full 295 handshake generating the session could be used instead of the 296 session_hash, because both the verify_data and the session_hash 297 depend on all the data that lead to the session context. However, 298 the verify_data is typically very short (12 bytes for all currently 299 defined cipher suites), and so collisions among verify_data of 300 different sessions are relatively easy to find. In this document, by 301 using the session_hash, the collision probability reduces to the 302 collision resistance of the chosen hash algorithm (ciper suite- 303 dependent for TLS 1.2, and concatenation of MD5 and SHA1 for all 304 previous TLS versions and SSL 3.0). 306 7. References 308 7.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 314 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 316 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 317 "Transport Layer Security (TLS) Renegotiation Indication 318 Extension", RFC 5746, February 2010. 320 7.2. Informative References 322 [TRIPLE-HS] 323 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 324 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 325 Breaking and Fixing Authentication over TLS", IEEE 326 Symposium on Security and Privacy, to appear , 2014. 328 [session-hash] 329 Bhargavan, K., Delignat-Lavaud, A., Langley, A., Pironti, 330 A., and M. Ray, "Transport Layer Security (TLS) Session 331 Hash and Extended Master Secret Extension", Internet Draft 332 , 2014. 334 Authors' Addresses 336 Karthikeyan Bhargavan 337 Inria Paris-Rocquencourt 338 23, Avenue d'Italie 339 Paris 75214 CEDEX 13 340 France 342 Email: karthikeyan.bhargavan@inria.fr 344 Antoine Delignat-Lavaud 345 Inria Paris-Rocquencourt 346 23, Avenue d'Italie 347 Paris 75214 CEDEX 13 348 France 350 Email: antoine.delignat-lavaud@inria.fr 352 Alfredo Pironti 353 Inria Paris-Rocquencourt 354 23, Avenue d'Italie 355 Paris 75214 CEDEX 13 356 France 358 Email: alfredo.pironti@inria.fr 360 Adam Langley 361 Google Inc. 362 1600 Amphitheatre Parkway 363 Mountain View, CA 94043 364 USA 366 Email: agl@google.com 368 Marsh Ray 369 Microsoft Corp. 370 1 Microsoft Way 371 Redmond, WA 98052 372 USA 374 Email: maray@microsoft.com