idnits 2.17.1 draft-bhargavan-tls-session-hash-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 '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 (July 21, 2014) is 3559 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: January 22, 2015 A. Pironti 5 Inria Paris-Rocquencourt 6 A. Langley 7 Google Inc. 8 M. Ray 9 Microsoft Corp. 10 July 21, 2014 12 Transport Layer Security (TLS) Session Hash and 13 Extended Master Secret Extension 14 draft-bhargavan-tls-session-hash-01 16 Abstract 18 The Transport Layer Security (TLS) master secret is not 19 cryptographically bound to important session parameters such as the 20 client and server identities. Consequently, it is possible for an 21 active attacker to set up two sessions, one with a client and another 22 with a server such that the master secrets on the two sessions are 23 the same. Thereafter, any mechanism that relies on the master secret 24 for authentication, including renegotiation after session resumption, 25 becomes vulnerable to a man-in-the-middle attack, where the attacker 26 can simply forward messages back and forth between the client and 27 server. This specification defines a TLS extension that contextually 28 binds the master secret to a log of the full handshake that computes 29 it, thus preventing such attacks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 22, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 67 3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5 68 4. The extended master secret . . . . . . . . . . . . . . . . . 5 69 5. Extension negotiation . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Extension definition . . . . . . . . . . . . . . . . . . 6 71 5.2. Client and Server Behavior . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 7. Acknowdledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 In TLS [RFC5246], every session has a "master_secret" computed as: 83 master_secret = PRF(pre_master_secret, "master secret", 84 ClientHello.random + ServerHello.random) 85 [0..47]; 87 where the "pre_master_secret" is the result of some key exchange 88 protocol. For example, when the handshake uses an RSA ciphersuite, 89 this value is generated uniformly at random by the client, whereas 90 for DHE ciphersuites, it is the result of a Diffie-Hellman key 91 agreement. 93 As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, 94 an active attacker can synchronize two TLS sessions so that they 95 share the same "master_secret". For an RSA key exchange where the 96 client is unauthenticated, this is achieved as follows. Suppose a 97 client, C, connects to a malicious server, A. A then connects to a 98 server, S, and completes both handshakes. For simplicity, assume 99 that C and S only use RSA ciphersuites. (Note that C thinks it is 100 connecting to A and is oblivious of S's involvement.) 102 1. C sends a "ClientHello" to A, and A forwards it to S. 104 2. S sends a "ServerHello" to A, and A forwards it to C. 106 3. S sends a "Certificate", containing its certificate chain, to A. 107 A replaces it with its onw certificate chain and sends it to C. 109 4. S sends a "ServerHelloDone" to A, and A forwards it to C. 111 5. C sends a "ClientKeyExchange" to A, containing the 112 "pre_master_secret", encrypted with A's public key. A decrypts 113 the "pre_master_secret", re-encrypts it with S's public key and 114 sends it on to S. 116 6. C sends a "Finished" to A. A computes a "Finished" for its 117 connection with S, and sends it to S. 119 7. S sends a "Finished" to A. A computes a "Finished" for its 120 connection with C, and sends it to C. 122 At this point, both connection (between C and A, and between A and S) 123 have new sessions that share the same "pre_master_secret", 124 "ClientHello.random", "ServerHello.random", as well as other session 125 parameters, including the session identifier and, optionally, the 126 session ticket. Hence, the "master_secret" value will be equal for 127 the two sessions and it will be associated both at C and S with the 128 same session ID, even though the server identities on the two 129 connections are different. Moreover, the record keys on the two 130 connections will also be the same. 132 Similar scenarios can be achieved when the handshake uses a DHE 133 ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit 134 curves. Even if the client or server does not prefer using RSA or 135 DHE, the attacker can force them to use it by offering only RSA or 136 DHE in its hello messages. Other key exchanges may also be 137 vulnerable. If client authentication is used, the attack still 138 works, except that the two sessions now differ on both client and 139 server identities. 141 Once A has synchronized the two connections, since the keys are the 142 same on the two sides, it can step away and transparently forward 143 messages between C and S, reading and modifying when it desires. In 144 the key exchange literature, such occurences are called unknown key- 145 share attacks, since C and S share a secret but they both think that 146 their secret is shared only with A. In itself, these attacks do not 147 break integrity or confidentiality between honest parties, but they 148 offer a useful starting point from which to mount impersonation 149 attacks on C and S. 151 Suppose C tries to resume its session on a new connection with A. A 152 can then resume its session with S on a new connection and forward 153 the abbreviated handshake messages unchanged between C and S. Since 154 the abbreviated handshake only relies on the master secret for 155 authentication, and does not mention client or server identities, 156 both handshakes complete successfully, resulting in the same session 157 keys and the same handshake log. A still knows the connection keys 158 and can send messages to both C and S. 160 Critically, on the new connection, even the handshake log is the same 161 on C and S, thus defeating any man-in-the-middle protection scheme 162 that relies on the uniqueness of finished messages, such as the 163 secure renegotiation indication extension [RFC5746] or TLS channel 164 bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on 165 such session synchronization attacks. In particular, it describes a 166 man-in-the-middle attack that circumvents the protections of 167 [RFC5746] to break client-authenticated TLS renegotiation after 168 session resumption. Similar attacks apply to application-level 169 authentication mechanisms that rely on channel bindings [RFC5929] or 170 on key material exported from TLS [RFC5705]. 172 The underlying protocol issue is that since the master secret is not 173 guaranteed to be unique across sessions, it cannot be used on its own 174 as an authentication credential. This specification introduces a TLS 175 extension that computes the "master_secret" value from the log of the 176 handshake that computes it, so that different handshakes will, by 177 construction, create different master secrets. 179 2. Requirements Notation 181 This document uses the same notation and terminology used in the TLS 182 Protocol specification [RFC5246]. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 3. The TLS Session Hash 190 When a full handshake takes place, we define 192 session_hash = Hash(handshake_messages) 194 where "handshake_messages" refers to all handshake messages sent or 195 received, starting at client hello up to and including the Client Key 196 Exchange message, including the type and length fields of the 197 handshake messages. This is the concatenation of all the exchanged 198 Handshake structures, as defined in Section 7.4 of [RFC5246]. 200 The hash function "Hash" is defined by the ciphersuite in TLS 1.2. 201 In all previous versions of TLS and in SSL 3.0, this function 202 computes the concatenation of MD5 and SHA1. 204 There is no "session_hash" for resumed handshakes, as they do not 205 lead to the creation of a new session. 207 Implementation note: As described in Section 4, the "session_hash" is 208 used in the extended master secret computation. Hence, it must be 209 possible to compute the session_hash before the master secret is 210 computed. In SSL 3.0, the master secret is first needed in the 211 Client's CertificateVerify message. Hence, it is widespread 212 implementation practice to compute the master secret as soon as the 213 "pre_master_secret" is available, typically immediately before or 214 after sending the Client Key Exchange message. The definition of 215 "session_hash" given in this document requires minimal patches to 216 such implementations in order to implement the extended master secret 217 extension. Our definition is also compatible with the common 218 implementation practice of keeping running hashes of the handshake 219 log. 221 4. The extended master secret 223 When the extended master secret extension is negotiated, the 224 "master_secret" is computed as 226 master_secret = PRF(pre_master_secret, "extended master secret", 227 session_hash) 228 [0..47]; 230 The "session_hash" depends upon a handshake log that includes 231 "ClientHello.random" and "ServerHello.random", in addition to 232 ciphersuites, client and server certificates. Consequently, the 233 extended master secret depends upon the choice of all these session 234 parameters. 236 Our proposed design reflects the recommendation that keys should be 237 bound to the security contexts that compute them [sp800-108]. The 238 technique of mixing a hash of the key exchange messages into master 239 key derivation is already used in other well-known protocols such as 240 SSH [RFC4251]. 242 5. Extension negotiation 244 5.1. Extension definition 246 This document defines a new TLS extension, "extended_master_secret" 247 (with extension type TBA), which is used to signal both client and 248 server to use the extended master secret computation. The 249 "extension_data" field of this extension is empty. Thus, the entire 250 encoding of the extension is XX XX 00 00. 252 If client and server agree on this extension and a full handshake 253 takes place, both client and server MUST use the extended master 254 secret derivation algorithm, as defined in Section 4. 256 5.2. Client and Server Behavior 258 In its ClientHello message, a client implementing this document MUST 259 send the "extended_master_secret" extension. 261 If a server receives the "extended_master_secret" extension, it MUST 262 include the "extended_master_secret" extension in its ServerHello 263 message. 265 Implementation note: if the server decides to proceed with 266 resumption, the extension does not have any effect. Requiring the 267 extension to be included anyway makes the extension negotiation logic 268 easier, because it does not depend on whether resumption is accepted 269 or not. Moreover, a client may find useful to learn that the server 270 supports this extension anyway. 272 6. Security Considerations 274 This entire document is about security, see [TRIPLE-HS] for more 275 details. 277 7. Acknowdledgements 279 The triple handshake attacks were originally discovered by Antoine 280 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were 281 further developed by the miTLS team: Cedric Fournet, Pierre-Yves 282 Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the 283 ideas in this draft emerged from discussions with Martin Abadi, Ben 284 Laurie, Eric Rescorla, Martin Rex, Brian Smith. 286 8. References 288 8.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 294 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 296 8.2. Informative References 298 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 299 "Transport Layer Security (TLS) Renegotiation Indication 300 Extension", RFC 5746, February 2010. 302 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 303 Layer Security (TLS)", RFC 5705, March 2010. 305 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 306 for TLS", RFC 5929, July 2010. 308 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 309 Protocol Architecture", RFC 4251, January 2006. 311 [TRIPLE-HS] 312 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 313 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 314 Breaking and Fixing Authentication over TLS", IEEE 315 Symposium on Security and Privacy, to appear , 2014. 317 [sp800-108] 318 Chen, L., "NIST Special Publication 800-108: 319 Recommendation for Key Derivation Using Pseudorandom 320 Functions", Unpublished draft , 2009. 322 Authors' Addresses 324 Karthikeyan Bhargavan 325 Inria Paris-Rocquencourt 326 23, Avenue d'Italie 327 Paris 75214 CEDEX 13 328 France 330 Email: karthikeyan.bhargavan@inria.fr 331 Antoine Delignat-Lavaud 332 Inria Paris-Rocquencourt 333 23, Avenue d'Italie 334 Paris 75214 CEDEX 13 335 France 337 Email: antoine.delignat-lavaud@inria.fr 339 Alfredo Pironti 340 Inria Paris-Rocquencourt 341 23, Avenue d'Italie 342 Paris 75214 CEDEX 13 343 France 345 Email: alfredo.pironti@inria.fr 347 Adam Langley 348 Google Inc. 349 1600 Amphitheatre Parkway 350 Mountain View, CA 94043 351 USA 353 Email: agl@google.com 355 Marsh Ray 356 Microsoft Corp. 357 1 Microsoft Way 358 Redmond, WA 98052 359 USA 361 Email: maray@microsoft.com