One document matched: draft-altman-tls-channel-bindings-04.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'>
]>
<?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="trust200902" docName="draft-altman-tls-channel-bindings-04.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="Sun">Sun Microsystems</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@sun.com</email>
</address>
</author>
<date month="June" year="2009"/>
<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 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. 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>
</section>
<section 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. Note that the only material changes from the
original registration should be: the "owner" (now the
IESG), contacts, the published specfication, and a
clarification to the description by the addition of a
parenthetical note (that is, the first such note in the
descritption is a new addition). We also added a note
indicating that this specification contains
applicability advice, and we 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>
<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: The client's TLS Finished message (note:
the Finished struct) from the first handshake of the
connection (note: connection, not session, so that
the channel binding is specific to each connection
regardless of whether session resumption is
used).</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
(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 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>
<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: The hash of the TLS server's end
entity certificate <xref target='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 end entity
certificate.) The hash function to be selected
is as follows: if the certificate's signature
hash algorithm is either MD5 <xref
target='RFC1321'/> or SHA-1 <xref
target='RFC3174'/>, then use SHA-256 <xref
target="FIPS-180-2"/>, otherwise use the
certificate's signature hash algorithm.
<vspace blankLines='1'/>
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>
<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 (ietf@ietf.org)</t>
<t>Note: This channel binding is only suitable for
use with PKIX server certificates <xref
target='RFC5280'/>, not OpenPGP certificates
<xref target='RFC5081'/> <xref
target='RFC4880'/>.</t>
<t>Note: see the published specification for advice
on the applicability of this channel binding
type.</t>
</list>
</t>
</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>
<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: 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 first TLS Finished
messages (note: the Finished struct) from the
client and server, each concatenated in that
order and in their clear text form. The server
does the same but in the opposite concatenation
order (server, then client).</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
(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 title="Applicability of TLS Channel Binding Types">
<t>The 'tls-unique-for-telnet' channel binding type is only
applicable to TELNET <xref target="RFC0854"/>.</t>
<t>The 'tls-unique' channel binding type is always available
for TLS connections, while 'tls-server-end-point' is
only available when TLS cipher suites with server
certificates are used. 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 are cases where
'tls-server-end-point' may interoperate but where
'tls-unique' may not.</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 a priori 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 prefer '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 may obtain the channel bindings for a TLS
connection. An implementation MAY provide interfaces
for obtaining the initial Finished messages of a
connection separately, letting TELNET <xref
target="RFC0854"/> construct 'tls-unique-for-telnet'
channel bindings from those, or the implementation MAY
provide an interface specifically for extracting channel
bindings data from a connection, and for a given channel
binding type.</t>
<t>TLS implementations supporting the use of
'tls-server-end-point' channel bindings MUST provide
application programming interfaces to obtain this
channel binding. Such an interface SHOULD produce the
'tls-server-end-point' channel bindings data directly,
but MAY produce the certificate of the server for the
connection instead, as it appears, octet for octet, in
the server's Certificate message. When a connection
results from TLS session resumption, the implementation
may need to have cached the server certificate from the
original connection, but MAY return an error instead of
the channel binding or server certificate. Applications
wishing to use 'tls-server-end-point' channel bindings
and TLS session resumption MUST be prepared to handle
the unavailability of 'tls-server-end-point' channel
bindings in the case of TLS session resumption.</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 title="Security Considerations">
<t>The Security Considerations section of <xref
target="RFC5056"/> applies 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.
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'/>.</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. 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
certificate itself: use SHA-256 if the certificate
uses MD5 or SHA-1, else use whatever hash function
the certificate uses. This construction
automatically makes 'tls-server-end-point' hash
algorithm agile.</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>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;&rfc5056;&rfc5246;
</references>
<references title="Normative References for 'tls-server-end-point'">
&rfc5280;
<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;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:17 |