idnits 2.17.1 draft-rescorla-tls-renegotiation-00.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 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 09, 2009) is 5282 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 124, 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 (~~), 4 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 13, 2010 S. Dispensa 6 PhoneFactor 7 N. Oskov 8 Microsoft 9 November 09, 2009 11 Transport Layer Security (TLS) Renegotiation Indication Extension 12 draft-rescorla-tls-renegotiation-00.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 13, 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 . . . . . . . . . . . . . . . . . . . 6 77 4.3. SSLv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 TLS [RFC5246] allows either the client or the server to initiate 89 renegotiation--a new handshake which establishes new cryptographic 90 parameters. Unfortunately, although the new handshake is carried out 91 over the protected channel established by the original handshake, 92 there is no cryptographic connection between the two. This creates 93 the opportunity for an attack in which the attacker who can intercept 94 a client's transport layer connection can inject traffic of his own 95 as a prefix to the client's interaction with the server. The attack 96 proceeds as shown below: 98 Client Attacker Server 99 ------ ------- ------ 100 <----------- Handshake ----------> 101 <======= Initial Traffic ========> 102 <-------------------------- Handshake ============================> 103 <======================== Client Traffic ==========================> 105 To start the attack, the attacker forms a TLS connection to the 106 server (perhaps in response to an initial intercepted connection from 107 the client). He then sends any traffic of his choice to the server. 108 This may involve multiple requests and responses at the application 109 layer, or may simply be a partial application layer request intended 110 to prefix the client's data. This traffic is shown with == to 111 indicate it is encrypted. He then allows the client's TLS handshake 112 to proceed with the server. The handshake is in the clear to the 113 attacker but encrypted over the attacker's channel to the server. 114 Once the handshake has completed, the client communicates with the 115 server over the new channel. The attacker cannot read this traffic, 116 but the server believes that the initial traffic to and from the 117 attacker is the same as that to and from the client. 119 If certificate-based client authentication is used, the server will 120 believe that the initial traffic corresponds to the authenticated 121 client identity. Even without certificate-based authentication, a 122 variety of attacks may be possible in which the attacker convinces 123 the server to accept data from it as data from the client. For 124 instance, if HTTPS [RFC2818] is in use with HTTP cookies [REF], the 125 attacker may be able to generate a request of his choice validated by 126 the client's cookie. 128 This attack can be prevented by cryptographically binding 129 renegotiation handshakes to the enclosing TLS channel, thus allowing 130 the server to differentiate renegotiation from initial negotiation, 131 as well as preventing renegotiations from being spliced in between 132 connections. An attempt by an attacker to inject himself as 133 described above will result in a mismatch of the extension and can 134 thus be detected This document defines an extension that performs 135 that cryptographic binding. The extension described here is similar 136 to that used for TLS Channel Bindings 137 [I-D.altman-tls-channel-bindings]. 139 2. Conventions Used In This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Extension Definition 147 This document defines a new TLS extension: "renegotiation_info", 148 which contains a cryptographic binding to the enclosing TLS 149 connection (if any) for which the renegotiation is being performed. 150 The "extension data" field of this extension contains a 151 "Renegotiation_Info" structure: 153 struct { 154 opaque renegotiated_connection<0..255>; 155 } Renegotiation_Info; 157 All TLS implementations SHOULD support this extension. TLS clients 158 SHOULD generate it with every handshake and TLS servers SHOULD 159 generate it in response to any client which offers it. 161 The contents of this extension are specified as follows. 163 o If this is the initial handshake for a connection, then this field 164 is of zero length in both the ClientHello and the ServerHello. 165 o For ClientHellos which are renegotiating, this field contains the 166 verify_data from the Finished message sent by the client on the 167 immediately previous handshake. For current versions of TLS, this 168 will be a 12-byte value. Note that this value is the "tls-unique" 169 channel binding from [I-D.altman-tls-channel-bindings] 170 o For ServerHellos which are renegotiating, this field contains the 171 concatenation of the verify_data values sent by the client and the 172 server (in that order) on the immediately previous handshake. For 173 current versions of TLS, this will be a 24-byte value. 175 The above rules apply even when TLS resumption is used. 177 Upon receipt of the "renegotiation_info" extension, implementations 178 which support the extension MUST verify that it contains the correct 179 contents as specified above. If the contents are incorrect, then it 180 MUST generate a fatal "handshake_failure" alert and terminate the 181 connection. This allows two implementations both of which support 182 the extension to safely renegotiate without fear of the above attack. 184 4. Backward Compatibility 186 Existing implementations which do not support this extension are 187 widely deployed and in general must interoperate with newer 188 implementations which do support it. This section describes 189 considerations for backward compatible interoperation. [[ OPEN ISSUE: 190 The normative strength of these recommendations needs to be 191 discussed.]] 193 4.1. Client Considerations 195 If a client offers the "renegotiation_info" extension and the server 196 does not respond, then this indicates that the server either does not 197 support the extension or is unwilling to use it. Because the above 198 attack looks like a single handshake to the client, the client cannot 199 determine whether the connection is under attack or not. 201 If clients wish to ensure that such attacks are impossible, they MUST 202 terminate the connection immediately upon failure to receive the 203 extension without completing the handshake. Otherwise, they may be 204 performing client authentication and thus potentially authorizing the 205 data already sent by the attacker even if the client itself sends no 206 data. Note that initially deployment of this extension will be very 207 sparse and thus choosing to terminate the connection immediately is 208 likely to result in significant interoperability problems. 210 4.2. Server Considerations 212 If the client does not offer the "renegotiation_info" extension, then 213 this indicates that the client does not support the extension or is 214 unwilling to use it. Note that TLS does not permit servers to offer 215 unsolicited extensions. However, because the above attack looks like 216 two handshakes to the server, the server can safely continue the 217 connection as long as it does not allow the client to rehandshake. 218 If servers wish to ensure that such attacks are impossible they MUST 219 NOT allow clients who do not offer the "renegotiation_info" extension 220 to renegotiate with them and SHOULD respond to such requests with a 221 "no_renegotiation" alert [RFC 5246 requires this alert to be at the 222 "warning" level.] Servers SHOULD follow this behavior. 224 4.3. SSLv3 226 SSLv3 does not support extensions and thus it is not possible to 227 securely renegotiate with SSLv3. Deployments wishing to renegotiate 228 securely will need to upgrade to at least TLS 1.0. 230 5. Security Considerations 232 The extension described in this document prevents an attack on TLS. 233 If this extension is not used, TLS renegotiation is subject to an 234 attack in which the attacker can inject their own conversation with 235 the TLS server as a prefix of the client's conversation. This attack 236 is invisible to the client and looks like an ordinary renegotiation 237 to the server. The extension defined in this document allows 238 renegotiation to be performed safely. Servers SHOULD NOT allow 239 clients to renegotiate without using this extension. 241 6. IANA Considerations 243 IANA [shall add/has added] the extension code point XXX [We request 244 0xff01, which has been used for prototype implementations] for the 245 "renegotiation_info" extension to the TLS ExtensionType values 246 registry. 248 7. Acknowledgements 250 This vulnerability was originally discovered by Marsh Ray. The 251 general concept behind the extension described here was independently 252 invented by Steve Dispensa, Nasko Oskov, and Eric Rescorla. Comments 253 and refinements were received from Jesse Walker and the rest of the 254 Project Mogul team. 256 8. References 258 8.1. Normative References 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 264 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 266 8.2. Informative References 268 [I-D.altman-tls-channel-bindings] 269 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 270 for TLS", draft-altman-tls-channel-bindings-07 (work in 271 progress), October 2009. 273 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 275 Authors' Addresses 277 Eric Rescorla 278 RTFM, Inc. 279 2064 Edgewood Drive 280 Palo Alto, CA 94303 281 USA 283 Email: ekr@rtfm.com 285 Marsh Ray 286 PhoneFactor 287 7301 W 129th Street 288 Overland Park, KS 66213 289 USA 291 Email: marsh@extendedsubset.com 293 Steve Dispensa 294 PhoneFactor 295 7301 W 129th Street 296 Overland Park, KS 66213 297 USA 299 Email: dispensa@phonefactor.com 301 Nasko 302 Microsoft 303 One Microsoft Way 304 Redmond, WA 98052 305 USA 307 Email: nasko.oskov@microsoft.com