idnits 2.17.1 draft-ietf-tls-renegotiation-03.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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4347, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4366, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC4347, updated by this document, for RFC5378 checks: 2004-01-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 04, 2010) is 5188 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) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) == 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) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 Updates: RFCs 5246, 4366, 4347, M. Ray 5 4346, 2246 (if approved) S. Dispensa 6 Intended status: Standards Track PhoneFactor 7 Expires: July 8, 2010 N. Oskov 8 Microsoft 9 Jan 04, 2010 11 Transport Layer Security (TLS) Renegotiation Indication Extension 12 draft-ietf-tls-renegotiation-03.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 specification 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 July 8, 2010. 49 Copyright Notice 51 Copyright (c) 2010 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 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 68 3. Secure Renegotiation Definition . . . . . . . . . . . . . . . 4 69 3.1. Additional Connection State . . . . . . . . . . . . . . . 4 70 3.2. Extension Definition . . . . . . . . . . . . . . . . . . . 5 71 3.3. Renegotiation Protection Request Signalling Cipher 72 Suite Value . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.4. Client Behavior: Initial Handshake . . . . . . . . . . . . 6 74 3.5. Client Behavior: Secure Renegotiation . . . . . . . . . . 7 75 3.6. Server Behavior: Initial Handshake . . . . . . . . . . . . 7 76 3.7. Server Behavior: Secure Renegotiation . . . . . . . . . . 8 77 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 78 4.1. Client Considerations . . . . . . . . . . . . . . . . . . 8 79 4.2. Client Behavior: Legacy (Insecure) Renegotation . . . . . 9 80 4.3. Server Considerations . . . . . . . . . . . . . . . . . . 10 81 4.4. Server Behavior: Legacy (Insecure) Renegotiation . . . . . 10 82 4.5. SSLv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 TLS [RFC5246] allows either the client or the server to initiate 94 renegotiation--a new handshake which establishes new cryptographic 95 parameters. Unfortunately, although the new handshake is carried out 96 using the cryptographic parameters established by the original 97 handshake, there is no cryptographic binding between the two. This 98 creates the opportunity for an attack in which the attacker who can 99 intercept a client's transport layer connection can inject traffic of 100 his own as a prefix to the client's interaction with the server. The 101 attack [Ray09] proceeds as shown below: 103 Client Attacker Server 104 ------ ------- ------ 105 <----------- Handshake ----------> 106 <======= Initial Traffic ========> 107 <-------------------------- Handshake ============================> 108 <======================== Client Traffic ==========================> 110 To start the attack, the attacker forms a TLS connection to the 111 server (perhaps in response to an initial intercepted connection from 112 the client). He then sends any traffic of his choice to the server. 113 This may involve multiple requests and responses at the application 114 layer, or may simply be a partial application layer request intended 115 to prefix the client's data. This traffic is shown with == to 116 indicate it is encrypted. He then allows the client's TLS handshake 117 to proceed with the server. The handshake is in the clear to the 118 attacker but encrypted over the attacker's TLS connection to the 119 server. Once the handshake has completed, the client communicates 120 with the server over the newly established security parameters with 121 the server. The attacker cannot read this traffic, but the server 122 believes that the initial traffic to and from the attacker is the 123 same as that to and from the client. 125 If certificate-based client authentication is used, the server will 126 see a stream of bytes where the initial bytes are protected but 127 unauthenticated by TLS and subsequent bytes are authenticated by TLS 128 and bound to the client's certificate. In some protocols (notably 129 HTTPS), no distinction is made between pre- and post-authentication 130 stages and the bytes are handled uniformly, resulting in the server 131 believing that the initial traffic corresponds to the authenticated 132 client identity. Even without certificate-based authentication, a 133 variety of attacks may be possible in which the attacker convinces 134 the server to accept data from it as data from the client. For 135 instance, if HTTPS [RFC2818] is in use with HTTP cookies [RFC2965] 136 the attacker may be able to generate a request of his choice 137 validated by the client's cookie. 139 Some protocols--such as IMAP or SMTP--have more explicit transitions 140 between authenticated and unauthenticated phases and require that the 141 protocol state machine be partly or fully reset at such transitions. 142 If strictly followed, these rules may limit the effect of attacks. 143 Unfortunately, there is no requirement for state machine resets at 144 TLS renegotiation and thus there is still a potential window of 145 vulnerability, for instance by prefixing a command which writes to an 146 area visible by the attacker with a command by the client that 147 includes his password, thus making the client's password visible to 148 the attacker (note that this precise attack does not work with 149 challenge-response authentication schemes but other attacks may be 150 possible). Similar attacks are available with SMTP and in fact do 151 not necessarily require the attacker to have an account on the target 152 server. 154 It is important to note that in both cases these attacks are possible 155 because the client sends unsolicited authentication information 156 without requiring any specific data from the server over the TLS 157 connection. Protocols which require a round trip to the server over 158 TLS before the client sends sensitive information are likely to be 159 less vulnerable. 161 These attacks can be prevented by cryptographically binding 162 renegotiation handshakes to the enclosing TLS cryptographic 163 parameters, thus allowing the server to differentiate renegotiation 164 from initial negotiation, as well as preventing renegotiations from 165 being spliced in between connections. An attempt by an attacker to 166 inject himself as described above will result in a mismatch of the 167 cryptographic binding and can thus be detected. The data used in the 168 extension is similar to, but not the same as, the data used in the 169 tls-unique and/or tls-unique-for-telnet channel bindings described in 170 [I-D.altman-tls-channel-bindings], however this extension is not a 171 general-purpose RFC 5056 [RFC5056] channel binding facility." 173 2. Conventions Used In This Document 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 3. Secure Renegotiation Definition 181 3.1. Additional Connection State 183 Both client and server need to store three additional values for each 184 TLS connection state (see RFC 5246, Section 6.1). Note that these 185 values are specific to connection (not a TLS session cache entry). 187 o a "secure_renegotiation" flag, indicating whether secure 188 renegotiation is in use for this connection. 189 o "client_verify_data": the verify_data from the Finished message 190 sent by the client on the immediately previous handshake. For 191 currently defined TLS versions and cipher suites, this will be a 192 12-byte value; for SSLv3, this will be a 36-byte value. 193 o "server_verify_data": the verify_data from the Finished message 194 sent by the server on the immediately previous handshake. 196 3.2. Extension Definition 198 This document defines a new TLS extension: "renegotiation_info", 199 (with extension type 0xff01) which contains a cryptographic binding 200 to the enclosing TLS connection (if any) for which the renegotiation 201 is being performed. The "extension data" field of this extension 202 contains a "RenegotiationInfo" structure: 204 struct { 205 opaque renegotiated_connection<0..255>; 206 } RenegotiationInfo; 208 The contents of this extension are specified as follows. 210 o If this is the initial handshake for a connection, then the 211 "renegotiated_connection" field is of zero length in both the 212 ClientHello and the ServerHello. Thus, the entire encoding of the 213 extension is: ff 01 00 01 00. The first two octets represent the 214 extension type, the third and fourth octet the length of the 215 extension itself, and the final octet the zero length byte for the 216 "renegotiated_connection" field. 217 o For ClientHellos which are renegotiating, this field contains the 218 "client_verify_data" specified in Section 3.2. 219 o For ServerHellos which are renegotiating, this field contains the 220 concatenation of client_verify_data and server_verify_data. For 221 current versions of TLS, this will be a 24-byte value (for SSLv3, 222 it will be a 72-byte value). 224 This extension also can be used with Datagram TLS [RFC4347]. 225 Although for editorial simplicity this document refers to TLS, all 226 requirements in this document apply equally to DTLS. 228 3.3. Renegotiation Protection Request Signalling Cipher Suite Value 230 Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require 231 implementations to ignore data following the ClientHello (i.e., 232 extensions) if they do not understand it. However, some SSLv3 and 233 TLS 1.0 implementations incorrectly fail the handshake in such case. 234 This means that clients which offer the "renegotiation_info" 235 extension may encounter handshake failures. In order to enhance 236 compatibility with such servers, this document defines a second 237 signalling mechanism via a special Signalling Cipher Suite Value 238 (SCSV) "TLS_RENEGO_PROTECTION_REQUEST", with code point {0xNN, 0xMM}. 239 This SCSV is not a true cipher suite (it does not correspond to any 240 valid set of algorithms) and cannot be negotiated. Instead it has 241 the same semantics as an empty "renegotiation_info" extension, as 242 described in the following sections. Because SSLv3 and TLS 243 implementations reliably ignore unknown cipher suites, the SCSV may 244 be safely sent to any server. The SCSV can also be included in the 245 SSLv2 backward compatible CLIENT-HELLO. 247 Note: a minimal client which does not support renegotiation at all 248 can simply use the SCSV in all initial handshakes. The rules in the 249 following sections will cause any compliant server to abort the 250 handshake when it sees an apparent attempt at renegotiation by such a 251 client. 253 3.4. Client Behavior: Initial Handshake 255 Note that this section and Section 3.5 apply to both full handshakes 256 and session resumption handshakes. 258 o The client MUST include either an empty "renegotiation_info" 259 extension, or the TLS_RENEGO_PROTECTION_REQUEST signalling cipher 260 suite value in every ClientHello. Including both is NOT 261 RECOMMENDED. 262 o When ServerHello is received, the client MUST check if it includes 263 the "renegotiation_info" extension: 264 * If the extension is not present, the server does not support 265 secure renegotiation; set secure_renegotiation flag to FALSE. 266 In this case, some clients may want to terminate the handshake 267 instead of continuing; see Section 4.1 for discussion. 268 * If the extension is present, set the secure_renegotiation flag 269 to TRUE. The client MUST then verify that the length of the 270 "renegotiated_connection" field is zero, and if it is not, MUST 271 abort the handshake (by sending a fatal handshake_failure 272 alert). 273 * Note: later in Section 3, "abort the handshake" is used as a 274 shorthand for "send a fatal handshake_failure alert and 275 terminate the connection". 276 o When the handshake has completed the client needs to save the 277 client_verify_data and server_verify_data values for future use. 279 3.5. Client Behavior: Secure Renegotiation 281 This text applies if the connection's "secure_renegotiation" flag is 282 set to TRUE (if it is set to FALSE, see Section 4.2). 284 o The client MUST include the "renegotiation_info" extension in the 285 ClientHello, containing the saved client_verify_data. The SCSV 286 MUST NOT be included. 287 o When ServerHello is received, the client MUST verify that the 288 "renegotiation_info" extension is present; if it is not, the 289 client MUST abort the handshake. 290 o The client MUST then verify that the first half of the 291 "renegotiated_connection" field is equal to the saved 292 client_verify_data value, and the second half is equal to the 293 saved server_verify_data value. If they are not, the client MUST 294 abort the handshake. 295 o When the handshake has completed, the client needs to save the new 296 client_verify_data and server_verify_data values. 298 3.6. Server Behavior: Initial Handshake 300 Note that this section and Section 3.7 apply to both full handshakes 301 and session resumption handshakes. 303 o When ClientHello is received, the server MUST check if it includes 304 the TLS_RENEGO_PROTECTION_REQUEST SCSV. If it does, set 305 secure_renegotiation flag to TRUE. 306 o The server MUST check if the "renegotiation_info" extension is 307 included in ClientHello. If the extension is present, set 308 secure_renegotiation flag to TRUE. The server MUST then verify 309 that the length of the "renegotiated_connection" field is zero, 310 and if it is not, MUST abort the handshake. 311 o If neither the TLS_RENEGO_PROTECTION_REQUEST SCSV nor the 312 "renegotiation_info" extension was included, set 313 secure_renegotiation flag to FALSE. In this case, some servers 314 may want to terminate the handshake instead of continuing; see 315 Section 4.3 for discussion. 316 o If the secure_renegotiation flag is set to TRUE, the server MUST 317 include an empty "renegotiation_info" extension in the ServerHello 318 message. 319 o When the handshake has completed, the server needs to save the 320 client_verify_data and server_verify_data values for future use. 322 TLS servers implementing this specification MUST ignore any unknown 323 extensions offered by the client and MUST accept version numbers 324 higher than its highest version number and negotiate the highest 325 common version. These two requirements reiterate preexisting 326 requirements in RFC 5246 and are merely stated here in the interest 327 of forward compatibility. 329 Note that sending a "renegotiation_info" extension in response to a 330 ClientHello containing only the SCSV is an explicit exception to the 331 RFC 5246 Section 7.4.1.4 prohibition on the server sending 332 unsolicited extensions and is only allowed because the client is 333 signaling its willingness to receive the extension via the the 334 TLS_RENEGO_PROTECTION_REQUEST SCSV. TLS implementations MUST 335 continue to comply with 7.4.1.4 for all other extensions. 337 3.7. Server Behavior: Secure Renegotiation 339 This text applies if the connection's "secure_renegotiation" flag is 340 set to TRUE (if it is set to FALSE, see Section 4.4). 342 o When ClientHello is received, the server MUST verify that it does 343 not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV. If the SCSV 344 is present, the server MUST abort the handshake. 345 o The server MUST verify that the "renegotiation_info" extension is 346 present; if it is not, the server MUST abort the handshake. 347 o The server MUST verify that the value of the 348 "renegotiated_connection" field is equal to the saved 349 client_verify_data value; if it is not, the server MUST abort the 350 handshake. 351 o The server MUST include a "renegotiation_info" extension 352 containing the saved client_verify_data and server_verify_data in 353 the ServerHello. 354 o When the handshake has completed, the server needs to save the new 355 client_verify_data and server_verify_data values. 357 4. Backward Compatibility 359 Existing implementations which do not support this extension are 360 widely deployed and in general must interoperate with newer 361 implementations which do support it. This section describes 362 considerations for backward compatible interoperation. 364 4.1. Client Considerations 366 If a client offers the "renegotiation_info" extension or the 367 TLS_RENEGO_PROTECTION_REQUEST SCSV and the server does not reply with 368 "renegotiation_info" in the ServerHello, then this indicates that the 369 server does not support secure renegotiation. Because the above 370 attack looks like a single handshake to the client, the client cannot 371 determine whether the connection is under attack or not. Note, 372 however, that merely because the server does not acknowledge the 373 extension does not mean that it is vulnerable; it might choose to 374 reject all renegotiations and simply not signal it. However, it is 375 not possible for the client to determine purely via TLS mechanisms 376 whether this is the case or not. 378 If clients wish to ensure that such attacks are impossible, they need 379 to terminate the connection immediately upon failure to receive the 380 extension without completing the handshake. Such clients MUST 381 generate a fatal "handshake_failure" alert prior to terminating the 382 connection. However, it is expected that many TLS servers that do 383 not support renegotiation (and thus are not vulnerable) will not 384 support this extension either, so in general, clients which implement 385 this behavior will encounter interoperability problems. There is no 386 set of client behaviors which will guarantee security and achieve 387 maximum interoperability during the transition period. Clients need 388 to choose one or the other preference when dealing with potentially 389 unupgraded servers. 391 4.2. Client Behavior: Legacy (Insecure) Renegotation 393 This text applies if the connection's "secure_renegotiation" flag is 394 set to FALSE. 396 It is possible that un-upgraded servers will request that the client 397 renegotiate. It is RECOMMENDED that clients refuse this 398 renegotiation request. Clients which do so MUST respond to such 399 requests with a "no_renegotiation" alert [RFC 5246 requires this 400 alert to be at the "warning" level.] It is possible that the 401 apparently un-upgraded server is in fact an attacker who is then 402 allowing the client to renegotiate with a different, legitimate, 403 upgraded server. If clients nevertheless choose to renegotiate, they 404 MUST behave as described below. 406 Clients which choose to renegotiate MUST provide either the 407 TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their 408 ClientHello. In a legitimate renegotiation with an un-upgraded 409 server, either of these signals will be ignored by the server. 410 However, if the server (incorrectly) fails to ignore extensions, 411 sending the "renegotiation_info" extension may cause a handshake 412 failure. Thus, it is permitted, though NOT RECOMMENDED, for the 413 client to simply send the SCSV. This is the only situation in which 414 clients are permitted to not send the "renegotiation_info" extension 415 in a ClientHello which is used for renegotiation. 417 Note that in the case of this downgrade attack, if this is the 418 initial handshake from the server's perspective, then use of the SCSV 419 from the client precludes detection of this attack by the server (if 420 this is a renegotiation from the server's perspective then it will 421 detect the attack). However, the attack will be detected by the 422 client when the server sends an empty "renegotiation_info" extension 423 and the client is expecting one containing the previous verify data. 424 By contrast, if the client sends the "renegotiation_info" extension, 425 then the server will immediately detect the attack. 427 When the ServerHello is received, the client MUST verify that it does 428 not contain the "renegotiation_info" extension. If it does, the 429 client MUST abort the handshake. [Because the server has already 430 indicated it does not support secure renegotiation the only way that 431 this can happen is if the server is broken or there is an attack.] 433 4.3. Server Considerations 435 If the client does not offer the "renegotiation_info" extension or 436 the TLS_RENEGO_PROTECTION_REQUEST SCSV then this indicates that the 437 client does not support secure renegotiation. However, because the 438 above attack looks like two handshakes to the server, the server can 439 safely continue the connection as long as it does not allow the 440 client to renegotiate. If servers wish to ensure that such attacks 441 are impossible they need to refuse to renegotiate with clients which 442 do not offer the "renegotiation_info" extension. Servers which 443 implement this behavior MUST respond to such requests with a 444 "no_renegotiation" alert [RFC 5246 requires this alert to be at the 445 "warning" level.] Servers SHOULD follow this behavior. 447 In order to enable clients to probe, even servers which do not 448 support renegotiation MUST implement the minimal version of the 449 extension described in this document for initial handshakes, thus 450 signalling that they have been upgraded. 452 4.4. Server Behavior: Legacy (Insecure) Renegotiation 454 This text applies if the connection's "secure_renegotiation" flag is 455 set to FALSE. 457 It is RECOMMENDED that servers not permit legacy renegotiation. If 458 servers nevertheless do permit it, they MUST follow the requirements 459 in this section. 460 o When ClientHello is received, the server MUST verify that it does 461 not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV. If the SCSV 462 is present, the server MUST abort the handshake. 463 o The server MUST verify that the "renegotiation_info" extension is 464 not present; if it is, the server MUST abort the handshake. 466 4.5. SSLv3 468 While SSLv3 is not a protocol under IETF change control (see [SSLv3]) 469 it was the original basis for TLS and most TLS stacks are also SSLv3 470 stacks. The SCSV and extension defined in this document can also be 471 used with SSLv3 with no changes except for the size of the 472 verify_data values, which are 36 bytes long each. TLS Clients which 473 support SSLv3 and offer secure renegotiation (either via SCSV or 474 "renegotiation_info") MUST accept the "renegotiation_info" extension 475 from the server even if the server version is {0x03, 0x00} and behave 476 as described in this specification. TLS Servers which support secure 477 renegotation and support SSLv3 MUST accept SCSV or the 478 "renegotiation_info" extension and respond as described in this 479 specification even if the offered client version is {0x03, 0x00}. 480 SSLv3 does not offer the "no_renegotiation" alert (and does not offer 481 a way to indicate a refusal to renegotiate at a warning level). 482 SSLv3 clients which refuse renegotiation SHOULD use a fatal 483 handshake_failure alert. 485 5. Security Considerations 487 The extension described in this document prevents an attack on TLS. 488 If this extension is not used, TLS renegotiation is subject to an 489 attack in which the attacker can inject their own conversation with 490 the TLS server as a prefix of the client's conversation. This attack 491 is invisible to the client and looks like an ordinary renegotiation 492 to the server. The extension defined in this document allows 493 renegotiation to be performed safely. Servers SHOULD NOT allow 494 clients to renegotiate without using this extension. Many servers 495 can mitigate this attack simply by refusing to renegotiate at all. 497 While this extension mitigates the man-in-the-middle attack described 498 in the overview, it does not resolve all possible problems an 499 application may face if it is unaware of renegotiation. For example, 500 during renegotiation either the client or the server can present a 501 different certificate than was used earlier. This may come as a 502 surprise to application developers (who might have expected, for 503 example, that a "getPeerCertificates()" API call returns the same 504 value if called twice), and might be handled in an insecure way. 506 TLS implementations SHOULD provide a mechanism to disable and enable 507 renegotiation. 509 TLS implementers are encouraged to clearly document how renegotiation 510 interacts with the APIs offered to applications (for example, which 511 API calls might return different values on different calls, or which 512 callbacks might get called multiple times). 514 To make life simpler for applications that use renegotiation but do 515 not expect the certificate to change once it has been authenticated, 516 TLS implementations may also wish to offer the applications the 517 option abort the renegotiation if the peer tries to authenticate with 518 a different certificate and/or different server name (in the 519 server_name extension) than was used earlier. TLS implementations 520 may alternatively offer the option to disable renegotiation once the 521 client certificate has be authenticated. However, enabling these 522 options by default for all applications could break existing 523 applications that depend on using renegotiation to change from one 524 certificate to another. (For example, long-lived TLS connections 525 could change to a renewed certificate; or renegotiation could select 526 a different cipher suite that requires using a different 527 certificate.) 529 Finally, designers of applications that depend on renegotiation are 530 reminded that many TLS APIs represent application data as a simple 531 octet stream; applications may not be able to determine exactly which 532 application data octets were received before, during, or after 533 renegotiation. Especially if the peer presents a different 534 certificate during renegotiation, care is needed when specifying how 535 the application should handle the data. 537 6. IANA Considerations 539 IANA [shall add/has added] the extension code point XXX [We request 540 0xff01, which has been used for prototype implementations] for the 541 "renegotiation_info" extension to the TLS ExtensionType values 542 registry. 544 IANA [shall add/has added] TLS cipher suite number 0xNN,0xMM [We 545 request 0x00, 0xff] with name TLS_RENEGO_PROTECTION_REQUEST to the 546 TLS Cipher Suite registry. 548 7. Acknowledgements 550 This vulnerability was originally discovered by Marsh Ray and 551 independently rediscovered by Martin Rex. The general concept behind 552 the extension described here was independently invented by Steve 553 Dispensa, Nasko Oskov, and Eric Rescorla with refinements from Nelson 554 Bolyard, Pasi Eronen, Michael D'Errico, Stephen Farrell, Michael 555 Gray, David-Sarah Hopwood, Ben Laurie, David Makepeace, Bodo Moeller, 556 Martin Rex (who defined TLS_RENEGO_PROTECTION_REQUEST), Peter 557 Robinson, Jesse Walker, Nico Williams and other members of the the 558 Project Mogul team and the TLS WG. [Note: if you think your name 559 should be here, please speak up.] 561 8. References 562 8.1. Normative References 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 568 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 570 8.2. Informative References 572 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 573 Security", RFC 4347, April 2006. 575 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 576 Channels", RFC 5056, November 2007. 578 [I-D.altman-tls-channel-bindings] 579 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 580 for TLS", draft-altman-tls-channel-bindings-07 (work in 581 progress), October 2009. 583 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 585 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 586 Mechanism", RFC 2965, October 2000. 588 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 589 November 2009, . 591 [SSLv3] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 592 Version 3.0", November 1996, . 595 Authors' Addresses 597 Eric Rescorla 598 RTFM, Inc. 599 2064 Edgewood Drive 600 Palo Alto, CA 94303 601 USA 603 Email: ekr@rtfm.com 604 Marsh Ray 605 PhoneFactor 606 7301 W 129th Street 607 Overland Park, KS 66213 608 USA 610 Email: marsh@extendedsubset.com 612 Steve Dispensa 613 PhoneFactor 614 7301 W 129th Street 615 Overland Park, KS 66213 616 USA 618 Email: dispensa@phonefactor.com 620 Nasko Oskov 621 Microsoft 622 One Microsoft Way 623 Redmond, WA 98052 624 USA 626 Email: nasko.oskov@microsoft.com