Network Working Group S. Josefsson Internet-Draft SJD AB Intended status: Standards Track March 2, 2015 Expires: September 3, 2015 Channel Bindings for TLS based on the PRF draft-josefsson-sasl-tls-cb-03 Abstract This document specify how to compute the 'tls-unique-prf' data that is cryptographically bound to a specific Transport Layer Security (TLS) session. The intention is to use this data as a name of the secure channel for the purpose of a channel binding. The channel bindings can be used by authentication protocols to avoid tunneling attacks and security layer re-use. The data is derived using the TLS Pseudo-Random Function (PRF). Applications of this include SASL- based protocols like IMAP, SMTP and XMPP. The channel binding 'tls- unique-prf' defined in this document is an alternative to 'tls- unique' as described by RFC 5929 and used by SCRAM and GS2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 3, 2015. Copyright Notice Copyright (c) 2015 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 Josefsson Expires September 3, 2015 [Page 1] Internet-Draft Channel Bindings for TLS based on the PRF March 2015 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Channel Bindings Syntax . . . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Binding authentication to a specific encrypted session can protect from certain attacks [MITM]. It can also help to improve performance by having peers agree to re-use a secure channel rather than to set up a new. After publication of SCRAM [RFC5802] and GS2 [RFC5801], it was discovered that the mandatory-to-implement and non-negotiable channel binding 'tls-unique' [RFC5929] does not meet the required properties [TRIPLE-HANDSHAKE]. This document describe how to generate data that can be used by application protocols to bind authentication to a specific TLS [RFC5246] session, in the same way as 'tls-unique' was intended to work. There exists a TLS extension [I-D.ietf-tls-session-hash] that modify TLS so that the definition of 'tls-unique' [RFC5929] has the intended properties. If widely implemented and deployed, the channel binding type in this document would not offer any additional protection. The purpose of this document is to provide an alternative channel binding that offers the intended properties without requiring TLS protocol changes. However, keep in mind that TLS implementations needs to offer the appropriate APIs necessary to be able to implement the channel binding described in this document. 2. Channel Bindings Syntax Inspired by [I-D.ietf-tls-session-hash] we introduce some definitions. When a full TLS handshake takes place, let session_hash be defined as follows. Josefsson Expires September 3, 2015 [Page 2] Internet-Draft Channel Bindings for TLS based on the PRF March 2015 session_hash = Hash(handshake_messages) Here "handshake_messages" refers to all handshake messages sent or received, starting at the ClientHello up to and including the ClientKeyExchange message, including the type and length fields of the handshake messages. This is the concatenation of all the exchanged Handshake structures, as defined in Section 7.4 of [RFC5246]. For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9 of [RFC5246] for the Finished message computation. For all previous versions of TLS, the "Hash" function computes the concatenation of MD5 and SHA1. There is no "session_hash" for resumed handshakes, as they do not lead to the creation of a new session. The channel bindings is then computed using the TLS Pseudorandom Function (PRF), see section 5 of [RFC5246]. The PRF takes three inputs, a secret, a fixed label, and a seed. Here the label will be "EXPORTER Channel Binding". The key will be the master secret in a TLS session. The seed is will be the session_hash as described above. We will use the first 32 octets computed by the PRF. Using the terminology, conventions and and pseudo-language in TLS [RFC5246] and [RFC5705], the channel bindings is computed as follows: TLS_channel_bindings = PRF(master_secret, "EXPORTER Channel Binding", session_hash) [0..31] The 32 byte TLS_channel_bindings data is used as the 'tls-unique-prf' channel binding data. 3. IANA Considerations The IANA is requested to allocate a string "EXPORTER Channel Binding" in the TLS Exporter Label registry as per [RFC5705]. The IANA is requested to register this channel binding using the following templates and the process described in [RFC5056]. Subject: Registration of channel binding TLS Channel binding unique prefix (name): tls-unique-prf Channel binding type: unique Josefsson Expires September 3, 2015 [Page 3] Internet-Draft Channel Bindings for TLS based on the PRF March 2015 Channel type: TLS Published specification (recommended, optional): This document Channel binding is secret (requires confidentiality protection): no Description (optional if a specification is given; required if no Published specification is specified): See earlier in this document. Intended usage: COMMON Person and email address to contact for further information: simon@josefsson.org Owner/Change controller name and email address: simon@josefsson.org Expert reviewer name and contact information: 4. Security Considerations For the intended use and other important considerations, see [RFC5056]. We claim that by appropriately using a channel binding an application can protect itself from the attacks in [MITM] and [TRIPLE-HANDSHAKE]. To guarantee this property, the derived data is only to be used for the intended purpose. The security considerations of TLS [RFC5246] are inherited by this document. In particular, the TLS master secret must be protected. 5. Acknowledgements Thanks to Eric Rescorla and Sam Hartman who pointed out a problem with the construct used in earlier versions of this document when TLS server authentication is not used or checked. The construct used starting from the -03 version of this document is inspired by (and some text were copied from) [I-D.ietf-tls-session-hash]. 6. References 6.1. Normative References [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. Josefsson Expires September 3, 2015 [Page 4] Internet-Draft Channel Bindings for TLS based on the PRF March 2015 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010. 6.2. Informative References [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010. [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010. [I-D.ietf-tls-session-hash] Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", draft-ietf- tls-session-hash-03 (work in progress), November 2014. [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunneled Authentication", WWW http://eprint.iacr.org/2002/163.pdf, November 2002. [TRIPLE-HANDSHAKE] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", WWW https://www.secure-resumption.com/, March 2014. Author's Address Simon Josefsson SJD AB Email: simon@josefsson.org Josefsson Expires September 3, 2015 [Page 5]