idnits 2.17.1 draft-ietf-tls-renegotiation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 26, 2009) is 5263 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) == Missing Reference: 'REF' is mentioned on line 132, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-10) exists of draft-altman-tls-channel-bindings-07 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Standards Track M. Ray 5 Expires: May 30, 2010 S. Dispensa 6 PhoneFactor 7 N. Oskov 8 Microsoft 9 November 26, 2009 11 Transport Layer Security (TLS) Renegotiation Indication Extension 12 draft-ietf-tls-renegotiation-01.txt 14 Abstract 16 SSL and TLS renegotiation are vulnerable to an attack in which the 17 attacker forms a TLS connection with the target server, injects 18 content of his choice, and then splices in a new TLS connection from 19 a client. The server treats the client's initial TLS handshake as a 20 renegotiation and thus believes that the initial data transmitted by 21 the attacker is from the same entity as the subsequent client data. 22 This draft defines a TLS extension to cryptographically tie 23 renegotiations to the TLS connections they are being performed over, 24 thus preventing this attack. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on May 30, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Conventions Used In This Document . . . . . . . . . . . . . . . 4 80 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 81 4. Renegotiation Protection Request Cipher Suite . . . . . . . . . 5 82 5. Requirements for Sending and Receiving . . . . . . . . . . . . 5 83 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 84 6.1. Client Considerations . . . . . . . . . . . . . . . . . . . 6 85 6.2. Server Considerations . . . . . . . . . . . . . . . . . . . 6 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 94 1. Introduction 96 TLS [RFC5246] allows either the client or the server to initiate 97 renegotiation--a new handshake which establishes new cryptographic 98 parameters. Unfortunately, although the new handshake is carried out 99 over the protected channel established by the original handshake, 100 there is no cryptographic connection between the two. This creates 101 the opportunity for an attack in which the attacker who can intercept 102 a client's transport layer connection can inject traffic of his own 103 as a prefix to the client's interaction with the server. The attack 104 proceeds as shown below: 106 Client Attacker Server 107 ------ ------- ------ 108 <----------- Handshake ----------> 109 <======= Initial Traffic ========> 110 <-------------------------- Handshake ============================> 111 <======================== Client Traffic ==========================> 113 To start the attack, the attacker forms a TLS connection to the 114 server (perhaps in response to an initial intercepted connection from 115 the client). He then sends any traffic of his choice to the server. 116 This may involve multiple requests and responses at the application 117 layer, or may simply be a partial application layer request intended 118 to prefix the client's data. This traffic is shown with == to 119 indicate it is encrypted. He then allows the client's TLS handshake 120 to proceed with the server. The handshake is in the clear to the 121 attacker but encrypted over the attacker's channel to the server. 122 Once the handshake has completed, the client communicates with the 123 server over the new channel. The attacker cannot read this traffic, 124 but the server believes that the initial traffic to and from the 125 attacker is the same as that to and from the client. 127 If certificate-based client authentication is used, the server will 128 believe that the initial traffic corresponds to the authenticated 129 client identity. Even without certificate-based authentication, a 130 variety of attacks may be possible in which the attacker convinces 131 the server to accept data from it as data from the client. For 132 instance, if HTTPS [RFC2818] is in use with HTTP cookies [REF], the 133 attacker may be able to generate a request of his choice validated by 134 the client's cookie. 136 This attack can be prevented by cryptographically binding 137 renegotiation handshakes to the enclosing TLS channel, thus allowing 138 the server to differentiate renegotiation from initial negotiation, 139 as well as preventing renegotiations from being spliced in between 140 connections. An attempt by an attacker to inject himself as 141 described above will result in a mismatch of the extension and can 142 thus be detected This document defines an extension that performs 143 that cryptographic binding. The extension described here is similar 144 to that used for TLS Channel Bindings 145 [I-D.altman-tls-channel-bindings]. 147 2. Conventions Used In This Document 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 [RFC2119]. 153 3. Extension Definition 155 This document defines a new TLS extension: "renegotiation_info", 156 which contains a cryptographic binding to the enclosing TLS 157 connection (if any) for which the renegotiation is being performed. 158 The "extension data" field of this extension contains a 159 "Renegotiation_Info" structure: 161 struct { 162 opaque renegotiated_connection<0..255>; 163 } Renegotiation_Info; 165 The contents of this extension are specified as follows. 167 o If this is the initial handshake for a connection, then the 168 "renegotiated_connection" field is of zero length in both the 169 ClientHello and the ServerHello. Thus, the entire encoding of the 170 extension is: ff 01 00 01 00. The first two octets represent the 171 extension type, the third and fourth octet the length of the 172 extension itself, and the final octet the zero length byte for the 173 "renegotiated_connection" field. 174 o For ClientHellos which are renegotiating, this field contains the 175 verify_data from the Finished message sent by the client on the 176 immediately previous handshake. For current versions of TLS, this 177 will be a 12-byte value. Note that this value is the "tls-unique" 178 channel binding from [I-D.altman-tls-channel-bindings] 179 o For ServerHellos which are renegotiating, this field contains the 180 concatenation of the verify_data values sent by the client and the 181 server (in that order) on the immediately previous handshake. For 182 current versions of TLS, this will be a 24-byte value. 184 The above rules apply even when TLS resumption is used. 186 Upon receipt of the "renegotiation_info" extension, both client and 187 server implementations which support the extension MUST verify that 188 it contains the correct contents as specified above. If the contents 189 are incorrect, then it MUST generate a fatal "handshake_failure" 190 alert and terminate the connection. This allows two implementations 191 both of which support the extension to safely renegotiate without 192 fear of the above attack. 194 4. Renegotiation Protection Request Cipher Suite 196 Both the SSLv3 and TLS 1.0/TLS1.1 specifications require 197 implementations to ignore data following the ClientHello (i.e., 198 extensions) if they do not understand it. However, some SSLv3 and 199 TLS 1.0 implementations incorrectly fail the handshake in such case. 200 This means that clients which offer "renegotiation_info" may find 201 handshake failures. In order to enhance compatibility with such 202 servers, this document defines a second signalling mechanism via a 203 special TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST", with code 204 point 0xNN, 0xMM. This cipher suite has exactly the same semantics 205 as an empty "renegotiation_info" extension. Because servers 206 ordinarily ignore unknown cipher suites, this cipher suite can be 207 added safely on any initial handshake, including SSLv2 backward 208 compatibility handshakes. 210 Servers MUST treat receipt of TLS_RENEGO_PROTECTION_REQUEST exactly 211 as if the client had sent an empty "renegotiation_info" extension and 212 respond with their own "renegotiation_info" extension. This is an 213 explicit exception to the RFC 5246 Section 7.4.1.4 prohibition on the 214 server sending unsolicited extensions and is only allowed because the 215 client is signaling its willingness to receive the extension via the 216 the TLS_RENEGO_PROTECTION_REQUEST cipher suite. TLS implementations 217 MUST continue to comply with 7.4.1.4 for all other extensions. 218 Servers MUST NOT select this cipher suite in any handshake, as it 219 does not correspond to any valid set of algorithms. 221 Because this cipher suite is equivalent to an empty 222 "renegotiation_info" extension, only renegotiation_info" may be used 223 rehandshakes. 225 Note that a minimal client which does not support renegotiation at 226 all can simply use this cipher suite in all initial handshakes. Any 227 compliant server will reject any (apparent) attempt at renegotiation 228 by such a client. Clients which do support renegotiation MUST 229 implement Section 3 as well. 231 5. Requirements for Sending and Receiving 233 TLS clients which support this draft MUST generate either the 234 "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST 235 cipher suite with every ClientHello. 237 TLS servers which support this draft MUST generate the 238 "renegotiation_info" extension in the ServerHello in response to any 239 client which offers either "renegotiation_info" or 240 TLS_RENEGO_PROTECTION_REQUEST in the ClientHello. 242 6. Backward Compatibility 244 Existing implementations which do not support this extension are 245 widely deployed and in general must interoperate with newer 246 implementations which do support it. This section describes 247 considerations for backward compatible interoperation. 249 6.1. Client Considerations 251 If a client offers the "renegotiation_info" extension or the 252 TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not 253 reply with "renegotiation_info" in the ServerHello, then this 254 indicates that the server either does not support secure 255 renegotiation or is unwilling to use it. Because the above attack 256 looks like a single handshake to the client, the client cannot 257 determine whether the connection is under attack or not. Note, 258 however, that merely because the server does not acknowledge the 259 extension does not mean that it is vulnerable; it might choose to 260 reject all rehandshakes and simply not signal it. However, it is not 261 possible for the client to determine purely via TLS mechanisms 262 whether this is the case or not. 264 If clients wish to ensure that such attacks are impossible, they MUST 265 terminate the connection immediately upon failure to receive the 266 extension without completing the handshake. However, it is expected 267 that many TLS servers that do not support renegotiation (and thus are 268 not vulnerable) will not support this extension either, so in 269 general, such behavior would not work well. 271 6.2. Server Considerations 273 If the client does not offer the "renegotiation_info" extension or 274 the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this indicates 275 that the client does not support secure renegotiation or is unwilling 276 to use it. However, because the above attack looks like two 277 handshakes to the server, the server can safely continue the 278 connection as long as it does not allow the client to rehandshake. 279 If servers wish to ensure that such attacks are impossible they MUST 280 NOT allow clients who do not offer the "renegotiation_info" extension 281 to renegotiate with them and SHOULD respond to such requests with a 282 "no_renegotiation" alert [RFC 5246 requires this alert to be at the 283 "warning" level.] Servers SHOULD follow this behavior. 285 In order to enable clients to probe, even servers which do not 286 support renegotiation SHOULD implement the minimal version of the 287 extension described in this document for initial handshakes, thus 288 signalling that they have been upgraded. 290 7. Security Considerations 292 The extension described in this document prevents an attack on TLS. 293 If this extension is not used, TLS renegotiation is subject to an 294 attack in which the attacker can inject their own conversation with 295 the TLS server as a prefix of the client's conversation. This attack 296 is invisible to the client and looks like an ordinary renegotiation 297 to the server. The extension defined in this document allows 298 renegotiation to be performed safely. Servers SHOULD NOT allow 299 clients to renegotiate without using this extension. 301 While this extension mitigates the man-in-the-middle attack described 302 in the overview, it does not resolve all possible problems an 303 application may face if it is unaware of renegotiation. It is 304 possible that the authenticated identity of the server or client may 305 change as a result of renegotiation. 307 By default, TLS implementations conforming to this document MUST 308 verify that once the peer has been identified and authenticated 309 within the TLS handshake, the identity does not change on subsequent 310 renegotiations. For certificate based cipher suites, this means 311 bitwise equality of the end-entity certificate. If the other end 312 attempts to authenticate with a different identity, the renegotiation 313 MUST fail. If the server_name extension is used, it MUST NOT change 314 when doing renegotiation. 316 A TLS library MAY provide a means for the application to allow 317 identity and/or server_name changes across renegotiations, in which 318 case the application is responsible for tracking the identity 319 associated with data it is processing. This may require additional 320 API facilities in the TLS library. 322 8. IANA Considerations 324 IANA [shall add/has added] the extension code point XXX [We request 325 0xff01, which has been used for prototype implementations] for the 326 "renegotiation_info" extension to the TLS ExtensionType values 327 registry. 329 IANA [shall add/has added] TLS cipher suite number 0xNN,0xMM with 330 name TLS_RENEGO_PROTECTION_REQUEST to the TLS Cipher Suite registry. 332 9. Acknowledgements 334 This vulnerability was originally discovered by Marsh Ray. The 335 general concept behind the extension described here was independently 336 invented by Steve Dispensa, Nasko Oskov, and Eric Rescorla with 337 refinements from Nelson Bolyard, Pasi Eronen, Mike D'Errico, Bodo 338 Moeller, Martin Rex (who defined TLS_RENEGO_PROTECTION_REQUEST), 339 Jesse Walker, Nico Williams and other members of the the Project 340 Mogul team and the TLS WG. [Note: if you think your name should be 341 here, please speak up.] 343 10. References 345 10.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 351 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 353 10.2. Informative References 355 [I-D.altman-tls-channel-bindings] 356 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 357 for TLS", draft-altman-tls-channel-bindings-07 (work in 358 progress), October 2009. 360 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 362 Authors' Addresses 364 Eric Rescorla 365 RTFM, Inc. 366 2064 Edgewood Drive 367 Palo Alto, CA 94303 368 USA 370 Email: ekr@rtfm.com 371 Marsh Ray 372 PhoneFactor 373 7301 W 129th Street 374 Overland Park, KS 66213 375 USA 377 Email: marsh@extendedsubset.com 379 Steve Dispensa 380 PhoneFactor 381 7301 W 129th Street 382 Overland Park, KS 66213 383 USA 385 Email: dispensa@phonefactor.com 387 Nasko Oskov 388 Microsoft 389 One Microsoft Way 390 Redmond, WA 98052 391 USA 393 Email: nasko.oskov@microsoft.com