Network Working Group E. Rescorla Internet-Draft RTFM, Inc. Updates: RFCs 5246, 4366, 4347, M. Ray 4346, 2246 (if approved) S. Dispensa Intended status: Standards Track PhoneFactor Expires: July 29, 2010 N. Oskov Microsoft January 26, 2010 Transport Layer Security (TLS) Renegotiation Indication Extension draft-ietf-tls-renegotiation-04.txt Abstract SSL and TLS renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2010. Rescorla, et al. Expires July 29, 2010 [Page 1] Internet-Draft TLS Renegotiation Extension Jan 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . . 4 3. Secure Renegotiation Definition . . . . . . . . . . . . . . . . 5 3.1. Additional Connection State . . . . . . . . . . . . . . . 5 3.2. Extension Definition . . . . . . . . . . . . . . . . . . . 5 3.3. Renegotiation Protection Request Signaling Cipher Suite Value . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Client Behavior: Initial Handshake . . . . . . . . . . . . 6 3.5. Client Behavior: Secure Renegotiation . . . . . . . . . . 7 3.6. Server Behavior: Initial Handshake . . . . . . . . . . . . 7 3.7. Server Behavior: Secure Renegotiation . . . . . . . . . . 8 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 4.1. Client Considerations . . . . . . . . . . . . . . . . . . 8 4.2. Client Behavior: Legacy (Insecure) Renegotiation . . . . . 9 4.3. Server Considerations . . . . . . . . . . . . . . . . . 10 4.4. Server Behavior: Legacy (Insecure) Renegotiation . . . . 10 4.5. SSLv3 . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Rescorla, et al. Expires July 29, 2010 [Page 2] Internet-Draft TLS Renegotiation Extension Jan 2010 1. Introduction TLS [RFC5246] allows either the client or the server to initiate renegotiation--a new handshake which establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out using the cryptographic parameters established by the original handshake, there is no cryptographic binding between the two. This creates the opportunity for an attack in which the attacker who can intercept a client's transport layer connection can inject traffic of his own as a prefix to the client's interaction with the server. The attack [Ray09] proceeds as shown below: Client Attacker Server ------ ------- ------ <----------- Handshake ----------> <======= Initial Traffic ========> <-------------------------- Handshake ============================> <======================== Client Traffic ==========================> To start the attack, the attacker forms a TLS connection to the server (perhaps in response to an initial intercepted connection from the client). He then sends any traffic of his choice to the server. This may involve multiple requests and responses at the application layer, or may simply be a partial application layer request intended to prefix the client's data. This traffic is shown with == to indicate it is encrypted. He then allows the client's TLS handshake to proceed with the server. The handshake is in the clear to the attacker but encrypted over the attacker's TLS connection to the server. Once the handshake has completed, the client communicates with the server over the newly established security parameters with the server. The attacker cannot read this traffic, but the server believes that the initial traffic to and from the attacker is the same as that to and from the client. If certificate-based client authentication is used, the server will see a stream of bytes where the initial bytes are protected but unauthenticated by TLS and subsequent bytes are authenticated by TLS and bound to the client's certificate. In some protocols (notably HTTPS), no distinction is made between pre- and post-authentication stages and the bytes are handled uniformly, resulting in the server believing that the initial traffic corresponds to the authenticated client identity. Even without certificate-based authentication, a variety of attacks may be possible in which the attacker convinces the server to accept data from it as data from the client. For instance, if HTTPS [RFC2818] is in use with HTTP cookies [RFC2965] the attacker may be able to generate a request of his choice validated by the client's cookie. Rescorla, et al. Expires July 29, 2010 [Page 3] Internet-Draft TLS Renegotiation Extension Jan 2010 Some protocols--such as IMAP or SMTP--have more explicit transitions between authenticated and unauthenticated phases and require that the protocol state machine be partly or fully reset at such transitions. If strictly followed, these rules may limit the effect of attacks. Unfortunately, there is no requirement for state machine resets at TLS renegotiation and thus there is still a potential window of vulnerability, for instance by prefixing a command which writes to an area visible by the attacker with a command by the client that includes his password, thus making the client's password visible to the attacker (note that this precise attack does not work with challenge-response authentication schemes but other attacks may be possible). Similar attacks are available with SMTP and in fact do not necessarily require the attacker to have an account on the target server. It is important to note that in both cases these attacks are possible because the client sends unsolicited authentication information without requiring any specific data from the server over the TLS connection. Protocols which require a round trip to the server over TLS before the client sends sensitive information are likely to be less vulnerable. These attacks can be prevented by cryptographically binding renegotiation handshakes to the enclosing TLS cryptographic parameters, thus allowing the server to differentiate renegotiation from initial negotiation, as well as preventing renegotiations from being spliced in between connections. An attempt by an attacker to inject himself as described above will result in a mismatch of the cryptographic binding and can thus be detected. The data used in the extension is similar to, but not the same as, the data used in the tls-unique and/or tls-unique-for-telnet channel bindings described in [I-D.altman-tls-channel-bindings], however this extension is not a general-purpose RFC 5056 [RFC5056] channel binding facility." 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Rescorla, et al. Expires July 29, 2010 [Page 4] Internet-Draft TLS Renegotiation Extension Jan 2010 3. Secure Renegotiation Definition 3.1. Additional Connection State Both client and server need to store three additional values for each TLS connection state (see RFC 5246, Section 6.1). Note that these values are specific to connection (not a TLS session cache entry). o a "secure_renegotiation" flag, indicating whether secure renegotiation is in use for this connection. o "client_verify_data": the verify_data from the Finished message sent by the client on the immediately previous handshake. For currently defined TLS versions and cipher suites, this will be a 12-byte value; for SSLv3, this will be a 36-byte value. o "server_verify_data": the verify_data from the Finished message sent by the server on the immediately previous handshake. 3.2. Extension Definition This document defines a new TLS extension: "renegotiation_info", (with extension type 0xff01) which contains a cryptographic binding to the enclosing TLS connection (if any) for which the renegotiation is being performed. The "extension data" field of this extension contains a "RenegotiationInfo" structure: struct { opaque renegotiated_connection<0..255>; } RenegotiationInfo; The contents of this extension are specified as follows. o If this is the initial handshake for a connection, then the "renegotiated_connection" field is of zero length in both the ClientHello and the ServerHello. Thus, the entire encoding of the extension is: ff 01 00 01 00. The first two octets represent the extension type, the third and fourth octet the length of the extension itself, and the final octet the zero length byte for the "renegotiated_connection" field. o For ClientHellos which are renegotiating, this field contains the "client_verify_data" specified in Section 3.2. o For ServerHellos which are renegotiating, this field contains the concatenation of client_verify_data and server_verify_data. For current versions of TLS, this will be a 24-byte value (for SSLv3, it will be a 72-byte value). This extension also can be used with Datagram TLS [RFC4347]. Although for editorial simplicity this document refers to TLS, all requirements in this document apply equally to DTLS. Rescorla, et al. Expires July 29, 2010 [Page 5] Internet-Draft TLS Renegotiation Extension Jan 2010 3.3. Renegotiation Protection Request Signaling Cipher Suite Value Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require implementations to ignore data following the ClientHello (i.e., extensions) if they do not understand it. However, some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake in such case. This means that clients which offer the "renegotiation_info" extension may encounter handshake failures. In order to enhance compatibility with such servers, this document defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) "TLS_RENEGO_PROTECTION_REQUEST", with code point {0xNN, 0xMM}. This SCSV is not a true cipher suite (it does not correspond to any valid set of algorithms) and cannot be negotiated. When the SCSV is used in ClientHello without "renegotiation_info" extension, it should be treated the same as an empty "renegotiation_info" extension, as described in the following sections. Because SSLv3 and TLS implementations reliably ignore unknown cipher suites, the SCSV may be safely sent to any server. The SCSV can also be included in the SSLv2 backward compatible CLIENT-HELLO (see Appendix E.2 [RFC5246]). Note: a minimal client which does not support renegotiation at all can simply include the SCSV in every ClientHello message. Compliant Servers will abort renegotiation attempts with a ClientHello that includes the SCSV and no valid "renegotiation_info" extension. 3.4. Client Behavior: Initial Handshake Note that this section and Section 3.5 apply to both full handshakes and session resumption handshakes. o The client MUST include either an empty "renegotiation_info" extension, or the TLS_RENEGO_PROTECTION_REQUEST signaling cipher suite value, in every initial ClientHello. It MAY send both. o When ServerHello is received, the client MUST check if it includes the "renegotiation_info" extension: * If the extension is not present, the server does not support secure renegotiation; set secure_renegotiation flag to FALSE. In this case, some clients may want to terminate the handshake instead of continuing; see Section 4.1 for discussion. * If the extension is present, set the secure_renegotiation flag to TRUE. The client MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake (sending a fatal handshake_failure alert). * Note: later in Section 3, "abort the handshake" is used as a shorthand for "send a fatal handshake_failure alert and terminate the connection". o When the handshake has completed the client needs to save the client_verify_data and server_verify_data values for future use. Rescorla, et al. Expires July 29, 2010 [Page 6] Internet-Draft TLS Renegotiation Extension Jan 2010 3.5. Client Behavior: Secure Renegotiation This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.2). o The client MUST include the "renegotiation_info" extension in the ClientHello, containing the saved client_verify_data. The SCSV MAY be included. o When ServerHello is received, the client MUST verify that the "renegotiation_info" extension is present; if it is not, the client MUST abort the handshake. o The client MUST then verify that the first half of the "renegotiated_connection" field is equal to the saved client_verify_data value, and the second half is equal to the saved server_verify_data value. If they are not, the client MUST abort the handshake. o When the handshake has completed, the client needs to save the new client_verify_data and server_verify_data values. 3.6. Server Behavior: Initial Handshake Note that this section and Section 3.7 apply to both full handshakes and session resumption handshakes. o When ClientHello is received, the server MUST check if it includes the TLS_RENEGO_PROTECTION_REQUEST SCSV. If it does, set secure_renegotiation flag to TRUE. o The server MUST check if the "renegotiation_info" extension is included in ClientHello. If the extension is present, set secure_renegotiation flag to TRUE. The server MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake. o If neither the TLS_RENEGO_PROTECTION_REQUEST SCSV nor the "renegotiation_info" extension was included, set secure_renegotiation flag to FALSE. In this case, some servers may want to terminate the handshake instead of continuing; see Section 4.3 for discussion. o If the secure_renegotiation flag is set to TRUE, the server MUST include an empty "renegotiation_info" extension in the ServerHello message. o When the handshake has completed, the server needs to save the client_verify_data and server_verify_data values for future use. Reiterating existing forward compatibility requirements in all existing TLS specs [RFC5246], [RFC4346] and [RFC2246], TLS servers MUST ignore any unknown ClientHello extensions and MUST accept client_version numbers higher than their own highest server_version number and select the highest common protocol_version. Rescorla, et al. Expires July 29, 2010 [Page 7] Internet-Draft TLS Renegotiation Extension Jan 2010 Note that sending a "renegotiation_info" extension in response to a ClientHello containing only the SCSV is an explicit exception to the RFC 5246 Section 7.4.1.4 prohibition on the server sending unsolicited extensions, and is only allowed because the client is signaling its willingness to receive the extension via the the TLS_RENEGO_PROTECTION_REQUEST SCSV. TLS implementations MUST continue to comply with 7.4.1.4 for all other extensions. 3.7. Server Behavior: Secure Renegotiation This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.4). o The server MUST verify that the "renegotiation_info" extension is present; if it is not, the server MUST abort the handshake. o The server MUST verify that the value of the "renegotiated_connection" field is equal to the saved client_verify_data value; if it is not, the server MUST abort the handshake. o The server MUST include a "renegotiation_info" extension containing the saved client_verify_data and server_verify_data in the ServerHello. o When the handshake has completed, the server needs to save the new client_verify_data and server_verify_data values. 4. Backward Compatibility Existing implementations which do not support this extension are widely deployed and in general must interoperate with newer implementations which do support it. This section describes considerations for backward compatible interoperation. 4.1. Client Considerations If a client offers the "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST SCSV and the server does not reply with "renegotiation_info" in the ServerHello, then this indicates that the server does not support secure renegotiation. Because the attack described in section 1 looks like a single handshake to the client, it is impossible for the client to distinguish an attack from a regular initial handshake with an un-upgraded server. Note, however, that merely because the server does not acknowledge the extension does not mean that it is vulnerable; it might simply be an old server (Webcam, PrintServer) which hasn't been upgraded or for which no upgrade is available. However, it is not possible for the client to determine purely via TLS mechanisms whether this is the case or not. Rescorla, et al. Expires July 29, 2010 [Page 8] Internet-Draft TLS Renegotiation Extension Jan 2010 If clients wish to ensure that such attacks are impossible, they need to terminate the connection immediately upon failure to receive the extension without completing the handshake. Such clients MUST generate a fatal "handshake_failure" alert prior to terminating the connection. However, it is expected that many TLS servers that do not support renegotiation (and thus are not vulnerable) will not support this extension either, so in general, clients which unconditionally abort initial TLS handshakes with un-upgraded servers will encounter interoperability problems. There is no set of client behaviors which will guarantee security and achieve maximum interoperability during the transition period. Clients need to choose one or the other preference when dealing with potentially un- upgraded servers. 4.2. Client Behavior: Legacy (Insecure) Renegotiation This text applies if the connection's "secure_renegotiation" flag is set to FALSE. It is RECOMMENDED that clients refuse renegotiation requests from un- upgraded servers. Clients which do so MUST respond to such requests with a "no_renegotiation" alert [RFC 5246 requires this alert to be at the "warning" level.] It is possible that the apparently un- upgraded server is in fact an attacker, who is trying to make the client renegotiate with a different server. In order to reliably prevent this attack from succeeding with upgraded servers, clients MUST behave as described below. Clients which choose to renegotiate MUST provide either the TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their ClientHello. In a renegotiation with an un-upgraded server, that server should ignore both of these signals. However, if the server (incorrectly) fails to ignore extensions, sending the "renegotiation_info" extension may cause a handshake failure. Thus, a client that permits insecure renegotiation might want to include the SCSV rather than "renegotiation_info" extension in those backwards interoperable renegotiation scenarios where the client did not send any extensions in the initial ClientHello on a connection. There exists an alternative attack scenario on TLS renegotiation to that described in section 1, where the client sees a renegotiation and the server sees an initial handshake. If the MitM simulated an old server to the client on the initial handshake, then sending only the SCSV in the renegotiation ClientHello looks like a valid initial handshake to an upgraded server. When the ServerHello is received, the client MUST verify that it does not contain the "renegotiation_info" extension. If it does, the client MUST abort the handshake. [The server did not confirm to support secure Rescorla, et al. Expires July 29, 2010 [Page 9] Internet-Draft TLS Renegotiation Extension Jan 2010 renegotiation on the initial handshake, so the only way that this can happen is if the server is broken or there is an attack.] 4.3. Server Considerations If the client does not offer the "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST SCSV then this indicates that the client does not support secure renegotiation. However, because the attack (see section 1) looks like two handshakes to the server, the server can safely continue the connection as long as it does not allow the client to renegotiate. If servers wish to ensure that such attacks are impossible they need to refuse to renegotiate with clients which do not offer the "renegotiation_info" extension. Servers which implement this behavior MUST respond to such requests with a "no_renegotiation" alert [RFC 5246 requires this alert to be at the "warning" level.] Servers SHOULD follow this behavior. In order to enable clients to probe, even servers which do not support renegotiation MUST implement the minimal version of the extension described in this document for initial handshakes, thus signaling that they have been upgraded. 4.4. Server Behavior: Legacy (Insecure) Renegotiation This text applies if the connection's "secure_renegotiation" flag is set to FALSE. It is RECOMMENDED that servers not permit legacy renegotiation. If servers nevertheless do permit it, they MUST follow the requirements in this section. o When ClientHello is received, the server MUST verify that it does not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV. If the SCSV is present, the server MUST abort the handshake. o The server MUST verify that the "renegotiation_info" extension is not present; if it is, the server MUST abort the handshake. 4.5. SSLv3 While SSLv3 (protocol_version {0x03, 0x00}) is not a protocol under IETF change control (see [SSLv3]) it was the original basis for TLSv1.0 (protocol_version {0x03,0x01}) and most implementations of TLS also support the SSLv3 protocol. The SCSV and extension defined in this document can also be used with SSLv3, where the data corresponding to the TLS verify_data in the Finished message is a concatenation of two values "md5_hash" and "sha_hash" with a combined length of 36 bytes. TLS Clients which support SSLv3 and offer secure renegotiation (via SCSV or "renegotiation_info") MUST accept the "renegotiation_info" extension from the server, even if the server Rescorla, et al. Expires July 29, 2010 [Page 10] Internet-Draft TLS Renegotiation Extension Jan 2010 replies with server_version {0x03, 0x00} in ServerHello, and behave as described in this specification. TLS Servers which support secure renegotiation and support SSLv3 MUST accept SCSV or the "renegotiation_info" extension and respond as described in this specification even if the offered client version is {0x03, 0x00}. SSLv3 does not define the "no_renegotiation" alert (and does not offer a way to indicate a refusal to renegotiate at a warning level). For refusing renegotiations, SSLv3 clients and servers should abort the handshake with a fatal handshake_failure alert. 5. Security Considerations The extension described in this document prevents an attack on TLS. If this extension is not used, TLS renegotiation is subject to an attack in which the attacker can inject their own conversation with the TLS server as a prefix of the client's conversation. This attack is invisible to the client and looks like an ordinary renegotiation to the server. The extension defined in this document allows renegotiation to be performed safely. Servers SHOULD NOT allow clients to renegotiate without using this extension. Many servers can mitigate this attack simply by refusing to renegotiate at all. While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. For example, during renegotiation either the client or the server can present a different certificate than was used earlier. This may come as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way. TLS implementations SHOULD provide a mechanism to disable and enable renegotiation. TLS implementers are encouraged to clearly document how renegotiation interacts with the APIs offered to applications (for example, which API calls might return different values on different calls, or which callbacks might get called multiple times). To make life simpler for applications that use renegotiation but do not expect the certificate to change once it has been authenticated, TLS implementations may also wish to offer the applications the option abort the renegotiation if the peer tries to authenticate with a different certificate and/or different server name (in the server_name extension) than was used earlier. TLS implementations may alternatively offer the option to disable renegotiation once the client certificate has be authenticated. However, enabling these Rescorla, et al. Expires July 29, 2010 [Page 11] Internet-Draft TLS Renegotiation Extension Jan 2010 options by default for all applications could break existing applications that depend on using renegotiation to change from one certificate to another. (For example, long-lived TLS connections could change to a renewed certificate; or renegotiation could select a different cipher suite that requires using a different certificate.) Finally, designers of applications that depend on renegotiation are reminded that many TLS APIs represent application data as a simple octet stream; applications may not be able to determine exactly which application data octets were received before, during, or after renegotiation. Especially if the peer presents a different certificate during renegotiation, care is needed when specifying how the application should handle the data. 6. IANA Considerations IANA [shall add/has added] the extension code point XXX [We request 0xff01, which has been used for prototype implementations] for the "renegotiation_info" extension to the TLS ExtensionType values registry. IANA [shall add/has added] TLS cipher suite number 0xNN,0xMM [We request 0x00, 0xff] with name TLS_RENEGO_PROTECTION_REQUEST to the TLS Cipher Suite registry. 7. Acknowledgements This vulnerability was originally discovered by Marsh Ray and independently rediscovered by Martin Rex. The general concept behind the extension described here was independently invented by Steve Dispensa, Nasko Oskov, and Eric Rescorla with refinements from Nelson Bolyard, Pasi Eronen, Michael D'Errico, Stephen Farrell, Michael Gray, David-Sarah Hopwood, Ben Laurie, David Makepeace, Bodo Moeller, Martin Rex (who defined TLS_RENEGO_PROTECTION_REQUEST), Peter Robinson, Jesse Walker, Nico Williams and other members of the the Project Mogul team and the TLS WG. [Note: if you think your name should be here, please speak up.] Rescorla, et al. Expires July 29, 2010 [Page 12] Internet-Draft TLS Renegotiation Extension Jan 2010 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006 [RFC2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4466, April 2006 8.2. Informative References [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [I-D.altman-tls-channel-bindings] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", draft-altman-tls-channel-bindings-07 (work in progress), October 2009. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000. [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", November 2009, . [SSLv3] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol Version 3.0", November 1996, . Rescorla, et al. Expires July 29, 2010 [Page 13] Internet-Draft TLS Renegotiation Extension Jan 2010 Authors' Addresses Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Email: ekr@rtfm.com Marsh Ray PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA Email: marsh@extendedsubset.com Steve Dispensa PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA Email: dispensa@phonefactor.com Nasko Oskov Microsoft One Microsoft Way Redmond, WA 98052 USA Email: nasko.oskov@microsoft.com Rescorla, et al. Expires July 29, 2010 [Page 14]