One document matched: draft-josefsson-sasl-tls-cb-01.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="std" ipr="full3978"
     docName="draft-josefsson-sasl-tls-cb-01">

<front>

<title>
Channel Bindings for TLS based on PRF
</title>

<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
	<organization>SJD</organization>
	<address>
		<email>simon@josefsson.org</email>
	</address>
</author>
	
<date month="August" year="2008"/>

<abstract>

  <t>This document specify how to compute data, "channel bindings",
    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).</t>

</abstract>

</front>
	
<middle>

<section title="Introduction">

  <t>Binding authentication to a specific encrypted session can
    protect from certain <xref target="mitm">attacks</xref>.  It can
    also help to improve performance by having peers agree to re-use a
    secure channel rather than to set up a new.</t>

  <t>This document describe how to generate data that can be used by
    application protocols to bind authentication to a
    specific <xref target="RFC4346">TLS</xref> session.</t>

</section>

<section title="Conventions Used in this Document">

  <t>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
    <xref target="RFC2119" />.</t>

</section>

<section title="Channel Bindings Syntax">

  <t>The channel bindings is computed using the TLS Pseudo-Random
    Function (PRF).  The PRF takes three inputs, a secret, a fixed
    label, and a seed.  Here the label will be "channel binding".  The
    key will be the master secret in a TLS session.  The seed will be
    the hash of the handshake messages, computed the same way as for
    the TLS Finished message.  We will use the first 32 octets
    computed by the PRF.</t>

  <t>Using the terminology and pseudo-language
    in <xref target="RFC4346">TLS</xref>, the channel bindings is
    computed as follows:</t>

  <figure>
    <artwork>
 TLS_channel_bindings = 
    PRF(SecurityParameters.master_secret, 
        "channel binding", 
        MD5(handshake_messages) + SHA-1(handshake_messages)) [0..31]
    </artwork>
  </figure>

  <t>The derived data MUST NOT be used for any other purpose than
    channel bindings as desribed in <xref target="RFC5056"/>.</t>

</section>

<section title="IANA Considerations">

  <t>The IANA is requested to register this channel binding using the
    following templates and the process described in
    <xref target="RFC5056"/>.</t>

  <t>Subject: Registration of channel binding TLS</t>

  <t>Channel binding unique prefix (name): tls-unique-prf</t>

  <t>Channel binding type: unique</t>

  <t>Channel type: TLS</t>

  <t>Published specification (recommended, optional): This
    document</t>

  <t>Channel binding is secret (requires confidentiality protection):
    no</t>

  <t>Description (optional if a specification is given; required if no
    Published specification is specified): See earlier in this
    document.</t>

  <t>Intended usage: COMMON</t>

  <t>Person and email address to contact for further information:
    simon@josefsson.org</t>

  <t>Owner/Change controller name and email address:
    simon@josefsson.org</t>

  <t>Expert reviewer name and contact information:</t>

</section>

<section title="Security Considerations">

  <t>For the intended use and other important considerations, see
    <xref target="RFC5056"/>.</t>

  <t>We claim that by appropriately using a channel binding an
    application can protect itself from the attacks in
    <xref target="mitm" />.  To guarantee this property, the derived
    data is only to be used for the intended purpose.</t>

  <t>The security considerations in TLS should be considered.  In
    particular, the TLS master secret must be protected.  </t>

</section>

<section title="Acknowledgements">

  <t>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.</t>

</section>

</middle>

<back>

<references title="Normative References">

  <?rfc include="reference.RFC.2119.xml"?>
  <?rfc include="reference.RFC.4346.xml"?>
  <?rfc include="reference.RFC.5056.xml"?>

</references>

<references title="Informative References">

    <reference anchor="mitm">
      <front>
	<title>Man-in-the-Middle in Tunneled Authentication</title>
	<author initials="N." surname="Asokan" fullname="N. Asokan">
	</author>
	<author initials="V." surname="Niemi" fullname="V. Niemi">
	</author>
	<author initials="K." surname="Nyberg" fullname="K. Nyberg">
	</author>
      </front>
      <seriesInfo name="WWW"
		  value="http://www.saunalahti.fi/~asokan/research/mitm.html" />
    </reference>

</references>

</back>

</rfc>