idnits 2.17.1 draft-rescorla-tls-renegotiation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- 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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == 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 17, 2009) is 5273 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 125, but not defined == Missing Reference: 'TBD' is mentioned on line 278, 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 (~~), 6 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 21, 2010 S. Dispensa 6 PhoneFactor 7 N. Oskov 8 Microsoft 9 November 17, 2009 11 Transport Layer Security (TLS) Renegotiation Indication Extension 12 draft-rescorla-tls-renegotiation-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on May 21, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 SSL and TLS renegotiation are vulnerable to an attack in which the 60 attacker forms a TLS connection with the target server, injects 61 content of his choice, and then splices in a new TLS connection from 62 a client. The server treats the client's initial TLS handshake as a 63 renegotiation and thus believes that the initial data transmitted by 64 the attacker is from the same entity as the subsequent client data. 65 This draft defines a TLS extension to cryptographically tie 66 renegotiations to the TLS connections they are being performed over, 67 thus preventing this attack. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Conventions Used In This Document . . . . . . . . . . . . . . . 5 73 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 74 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 75 4.1. Client Considerations . . . . . . . . . . . . . . . . . . . 6 76 4.2. Server Considerations . . . . . . . . . . . . . . . . . . . 7 77 4.3. SSLv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.3.1. Fallback Cipher Suite Signaling . . . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 TLS [RFC5246] allows either the client or the server to initiate 90 renegotiation--a new handshake which establishes new cryptographic 91 parameters. Unfortunately, although the new handshake is carried out 92 over the protected channel established by the original handshake, 93 there is no cryptographic connection between the two. This creates 94 the opportunity for an attack in which the attacker who can intercept 95 a client's transport layer connection can inject traffic of his own 96 as a prefix to the client's interaction with the server. The attack 97 proceeds as shown below: 99 Client Attacker Server 100 ------ ------- ------ 101 <----------- Handshake ----------> 102 <======= Initial Traffic ========> 103 <-------------------------- Handshake ============================> 104 <======================== Client Traffic ==========================> 106 To start the attack, the attacker forms a TLS connection to the 107 server (perhaps in response to an initial intercepted connection from 108 the client). He then sends any traffic of his choice to the server. 109 This may involve multiple requests and responses at the application 110 layer, or may simply be a partial application layer request intended 111 to prefix the client's data. This traffic is shown with == to 112 indicate it is encrypted. He then allows the client's TLS handshake 113 to proceed with the server. The handshake is in the clear to the 114 attacker but encrypted over the attacker's channel to the server. 115 Once the handshake has completed, the client communicates with the 116 server over the new channel. The attacker cannot read this traffic, 117 but the server believes that the initial traffic to and from the 118 attacker is the same as that to and from the client. 120 If certificate-based client authentication is used, the server will 121 believe that the initial traffic corresponds to the authenticated 122 client identity. Even without certificate-based authentication, a 123 variety of attacks may be possible in which the attacker convinces 124 the server to accept data from it as data from the client. For 125 instance, if HTTPS [RFC2818] is in use with HTTP cookies [REF], the 126 attacker may be able to generate a request of his choice validated by 127 the client's cookie. 129 This attack can be prevented by cryptographically binding 130 renegotiation handshakes to the enclosing TLS channel, thus allowing 131 the server to differentiate renegotiation from initial negotiation, 132 as well as preventing renegotiations from being spliced in between 133 connections. An attempt by an attacker to inject himself as 134 described above will result in a mismatch of the extension and can 135 thus be detected This document defines an extension that performs 136 that cryptographic binding. The extension described here is similar 137 to that used for TLS Channel Bindings 138 [I-D.altman-tls-channel-bindings]. 140 2. Conventions Used In This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Extension Definition 148 This document defines a new TLS extension: "renegotiation_info", 149 which contains a cryptographic binding to the enclosing TLS 150 connection (if any) for which the renegotiation is being performed. 151 The "extension data" field of this extension contains a 152 "Renegotiation_Info" structure: 154 struct { 155 opaque renegotiated_connection<0..255>; 156 } Renegotiation_Info; 158 All TLS implementations SHOULD support this extension. TLS clients 159 SHOULD generate it with every handshake and TLS servers SHOULD 160 generate it in response to any client which offers it. 162 The contents of this extension are specified as follows. 164 o If this is the initial handshake for a connection, then the 165 "renegotiated_connection" field is of zero length in both the 166 ClientHello and the ServerHello. Thus, the entire encoding of the 167 extension is: ff 01 00 01 00. The first two octets represent the 168 extension type, the third and fourth octet the length of the 169 extension itself, and the final octet the zero length byte for the 170 "renegotiated_connection" field. 171 o For ClientHellos which are renegotiating, this field contains the 172 verify_data from the Finished message sent by the client on the 173 immediately previous handshake. For current versions of TLS, this 174 will be a 12-byte value. Note that this value is the "tls-unique" 175 channel binding from [I-D.altman-tls-channel-bindings] 176 o For ServerHellos which are renegotiating, this field contains the 177 concatenation of the verify_data values sent by the client and the 178 server (in that order) on the immediately previous handshake. For 179 current versions of TLS, this will be a 24-byte value. 181 The above rules apply even when TLS resumption is used. 183 Upon receipt of the "renegotiation_info" extension, implementations 184 which support the extension MUST verify that it contains the correct 185 contents as specified above. If the contents are incorrect, then it 186 MUST generate a fatal "handshake_failure" alert and terminate the 187 connection. This allows two implementations both of which support 188 the extension to safely renegotiate without fear of the above attack. 190 4. Backward Compatibility 192 Existing implementations which do not support this extension are 193 widely deployed and in general must interoperate with newer 194 implementations which do support it. This section describes 195 considerations for backward compatible interoperation. [[ OPEN ISSUE: 196 The normative strength of these recommendations needs to be 197 discussed.]] 199 4.1. Client Considerations 201 If a client offers the "renegotiation_info" extension and the server 202 does not respond, then this indicates that the server either does not 203 support the extension or is unwilling to use it. Because the above 204 attack looks like a single handshake to the client, the client cannot 205 determine whether the connection is under attack or not. Note, 206 however, that merely because the server does not acknowledge the 207 extension does not mean that it is vulnerable; it might choose to 208 reject all rehandshakes. However, it is not possible for the client 209 to determine purely via TLS mechanisms whether this is the case or 210 not. 212 If clients wish to ensure that such attacks are impossible, they MUST 213 terminate the connection immediately upon failure to receive the 214 extension without completing the handshake. Otherwise, they may be 215 performing client authentication and thus potentially authorizing the 216 data already sent by the attacker even if the client itself sends no 217 data. Note that initially deployment of this extension will be very 218 sparse and thus choosing to terminate the connection immediately is 219 likely to result in significant interoperability problems. 221 While this specification does not require the client to send RI on 222 initial handshakes, clients which choose not to do so have no 223 mechanism for determining whether the server is operating in a 224 vulnerable mode (and provide no such indication to the server) and 225 are therefore relying entirely on the server refusing to renegotiate 226 in the absence of the extension as opposed to explicitly indicating 227 to the server that the initial handshake is in fact the first one on 228 the connection. 230 4.2. Server Considerations 232 If the client does not offer the "renegotiation_info" extension, then 233 this indicates that the client does not support the extension or is 234 unwilling to use it. Note that TLS does not permit servers to offer 235 unsolicited extensions. However, because the above attack looks like 236 two handshakes to the server, the server can safely continue the 237 connection as long as it does not allow the client to rehandshake. 238 If servers wish to ensure that such attacks are impossible they MUST 239 NOT allow clients who do not offer the "renegotiation_info" extension 240 to renegotiate with them and SHOULD respond to such requests with a 241 "no_renegotiation" alert [RFC 5246 requires this alert to be at the 242 "warning" level.] Servers SHOULD follow this behavior. 244 4.3. SSLv3 246 SSLv3 does not support extensions and thus it is not possible to 247 securely renegotiate with SSLv3. Deployments wishing to renegotiate 248 securely will need to upgrade to at least TLS 1.0. Although the 249 later drafts of SSLv3 require implementations to ignore data 250 following the ClientHello (i.e., extensions), some SSLv3 server 251 implementations incorrectly fail the handshake. TLS implementations 252 which offer extensions sometimes will respond to such failures by 253 falling back to an extensionless mode. This practice can be 254 exploited by a MITM to cause a client which would ordinarily offer 255 the renegotiation extension not to do so. Note that this 256 consideration does not apply to implementations which ignore 257 extensions since the ordinarily TLS Finished messages protect that 258 negotiation. 260 When combined with a server which allows renegotiation without the 261 extension (which, per Section 5, is NOT RECOMMENDED) this allows a 262 downgrade attack. Accordingly, clients which offer this extension 263 SHOULD NOT fall back to extensionless modes upon handshake errors. 264 Any SSLv3 or TLS implementation which chooses to address this issue 265 by refusing to renegotiate at all MUST at minimum ensure that the 266 extension is ignored (this is simply a restatement of existing 267 requirements). Thus, any such handshake failure can be assumed to 268 represent either an attack or a vulnerable server; in either case the 269 best practice is not to continue the connection. Even servers which 270 refuse to renegotiate SHOULD reply with an empty RI extension because 271 this signals that they have been upgraded. 273 4.3.1. Fallback Cipher Suite Signaling 275 [[OPEN ISSUE: Should this feature be added?]] 277 Clients which choose to fall back to an extensionless mode of 278 operation MUST include the magic cipher suite [TBD] in any such 279 handshake. Servers MUST reject any ClientHello which uses this 280 cipher suite but does not include RI with a fatal "handshake_failure" 281 alert. Because servers ordinarily ignore unknown cipher suites, this 282 cipher suite can be added safely on any handshake, thus allowing 283 detection and prevention of the MITM attack described above. Servers 284 MUST NOT select this cipher suite in any handshake, as it does not 285 correspond to any valid cipher suite. 287 5. Security Considerations 289 The extension described in this document prevents an attack on TLS. 290 If this extension is not used, TLS renegotiation is subject to an 291 attack in which the attacker can inject their own conversation with 292 the TLS server as a prefix of the client's conversation. This attack 293 is invisible to the client and looks like an ordinary renegotiation 294 to the server. The extension defined in this document allows 295 renegotiation to be performed safely. Servers SHOULD NOT allow 296 clients to renegotiate without using this extension. 298 While this extension mitigates the man-in-the-middle attack described 299 in the overview, it does not resolve all possible problems an 300 application may face if it is unaware of negotiation. It is possible 301 that the authenticated identity of the server or client may change as 302 a result of renegotiation. By default TLS implementations SHOULD 303 verify that once an identity has been authenticated within the TLS 304 handshake that it does not change on subsequent renegotiations. If 305 the identity changes the renegotiation should fail. A TLS library 306 MAY provide a means for the application to allow identity change 307 across renegotiations, in which case the application is responsible 308 for tracking the identity associated with data it is processing. 309 This may require additional API facilities in the TLS library. 311 6. IANA Considerations 313 IANA [shall add/has added] the extension code point XXX [We request 314 0xff01, which has been used for prototype implementations] for the 315 "renegotiation_info" extension to the TLS ExtensionType values 316 registry. 318 7. Acknowledgements 320 This vulnerability was originally discovered by Marsh Ray. The 321 general concept behind the extension described here was independently 322 invented by Steve Dispensa, Nasko Oskov, and Eric Rescorla. Comments 323 and refinements were received from Jesse Walker and the rest of the 324 Project Mogul team. 326 8. References 328 8.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 334 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 336 8.2. Informative References 338 [I-D.altman-tls-channel-bindings] 339 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 340 for TLS", draft-altman-tls-channel-bindings-07 (work in 341 progress), October 2009. 343 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 345 Authors' Addresses 347 Eric Rescorla 348 RTFM, Inc. 349 2064 Edgewood Drive 350 Palo Alto, CA 94303 351 USA 353 Email: ekr@rtfm.com 355 Marsh Ray 356 PhoneFactor 357 7301 W 129th Street 358 Overland Park, KS 66213 359 USA 361 Email: marsh@extendedsubset.com 362 Steve Dispensa 363 PhoneFactor 364 7301 W 129th Street 365 Overland Park, KS 66213 366 USA 368 Email: dispensa@phonefactor.com 370 Nasko 371 Microsoft 372 One Microsoft Way 373 Redmond, WA 98052 374 USA 376 Email: nasko.oskov@microsoft.com