idnits 2.17.00 (12 Aug 2021) /tmp/idnits23013/draft-ietf-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 : ---------------------------------------------------------------------------- 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 (August 22, 2014) is 2828 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. -------------------------------------------------------------------------------- 1 Network Working Group K. Bhargavan 2 Internet-Draft A. Delignat-Lavaud 3 Expires: February 23, 2015 A. Pironti 4 Inria Paris-Rocquencourt 5 A. Langley 6 Google Inc. 7 M. Ray 8 Microsoft Corp. 9 August 22, 2014 11 Transport Layer Security (TLS) Session Hash and 12 Extended Master Secret Extension 13 draft-ietf-tls-session-hash-01 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 session resumption, becomes vulnerable 24 to a man-in-the-middle attack, where the attacker can simply forward 25 messages back and forth between the client and server. This 26 specification defines a TLS extension that contextually binds the 27 master secret to a log of the full handshake that computes it, thus 28 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 23, 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 9.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 own 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 connections (between C and A, and between A and 123 S) 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 curve. 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 occurrences 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 themselves, these attacks do 147 not break integrity or confidentiality between honest parties, but 148 they 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. IANA Considerations 279 IANA is requested to assign an extension code point for the 280 extended_master_secret extension to the TLS ExtensionType values 281 registry as specified in TLS [RFC5246]. 283 8. Acknowledgments 285 The triple handshake attacks were originally discovered by Antoine 286 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were 287 further developed by the miTLS team: Cedric Fournet, Pierre-Yves 288 Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the 289 ideas in this draft emerged from discussions with Martin Abadi, Ben 290 Laurie, Eric Rescorla, Martin Rex, Brian Smith. 292 9. References 294 9.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 300 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 302 9.2. Informative References 304 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 305 "Transport Layer Security (TLS) Renegotiation Indication 306 Extension", RFC 5746, February 2010. 308 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 309 Layer Security (TLS)", RFC 5705, March 2010. 311 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 312 for TLS", RFC 5929, July 2010. 314 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 315 Protocol Architecture", RFC 4251, January 2006. 317 [TRIPLE-HS] 318 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 319 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 320 Breaking and Fixing Authentication over TLS", IEEE 321 Symposium on Security and Privacy, pages 98-113 , 2014. 323 [sp800-108] 324 Chen, L., "NIST Special Publication 800-108: 325 Recommendation for Key Derivation Using Pseudorandom 326 Functions", Unpublished draft , 2009. 328 Authors' Addresses 330 Karthikeyan Bhargavan 331 Inria Paris-Rocquencourt 332 23, Avenue d'Italie 333 Paris 75214 CEDEX 13 334 France 336 Email: karthikeyan.bhargavan@inria.fr 338 Antoine Delignat-Lavaud 339 Inria Paris-Rocquencourt 340 23, Avenue d'Italie 341 Paris 75214 CEDEX 13 342 France 344 Email: antoine.delignat-lavaud@inria.fr 346 Alfredo Pironti 347 Inria Paris-Rocquencourt 348 23, Avenue d'Italie 349 Paris 75214 CEDEX 13 350 France 352 Email: alfredo.pironti@inria.fr 354 Adam Langley 355 Google Inc. 356 1600 Amphitheatre Parkway 357 Mountain View, CA 94043 358 USA 360 Email: agl@google.com 362 Marsh Ray 363 Microsoft Corp. 364 1 Microsoft Way 365 Redmond, WA 98052 366 USA 368 Email: maray@microsoft.com