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