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


   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

   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
   ( 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

   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

   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:

   Owner/Change controller name and email address:

   Expert reviewer name and contact information:

4.  Security Considerations

   For the intended use and other important considerations, see

   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)

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.

              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
    , November 2002.

              Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
              A., and P. Strub, "Triple Handshakes and Cookie Cutters:
              Breaking and Fixing Authentication over TLS", WWW
    , March 2014.

Author's Address

   Simon Josefsson


Josefsson               Expires September 3, 2015               [Page 5]