One document matched: draft-altman-tls-channel-bindings-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc0854 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0854.xml'>
<!ENTITY rfc1321 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2743 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY rfc3174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3174.xml'>
<!ENTITY rfc4880 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.xml'>
<!ENTITY rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY rfc5081 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5081.xml'>
<!ENTITY rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc5280 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY rfc5746 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml'>
<!ENTITY rhash PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-rhash.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc compact="no" ?>
<?rfc autobreaks="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="pre5378Trust200902" docName="draft-altman-tls-channel-bindings-09.txt">
<front>
<title abbrev="TLS Channel Bindings">Channel Bindings for TLS</title>
<author initials='J.' surname="Altman" fullname='Jeff
Altman'>
<organization abbrev="Secure Endpoints">Secure Endpoints</organization>
<address>
<postal>
<street>255 W 94TH ST PHB</street>
<city>New York</city> <region>NY</region>
<code>10025</code> <country>US</country>
</postal>
<email>jaltman@secure-endpoints.com</email>
</address>
</author>
<author initials='N.' surname="Williams" fullname='Nicolas Williams'>
<organization abbrev="Oracle">Oracle</organization>
<address>
<postal>
<street>5300 Riata Trace Ct</street>
<city>Austin</city>
<region>TX</region>
<code>78727</code>
<country>US</country>
</postal>
<email>Nicolas.Williams@oracle.com</email>
</address>
</author>
<author initials="L." surname="Zhu" fullname="Larry Zhu">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>lzhu@microsoft.com</email>
</address>
</author>
<date year="2010"/>
<area>Security</area>
<workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines three channel binding types for
Transport Layer Security (TLS), tls-unique,
tls-server-end-point, and tls-unique-for-telnet, in
accordance with RFC 5056 (On Channel Binding).</t>
</abstract>
</front>
<middle>
<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 anchor="intro" title="Introduction">
<t>Subsequent to the publication of "On Channel Bindings"
<xref target="RFC5246"/>, three channel binding types
for Transport Layer Security (TLS) were proposed,
reviewed and added to the IANA channel binding type
registry, all in accordance with <xref
target="RFC5246"/>. Those channel binding types
are: 'tls-unique', 'tls-server-end-point', and
'tls-unique-for-telnet'. It has become desirable to
have these channel binding types re-registered through
an RFC so as to make it easier to reference them, and to
correct them to describe actual implementations. This
document does just that. The authors of those three
channel binding types have, or have indicated that they
will, transferred "ownership" of those channel binding
types to the IESG.</t>
<t>We also provide some advice on the applicability of these
channel binding types, as well as advice on when to use
which. And we provide an abstract API that TLS
implementors should provide, by which to obtain channel
bindings data for a TLS connection.</t>
<t>WARNING: it turns out that the first implementor
implemented and deployed something rather different than
what was described in the IANA registration for
'tls-unique'. Subsequently it was decided that we
should adopt that form of 'tls-unique'. This means that
this document
makes a backwards-incompatible change to 'tls-unique'.
See <xref target="changes"/> for more details.</t>
</section>
<section anchor='tls-unique' title="The 'tls-unique' Channel Binding Type">
<t>IANA is hereby directed to update the registration of the
'tls-unique' channel binding type to match the
following. There are material and substantial changes
from the original registration, both in the description
as well as registration meta-data (such as registration
ownership).</t>
<section title="Description">
<t>Description: The first TLS Finished message sent
(note: the Finished struct) in the most recent TLS
handshake of the TLS connection being bound to
(note: TLS connection, not session, so that the
channel binding is specific to each connection
regardless of whether session resumption is used).
If TLS re-negotiation takes place before the channel
binding operation, then the first TLS Finished
message sent of the latest/inner-most TLS connection
is used. Note that for full TLS handshakes the
first Finished message is sent by the client, while
for abbreviated TLS handshakes (session resumption)
the first Finished message is sent by the
server.</t>
<t>Interoperability note: this definition of tls-unique
means that the channel's bindings data may change
over time, which in turn creates a synchronization
problem should the channel's bindings data change
between the time that the client initiates
authentication with channel
binding and the time that the server begins to
process the client's first authentication message.
If that happens the authentication will fail
spuriously. To avoid this problem client
applications SHOULD ensure that TLS re-negotiation
does not occur between the start and completion of
authentication.</t>
<t>WARNING: The definition, security and
interoperability considerations of this channel
binding type have changed since the original
registration. Implementors should read the document
that last updated this registration for more
information.</t>
</section>
<section title="Registration">
<t> <list style='symbols'>
<t>Channel binding unique prefix: tls-unique</t>
<t>Channel binding type: unique</t>
<t>Channel type: TLS <xref
target='RFC5246'/></t>
<t>Published specification: <this
document></t>
<t>Channel binding is secret: no</t>
<t>Description: <See specification></t>
<t>Intended usage: COMMON</t>
<t>Person and email address to contact for
further information: Larry Zhu
(lzhu@microsoft.com), Nicolas Williams
(Nicolas.Williams@sun.com).</t>
<t>Owner/Change controller name and email
address: IESG.</t>
<t>Expert reviewer name and contact information:
IETF TLS WG (tls@ietf.org, failing that,
ietf@ietf.org)</t>
<t>Note: see the published specification for
advice on the applicability of this channel
binding type.</t>
</list>
</t>
</section>
</section>
<section title="The 'tls-server-end-point' Channel Binding Type">
<t>IANA is hereby directed to update the registration of the
'tls-server-end-point' channel binding type to match the
following. Note that the only material changes from the
original registration should be: the "owner" (now the
IESG), the contacts, the published specfication, and a
note indicating that the published specification should
be consulted for applicability advice. References were
added to the description. All other fields of the
registration are copied here for the convenience of
readers.</t>
<section anchor="tsep-desc" title="Description">
<t>Description: The hash of the TLS server's certificate
[RFC5280] as it appears, octet for octet, in the
server's Certificate message (note that the
Certificate message contains a certificate_list, the
first element of which is the server's
certificate).</t>
<t>The hash function is to be selected as follows:</t>
<t>
<list style='symbols'>
<t>if the certificate's signatureAlgorithm uses
a single hash function, and that hash
function is either MD5 <xref
target="RFC1321"/> or SHA-1 <xref
target="RFC3174"/> then use SHA-256
<xref target="FIPS-180-2"/>;</t>
<t>if the certificate's signatureAlgorithm uses
a single hash function and that hash
function neither MD5 nor SHA-1, then use the
hash function associated with the
certificate's signatureAlgorithm;</t>
<t>if the certificate's signatureAlgorithm uses
no hash functions or multiple hash
functions, then this channel binding type's
channel bindings are undefined at this time
(updates to is channel binding type may
occur to address this issue if it ever
arises).</t>
</list>
</t>
<t>The reason for using a hash of the certificate is
that some implementations need to track the channel
binding of a TLS session in kernel-mode memory,
which is often at a premium.</t>
</section>
<section title="Registration">
<t>
<list style='symbols'>
<t>Channel binding unique prefix:
tls-server-end-point</t>
<t>Channel binding type: end-point</t>
<t>Channel type: TLS <xref
target='RFC5246'/></t>
<t>Published specification: <this
document></t>
<t>Channel binding is secret: no</t>
<t>Description: <See specification></t>
<t>Intended usage: COMMON</t>
<t>Person and email address to contact for
further information: Larry Zhu
(lzhu@microsoft.com), Nicolas Williams
(Nicolas.Williams@sun.com).</t>
<t>Owner/Change controller name and email
address: IESG.</t>
<t>Expert reviewer name and contact information:
IETF TLS WG (tls@ietf.org, failing that,
ietf@ietf.org)</t>
<t>Note: see the published specification for
advice on the applicability of this channel
binding type.</t>
</list>
</t>
</section>
</section>
<section title="The 'tls-unique-for-telnet' Channel Binding Type">
<t>IANA is hereby directed to update the registration of the
'tls-unique-for-telnet' channel binding type to match
the following. Note that the only material changes from
the original registration should be: the "owner" (now
the IESG), the contacts, the published specfication, and
a note indicating that the published specification
should be consulted for applicability advice. The
description is also clarified. We also moved security
considerations notes to the security considerations
section of this document. All other fields of the
registration are copied here for the convenience of
readers.</t>
<section title="Description">
<t>Description: There is a proposal for adding a
"StartTLS" extension to TELNET, and a channel
binding extension for the various TELNET AUTH
mechanisms whereby each side sends the other a
"checksum" (MAC) of their view of the channel's
bindings. The client uses the TLS Finished
messages (note: the Finished struct) sent by the
client and server, each concatenated in that order
and in their clear text form, of the first TLS
handshake of the connection being bound to. The
server does the same but in the opposite
concatenation order (server, then client).</t>
</section>
<section title="Registration">
<t>
<list style='symbols'>
<t>Channel binding unique prefix:
tls-unique-for-telnet</t>
<t>Channel binding type: unique</t>
<t>Channel type: TLS <xref
target='RFC5246'/></t>
<t>Published specification: <this
document></t>
<t>Channel binding is secret: no</t>
<t>Description: <See specification></t>
<t>Intended usage: COMMON</t>
<t>Person and email address to contact for
further information: Jeff Altman
(jaltman@secure-endpoints.com), Nicolas
Williams (Nicolas.Williams@sun.com).</t>
<t>Owner/Change controller name and email
address: IESG.</t>
<t>Expert reviewer name and contact information:
IETF TLS WG (tls@ietf.org, failing that,
ietf@ietf.org)</t>
<t>Note: see the published specification for
advice on the applicability of this channel
binding type.</t>
</list>
</t>
</section>
</section>
<section title="Applicability of TLS Channel Binding Types">
<t>The 'tls-unique-for-telnet' channel binding type is only
applicable to TELNET <xref target="RFC0854"/>, and is
available for all TLS connections.</t>
<t>The 'tls-unique' channel binding type is available for
all TLS connections, while 'tls-server-end-point' is
only available when TLS cipher suites with server
certificates are used, specifically: cipher suites that
use the Certificate handshake message, which
typically involve the use of PKIX <xref
target='RFC5280'/>. For example,
'tls-server-end-point' is available when using TLS
ciphers suites such as (this is not an exhaustive list):
<list style='symbols'>
<t>TLS_DHE_DSS_WITH_*</t>
<t>TLS_DHE_RSA_WITH_*</t>
<t>TLS_DH_DSS_WITH_*</t>
<t>TLS_DH_RSA_WITH_*</t>
<t>TLS_ECDHE_ECDSA_WITH_*</t>
<t>TLS_ECDHE_RSA_WITH_*</t>
<t>TLS_ECDH_ECDSA_WITH_*</t>
<t>TLS_ECDH_RSA_WITH_*</t>
<t>TLS_RSA_PSK_WITH_*</t>
<t>TLS_RSA_WITH_*</t>
<t>TLS_SRP_SHA_DSS_WITH_*</t>
<t>TLS_SRP_SHA_RSA_WITH_*</t>
</list>
but is not available when using TLS cipher suites such
as (this is not an exhaustive list):
<list style='symbols'>
<t>TLS_DHE_PSK_WITH_*</t>
<t>TLS_DH_anon_WITH_*</t>
<t>TLS_ECDHE_PSK_WITH_*</t>
<t>TLS_ECDH_anon_WITH_*</t>
<t>TLS_KRB5_WITH_*</t>
<t>TLS_PSK_WITH_*</t>
<t>TLS_SRP_SHA_WITH_*</t>
</list>
Nor is this channel binding type available for use with
OpenPGP server certificates <xref target='RFC5081'/>
<xref target='RFC4880'/> (since these don't use the
Certificate handshake message).
</t>
<t>Therefore 'tls-unique' is generally better than
'tls-server-end-point'. However, 'tls-server-end-point'
may be used with existing TLS server-side proxies
("concentrators") without modification to the proxies,
whereas 'tls-unique' may require firmware or software
updates to server-side proxies. Therefore there may be
cases where 'tls-server-end-point' may interoperate but
where 'tls-unique' may not.</t>
<t>Also, authentications mechanisms may arise which depend
on channel bindings to contribute entropy, in which case
unique channel bindings would have to always be used in
preference to end-point channel bindings. At this time
there are no such mechanisms, though one such SASL
mechanism has been proposed. Whether such mechanisms
should be allowed is out of scope for this document.</t>
<t>In other words, for many applications there may be two
potentially applicable TLS channel binding types.
Channel binding is all or nothing for the GSS-API <xref
target="RFC2743"/>, and likely other frameworks.
Therefore agreement on the use of channel binding, and a
particular channel binding type is necessary. Such
agreement can be obtained a priori, by convention, or
negotiated.</t>
<t>The specifics of whether and how to negotiate channel
binding types are beyond the scope of this document.
However, it is RECOMMENDED that application protocols
making use of TLS channel bindings, use 'tls-unique'
exclusively, except, perhaps, where server-side proxies
are common in deployments of an application protocol.
In the latter case an application protocol MAY specify
that 'tls-server-end-point' channel bindings must be
used when available, with 'tls-unique' being used when
'tls-server-end-point' channel bindings are not
available. Alternatively, the application may negotiate
which channel binding type to use, or may make the
choice of channel binding type configurable.</t>
<t>Specifically, application protocol specifications MUST
indicate at least one mandatory to implement channel
binding type, MAY specify a negotiation protocol, MAY
allow for out-of-band negotiation or configuration, and
SHOULD have a preference for 'tls-unique' over
'tls-server-end-point'.</t>
</section>
<section title="Required Application Programming Interfaces">
<t>TLS implementations supporting the use of 'tls-unique'
and/or 'tls-unique-for-telnet' channel binding types,
MUST provide application programming interfaces by which
applications (clients and servers both) may obtain the
channel bindings for a TLS connection. Such interfaces
may be expressed in terms of extracting the channel
bindings data for a given connection and channel binding
type. Alternatively the implementor may provide
interfaces by which to obtain the initial client
Finished message, the initial server Finished message
and/or the server certificate (in a form that matches
the description of the 'tls-server-end-point' channel
binding type). In the latter case the application has
to have knowledge of the channel binding type
descriptions from this document. This document takes no
position on which form these application programming
interfaces must take.</t>
</section>
<section anchor="changes" title="Description of backwards-incompatible changes made herein to 'tls-unique'">
<t>The original description of 'tls-unique' read as follows:
</t>
<figure title="Original 'tls-unique' description">
<artwork>
|OLD| Description: The client's TLS Finished message (note: the
|OLD| Finished struct) from the first handshake of the connection
|OLD| (note: connection, not session, so that the channel binding
|OLD| is specific to each connection regardless of whether session
|OLD| resumption is used).
</artwork>
</figure>
<t>In other words: the client's Finished message from the
first handhske of a connection, regardless of whether
that handshake was a full or abbreviated handshake, and
regardless of how many subsequent handshakes
(re-negotiations) might have followed.</t>
<t>As explained in <xref target="intro"/> this is no longer
the description of 'tls-unique', and the new description
is not backwards compatible with the original except in
the case of TLS connections where: a) only one handshake
has taken place before application-layer authentication,
and b) that one handshake was a full handshake.</t>
<t>This change has a number of implications:
<list style='symbols'>
<t>Backwards-incompatibility. It is possible that
some implementations of the original
'tls-unique' channel binding type may have been
deployed. We know of at least one TLS
implementation that exports 'tls-unique' channel
bindings with the original semantics, but we
know of no deployed application using the
same. Implementations of the original and new
'tls-unique' channel binding type will only
interoperate when: a) full TLS handshakes are
used, b) TLS re-negotiation is not used.</t>
<t>Security considerations -- see <xref
target='seccons'/>.</t>
<t>Interoperability considerations. As described in
<xref target='tls-unique'/> the new definition
of the 'tls-unique' channel binding type has an
interoperability problem that may result in
spurious authentication failures unless the
client implements the technique described in
that section.</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>The IANA is hereby directed to update three existing
channel binding type registrations. See the rest of
this document.</t>
</section>
<section anchor='seccons' title="Security Considerations">
<t>The Security Considerations sections of <xref
target="RFC5056"/>, <xref target="RFC5246"/> and
<xref target="RFC5746"/> apply to this document.</t>
<t>The TLS Finished messages (see section 7.4.9 of <xref
target="RFC5246"/>) are known to both endpoints of a
TLS connection, and are cryptographycally bound to it.
For implementations of TLS that correctly handle
re-negotiation <xref target="RFC5746"/> each handshake
on a TLS connection is bound to the preceding handshake,
if any. Therefore the TLS Finished messages can be
safely used as a channel binding provided that the
authentication mechanism doing the channel binding
conforms to the requirements in <xref
target='RFC5056'/>. Applications utilizing
'tls-unique' channel binding with TLS implementations
without support for secure re-negotiation <xref
target="RFC5746"/> MUST ensure that that
ChangeCipherSpec has been used in any and all
re-negotiations prior to application-layer
authentication, and MUST discard any knowledge learned
from the server prior to the completion of
application-layer authentication.</t>
<t>The server certificate, when present, is also
cryptographically bound to the TLS connection through
its use in key transport and/or authentication of the
server (either by dint of its use in key transport, by
its use in signing key agreement, or by its use in key
agreement). Therefore the server certificate is
suitable as an end-point channel binding as described in
<xref target='RFC5056'/>.</t>
<section title="Cryptographic Algorithm Agility">
<t>The 'tls-unique' and 'tls-unique-for-telnet' channel
binding types do not add any use of cryptography
beyond that used by TLS itself. Therefore these two
channel binding types add no considerations with
respect to cryptographic algorithm agility.</t>
<t>The 'tls-server-end-point' channel binding type
consist of a hash of a server certificate. The
reason for this is to produce manageably small
channel binding data, as some implementations will
be using kernel-mode memory (which is typically
scarce) to store these. This use of a hash
algorithm is above and beyond TLS's use of
cryptography, therefore the 'tls-server-end-point'
channel binding type has a security consideration
with respect to hash algorithm agility. The
algorithm to be used, however, is derived from the
server certificate's signature algorithm as
described in <xref target="tsep-desc"/>; to recap:
use SHA-256 if the certificate signature algorithm
uses MD5 or SHA-1, else use whatever hash function
the certificate uses (unless the signature algorithm
uses no hash functions or more than one hash
function, in which case 'tls-server-end-point' is
undefined). This construction automatically makes
'tls-server-end-point' hash algorithm agile, with a
dependency on PKIX and TLS for hash agility.</t>
<t>Current proposals for randomized signatures
algorithms <xref target="I-D.irtf-cfrg-rhash"/>
<xref target="NIST-SP.800-106.2009"/> use hash
functions in their construction -- a single hash
function in each algorithm. Therefore the
'tls-server-end-point' channel binding type should
be available even in cases where new signatures
algorithms are used that are based on current
randomized hashing proposals (but we cannot
guarantee this, of course).</t>
</section>
<section title="On Disclosure of Channel Bindings Data by
Authentication Mechanisms">
<t>When these channel binding types were first
considered, one issue that some commenters were
concerned about was the possible impact on the
security of the TLS channel, of disclosure of the
channel bindings data by authentication mechanisms.
This can happen, for example, when an authentication
mechanism transports the channel bindings data, with
no confidentiality protection, over other transports
(for example, in communicating with a trusted third
party), or when the TLS channel provides no
confidentiality protection and the authentication
mechanism does not protect the confidentiality of
the channel bindings data. This section considers
that concern.</t>
<t>When the TLS connection uses a cipher suite that does
not provide confidentiality protection, the TLS
Finished messages will be visible to eavesdroppers,
regardless of what the authentication mechanism
does. The same is true of the server certificate
which, in any case, is generally visible to
eavesdroppers. Therefore we must consider our
choices of TLS channel bindings here to be safe to
disclose by definition -- if that were not the case
then TLS with cipher suites that don't provide
confidentiality protection would be unsafe.
Furthermore, the TLS Finished message construction
depends on the security of the TLS PRF, which in
turn needs to be resistant to key recovery attacks,
and we think that it is, as it is based on HMAC, and
the master secret is, well, secret (and the result
of key exchange).</t>
<t>Note too that in the case of an attempted active
man-in-the-middle attack, the attacker will already
possess knowledge of the TLS finished messages for
both inbound and outbound TLS channels (which will
differ, given that the attacker cannot force them to
be the same). No additional information is obtained
by the attacker from the authentication mechanism's
disclosure of channel bindings data -- the attacker
already has it, even when cipher suites providing
confidentiality protection are provided.</t>
<t>None of the channel binding types defined herein
produce channel bindings data that must be kept
secret. Moreover, none of the channel binding types
defined herein can be expected to be private (known
only to the end-points of the channel), except that
the unique TLS channel binding types can be expected
to be private when a cipher suite that provides
confidentiality protection is used to protect the
Finished message exchanges and the application data
records containing application-layer authentication
messages.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;&rfc5056;&rfc5246;&rfc5746;
</references>
<references title="Normative References for 'tls-server-end-point'">
<reference anchor='FIPS-180-2'>
<front>
<title>Secure Hash Standard (Federal Information
Processing Standard (FIPS) 180-2</title>
<author>
<organization
abbrev='NIST'>United States of America,
National Institute of Standards and
Technology</organization>
</author>
</front>
<format
type='PDF'
target='http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf'/>
</reference>
</references>
<references title="Informative References">
&rfc0854;&rfc1321;&rfc2743;&rfc3174;&rfc4880;&rfc5081;&rfc5280;&rhash;
<reference anchor="NIST-SP.800-106.2009">
<front>
<title>NIST Special Publication 800-106: Randomized
Hashing for Digital Signatures</title>
<author>
<organization>National Institute of Standards
and Technology</organization>
</author>
<date month="February" year="2009"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:29 |