Internet DRAFT - draft-josefsson-sasl-tls-cb
draft-josefsson-sasl-tls-cb
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]
