idnits 2.17.00 (12 Aug 2021) /tmp/idnits21674/draft-ietf-tls-session-hash-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2014) is 2783 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: 1 error (**), 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: April 9, 2015 A. Pironti 5 Inria Paris-Rocquencourt 6 A. Langley 7 Google Inc. 8 M. Ray 9 Microsoft Corp. 10 October 6, 2014 12 Transport Layer Security (TLS) Session Hash and 13 Extended Master Secret Extension 14 draft-ietf-tls-session-hash-02 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 session resumption, becomes vulnerable 25 to a man-in-the-middle attack, where the attacker can simply forward 26 messages back and forth between the client and server. This 27 specification defines a TLS extension that contextually binds the 28 master secret to a log of the full handshake that computes it, thus 29 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 April 9, 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 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2. SSL 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Extension negotiation . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Extension definition . . . . . . . . . . . . . . . . . . 6 73 5.2. Client and Server Behavior . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 9.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 In TLS [RFC5246], every session has a "master_secret" computed as: 86 master_secret = PRF(pre_master_secret, "master secret", 87 ClientHello.random + ServerHello.random) 88 [0..47]; 90 where the "pre_master_secret" is the result of some key exchange 91 protocol. For example, when the handshake uses an RSA ciphersuite, 92 this value is generated uniformly at random by the client, whereas 93 for DHE ciphersuites, it is the result of a Diffie-Hellman key 94 agreement. 96 As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, 97 an active attacker can synchronize two TLS sessions so that they 98 share the same "master_secret". For an RSA key exchange where the 99 client is unauthenticated, this is achieved as follows. Suppose a 100 client, C, connects to a malicious server, A. A then connects to a 101 server, S, and completes both handshakes. For simplicity, assume 102 that C and S only use RSA ciphersuites. (Note that C thinks it is 103 connecting to A and is oblivious of S's involvement.) 105 1. C sends a "ClientHello" to A, and A forwards it to S. 107 2. S sends a "ServerHello" to A, and A forwards it to C. 109 3. S sends a "Certificate", containing its certificate chain, to A. 110 A replaces it with its own certificate chain and sends it to C. 112 4. S sends a "ServerHelloDone" to A, and A forwards it to C. 114 5. C sends a "ClientKeyExchange" to A, containing the 115 "pre_master_secret", encrypted with A's public key. A decrypts 116 the "pre_master_secret", re-encrypts it with S's public key and 117 sends it on to S. 119 6. C sends a "Finished" to A. A computes a "Finished" for its 120 connection with S, and sends it to S. 122 7. S sends a "Finished" to A. A computes a "Finished" for its 123 connection with C, and sends it to C. 125 At this point, both connections (between C and A, and between A and 126 S) have new sessions that share the same "pre_master_secret", 127 "ClientHello.random", "ServerHello.random", as well as other session 128 parameters, including the session identifier and, optionally, the 129 session ticket. Hence, the "master_secret" value will be equal for 130 the two sessions and it will be associated both at C and S with the 131 same session ID, even though the server identities on the two 132 connections are different. Moreover, the record keys on the two 133 connections will also be the same. 135 Similar scenarios can be achieved when the handshake uses a DHE 136 ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit 137 curve. Even if the client or server does not prefer using RSA or 138 DHE, the attacker can force them to use it by offering only RSA or 139 DHE in its hello messages. Other key exchanges may also be 140 vulnerable. If client authentication is used, the attack still 141 works, except that the two sessions now differ on both client and 142 server identities. 144 Once A has synchronized the two connections, since the keys are the 145 same on the two sides, it can step away and transparently forward 146 messages between C and S, reading and modifying when it desires. In 147 the key exchange literature, such occurrences are called unknown key- 148 share attacks, since C and S share a secret but they both think that 149 their secret is shared only with A. In themselves, these attacks do 150 not break integrity or confidentiality between honest parties, but 151 they offer a useful starting point from which to mount impersonation 152 attacks on C and S. 154 Suppose C tries to resume its session on a new connection with A. A 155 can then resume its session with S on a new connection and forward 156 the abbreviated handshake messages unchanged between C and S. Since 157 the abbreviated handshake only relies on the master secret for 158 authentication, and does not mention client or server identities, 159 both handshakes complete successfully, resulting in the same session 160 keys and the same handshake log. A still knows the connection keys 161 and can send messages to both C and S. 163 Critically, on the new connection, even the handshake log is the same 164 on C and S, thus defeating any man-in-the-middle protection scheme 165 that relies on the uniqueness of finished messages, such as the 166 secure renegotiation indication extension [RFC5746] or TLS channel 167 bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on 168 such session synchronization attacks. In particular, it describes a 169 man-in-the-middle attack that circumvents the protections of 170 [RFC5746] to break client-authenticated TLS renegotiation after 171 session resumption. Similar attacks apply to application-level 172 authentication mechanisms that rely on channel bindings [RFC5929] or 173 on key material exported from TLS [RFC5705]. 175 The underlying protocol issue is that since the master secret is not 176 guaranteed to be unique across sessions, it cannot be used on its own 177 as an authentication credential. This specification introduces a TLS 178 extension that computes the "master_secret" value from the log of the 179 handshake that computes it, so that different handshakes will, by 180 construction, create different master secrets. 182 2. Requirements Notation 184 This document uses the same notation and terminology used in the TLS 185 Protocol specification [RFC5246]. 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [RFC2119]. 191 3. The TLS Session Hash 193 When a full handshake takes place, we define 195 session_hash = Hash(handshake_messages) 197 where "handshake_messages" refers to all handshake messages sent or 198 received, starting at client hello up to and including the Client Key 199 Exchange message, including the type and length fields of the 200 handshake messages. This is the concatenation of all the exchanged 201 Handshake structures, as defined in Section 7.4 of [RFC5246]. 203 The hash function "Hash" is defined by the ciphersuite in TLS 1.2. 204 In all previous versions of TLS and in SSL 3.0, this function 205 computes the concatenation of MD5 and SHA1. 207 There is no "session_hash" for resumed handshakes, as they do not 208 lead to the creation of a new session. 210 Implementation note: As described in Section 4, the "session_hash" is 211 used in the extended master secret computation. Hence, it must be 212 possible to compute the session_hash before the master secret is 213 computed. In SSL 3.0, the master secret is first needed in the 214 Client's CertificateVerify message. Hence, it is widespread 215 implementation practice to compute the master secret as soon as the 216 "pre_master_secret" is available, typically immediately before or 217 after sending the Client Key Exchange message. The definition of 218 "session_hash" given in this document requires minimal patches to 219 such implementations in order to implement the extended master secret 220 extension. Our definition is also compatible with the common 221 implementation practice of keeping running hashes of the handshake 222 log. 224 4. The extended master secret 226 4.1. TLS 228 When the extended master secret extension is negotiated in a TLS 229 session, the "master_secret" is computed as 231 master_secret = PRF(pre_master_secret, "extended master secret", 232 session_hash) 233 [0..47]; 235 The extended master secret computation differs from the [RFC5246] in 236 the following ways: 238 o The "extended master secret" label is used instead of "master 239 secret"; 241 o The "session_hash" is used instead of the "ClientHello.random" and 242 "ServerHello.random". 244 The "session_hash" depends upon a handshake log that includes 245 "ClientHello.random" and "ServerHello.random", in addition to 246 ciphersuites, client and server certificates. Consequently, the 247 extended master secret depends upon the choice of all these session 248 parameters. 250 Our proposed design reflects the recommendation that keys should be 251 bound to the security contexts that compute them [sp800-108]. The 252 technique of mixing a hash of the key exchange messages into master 253 key derivation is already used in other well-known protocols such as 254 SSH [RFC4251]. 256 4.2. SSL 3.0 258 SSL 3.0 does not defne a PRF function, instead it defines a custom 259 algorithm to compute the master secret. When the extended master 260 secret extension is negotiated in SSL 3.0, the master secret is 261 computed as 263 master_secret = 264 MD5(pre_master_secret + SHA('A' + pre_master_secret + 265 session_hash)) + 266 MD5(pre_master_secret + SHA('BB' + pre_master_secret + 267 session_hash)) + 268 MD5(pre_master_secret + SHA('CCC' + pre_master_secret + 269 session_hash)); 271 That is, the "session_hash" replaces the concatenation of 272 "ClientHello.random" and "ServerHello.random". 274 5. Extension negotiation 276 5.1. Extension definition 278 This document defines a new TLS extension, "extended_master_secret" 279 (with extension type 0x0017), which is used to signal both client and 280 server to use the extended master secret computation. The 281 "extension_data" field of this extension is empty. Thus, the entire 282 encoding of the extension is 00 17 00 00. 284 If client and server agree on this extension and a full handshake 285 takes place, both client and server MUST use the extended master 286 secret derivation algorithm, as defined in Section 4. 288 5.2. Client and Server Behavior 290 In its ClientHello message, a client implementing this document MUST 291 send the "extended_master_secret" extension. 293 If a server receives the "extended_master_secret" extension, it MUST 294 include the "extended_master_secret" extension in its ServerHello 295 message. 297 Implementation note: if the server decides to proceed with 298 resumption, the extension does not have any effect. Requiring the 299 extension to be included anyway makes the extension negotiation logic 300 easier, because it does not depend on whether resumption is accepted 301 or not. Moreover, a client may find useful to learn that the server 302 supports this extension anyway. 304 6. Security Considerations 306 This entire document is about security, see [TRIPLE-HS] for more 307 details. 309 7. IANA Considerations 311 IANA has added the extension code point 23 (0x0017), which has been 312 used for prototype implementations, for the "extended_master_secret" 313 extension to the TLS ExtensionType values registry as specified in 314 TLS [RFC5246]. 316 8. Acknowledgments 318 The triple handshake attacks were originally discovered by Antoine 319 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were 320 further developed by the miTLS team: Cedric Fournet, Pierre-Yves 321 Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the 322 ideas in this draft emerged from discussions with Martin Abadi, Ben 323 Laurie, Eric Rescorla, Martin Rex, Brian Smith. 325 9. References 327 9.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 333 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 335 9.2. Informative References 337 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 338 "Transport Layer Security (TLS) Renegotiation Indication 339 Extension", RFC 5746, February 2010. 341 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 342 Layer Security (TLS)", RFC 5705, March 2010. 344 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 345 for TLS", RFC 5929, July 2010. 347 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 348 Protocol Architecture", RFC 4251, January 2006. 350 [TRIPLE-HS] 351 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 352 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 353 Breaking and Fixing Authentication over TLS", IEEE 354 Symposium on Security and Privacy, pages 98-113 , 2014. 356 [sp800-108] 357 Chen, L., "NIST Special Publication 800-108: 358 Recommendation for Key Derivation Using Pseudorandom 359 Functions", Unpublished draft , 2009. 361 Authors' Addresses 363 Karthikeyan Bhargavan 364 Inria Paris-Rocquencourt 365 23, Avenue d'Italie 366 Paris 75214 CEDEX 13 367 France 369 Email: karthikeyan.bhargavan@inria.fr 371 Antoine Delignat-Lavaud 372 Inria Paris-Rocquencourt 373 23, Avenue d'Italie 374 Paris 75214 CEDEX 13 375 France 377 Email: antoine.delignat-lavaud@inria.fr 378 Alfredo Pironti 379 Inria Paris-Rocquencourt 380 23, Avenue d'Italie 381 Paris 75214 CEDEX 13 382 France 384 Email: alfredo.pironti@inria.fr 386 Adam Langley 387 Google Inc. 388 1600 Amphitheatre Parkway 389 Mountain View, CA 94043 390 USA 392 Email: agl@google.com 394 Marsh Ray 395 Microsoft Corp. 396 1 Microsoft Way 397 Redmond, WA 98052 398 USA 400 Email: maray@microsoft.com