One document matched: draft-ietf-sasl-channel-bindings-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!-- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4422 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml'>
<!ENTITY rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY scram PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.newman-auth-scram.xml'>
<!ENTITY yap PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zeilenga-sasl-yap.xml'>
<!ENTITY gs2 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sasl-gs2.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc updates='rfc4422' category="std" ipr="trust200902" docName="draft-ietf-sasl-channel-bindings-03.txt">
<front>
<title abbrev="SASL Channel Binding">SASL And Channel Binding</title>
<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="April" year="2009"/>
<area>Security</area>
<workgroup>SASL WG</workgroup>
<keyword>Internet-Draft</keyword>
<abstract><t>This document specifies the semantics of channel
binding for the Simple Authentication and Security
Layers (SASL) framework, mechanisms and applications.
This includes negotiation of channel binding, and
negotiation of channel binding types.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The introduction of the Salted Challenge Response (SCRAM)
SASL mechanism <xref target='I-D.newman-auth-scram'/>
and GS2 family of SASL mechanisms <xref
target='I-D.ietf-sasl-gs2'/> requires that we define
the semantics of channel binding <xref
target='RFC5056'/> in the context of SASL <xref
target='RFC4422'/>. Without such a definition we
risk ending up with mechanism-specific channel binding
code in applications.</t>
<t>In SASL channel bindings are all-or-nothing, and the use
or non-use of channel binding is negotiated via
mechanism negotiation, with downgrade protection built
into mechanisms that support channel binding. See <xref
target='core'/>.</t>
<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>
<section anchor='core' title="Channel Binding Semantics and Negotiation for SASL">
<t>In SASL <xref target='RFC4422'/> channel binding <xref
target='RFC5056'/> is all-or-nothing. If channel
binding is used and channel binding fails then SASL
authentication MUST also fail. This means that
applications either must know a priori whether to use
channel binding, or the must negotiate whether to use
channel binding. To improve interoperability we
therefore provide a method for negotiating the use of
channel binding.</t>
<t>Secure channels may also export multiple types of channel
bindings, such as "unique" channel bindings and
"end-point" channel bindings <xref target='RFC5056'/>.
Since channel binding is a fairly recent addition to
protocols like TLS <xref target='RFC5246'/>, and since
the set of channel binding types is open, it is not
necessarily the case that both ends of a secure
end-to-end channel support the same set of channel
binding types. In order to interoperate it is necessary
that both ends agree on a channel binding type to use.
Also, some SASL mechanisms, such as YAP <xref
target='I-D.zeilenga-sasl-yap'/>, may work only with
"unique" channel bindings, but "end-point" channel
bindings are also quite desirable as they have better
interoperability characteristics when server-side TLS
proxies ("concentrators") are used (see <xref
target='tls-server-end-point'/>). Therefore we also
provide for negotiation of channel binding types.</t>
<section anchor='cbinding_nego' title="Channel Binding Negotiation">
<t>Negotiation of whether to use channel binding is
achieved by overloading the SASL mechanism
negotiation. Each SASL mechanism name MUST imply
whether the channel binding is supported. This
means that mechanisms which support optional use of
channel binding MUST have two SASL mechanism names.
See <xref target='iana'/> for more information.</t>
<t>The server application MUST advertise SASL mechanism
names that correspond to whether the secure channel,
if any, and the application support channel binding;
conversely, the server MUST NOT advertise SASL
mechanism names which indicate the opposite. For
example, if the server has support for SCRAM <xref
target='I-D.newman-auth-scram'/>, there
is a TLS channel, and the server application
supports channel binding, then the server
application must advertise the SCRAM mechanism name
that indicates support for channel binding, and it
must not advertise the SCRAM mechanism name that
indicates the opposite.</t>
<t>The client MUST NOT use channel binding if it lists
the server's mechanisms and does not find a suitable
mechanism that supports channel binding in that
list.</t>
<t>To prevent downgrade attacks each mechanism that
supports channel binding MUST provide downgrade
attack detection. To do this the client application
MUST provide the name of the selected mechanism, or
the server's entire mechanism list, as an input to
the mechanism prior to producing the mechanism's
first authentication message. The mechanism MUST
securely indicate to the server whether the client
a) chose to use channel binding, b) would have
chosen to use channel binding if the server had
supported it, c) cannot do channel binding. In the
case of (c) the server MUST fail authentication if
the server does actually support channel
binding, as that would be an indication of a
downgrade attack.</t>
</section>
<section anchor='cbinding_type_nego' title="Channel Binding Type Negotiation">
<t>The negotiation of what channel binding type to use
is also achieved by overloading the SASL mechanism
negotiation. In this case we use pseudo-mechanism
names to indicate what channel binding types are
available on the server side. See <xref
target='iana'/> for more information on these
pseudo-mechanism names.</t>
<t>The server application SHOULD advertise SASL
pseudo-mechanism names corresponding to the channel
binding types that are available on the server end
of the secure channel to be bound into SASL
authentication.</t>
<t>The IANA registrations of SASL mechanisms that
support channel binding MUST indicate whether the
mechanism requires "unique" channel binding types.
Given this information it is possible for the client
to select a channel binding type that is available
locally and on the server side. If the server did
not advertise any channel binding types but did
advertise mechanisms that support channel binding,
then the client SHOULD assume that all locally
available channel binding types are also available
on the server side.</t>
<t>Whether the application, SASL framework, or SASL
mechanism decides which channel binding type to use
is an implementation detail. An implementation
could have the application provide the server's
mechanism list to a SASL framework which then
decides which channel binding type to use, or
perhaps the framework will then pass that list to
the chosen mechanism which will then in turn decide.
It's also possible to let the application decide.
All three implementation designs are made possible
by including an indication, in a mechanism's SASL
name registration, of whether the mechanism requires
the use of unqieu channel binding types.</t>
<t>The channel binding type negotiation is protected
only by protecting the SASL mechanism name
negotiation, which, if done over the secure channel
is protected by that channel and, therefore, by
channel binding.</t>
<t>Note that while the channel binding negotiation is
done through concrete mechanism name negotiation,
the channel binding type negotiation is done through
pseudo-mechanism names. Both could have been done
via pseudo-mechanism names, however, in the interest
of making the simplest cases simple and obvious we
used concrete mechanism names for the channel
binding negotiation.</t>
</section>
</section>
<section anchor='iana' title="IANA Considerations">
<t>This document changes the procedures for registration of
SASL mechanism names in the IANA SASL mechanism name
registry.</t>
<t>Henceforth any SASL mechanism registration MUST include
one or two mechanism names and an indication of which
name indicates server support for channel binding. Also
REQUIRED of all new SASL mechanism registrations is a
note indicating whether the mechanism requires the use
of channel binding, and another note indicating whether
the mechanism requires the use of unique channel binding
types.</t>
<t>Additionally, the IANA is directed to review and allow
SASL pseudo-mechanism name registrations corresponding
to channel binding types in the IANA channel
binding type registry. The following pseudo-mechanism
names are to be added to the registry immediately:
<list style='symbols'>
<t>'CB-tls-srv-endpoint' (corresponding to the
'tls-server-end-point' <xref
target='tls-server-end-point'/> channel
binding type);</t>
<t>'CB-tls-unique' (corresponding to the
'tls-unique' <xref target='tls-unique'/> channel
binding type).</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>For general security considerations relating to channel
bindings see <xref target="RFC5056"/>. For general
security considerations relating to SASL see <xref
target='RFC4422'/>.</t>
<t>This document specifies how channel binding fits into
SASL and, specifically, the semantics of channel binding
for SASL and how the use of channel binding and which
channel binding type to use are negotiated. The
negotiation of channel binding is subject to downgrade
attacks by active attackers, therefore we include a
requirement that SASL mechanisms provide protection
against downgrade attacks. Protection against downgrade
attacks requires that the application provide certain
information to the SASL mechanism. See <xref
target='core'/>.</t>
<t>The negotiation of channel binding type is protected by
channel binding, assuming that SASL mechanism
negotiation is done with integrity protection from the
secure channel.</t>
</section>
</middle>
<back>
<references
title="Normative References">&rfc2119;&rfc4422;&rfc5056;</references>
<references
title="Informative References">&rfc5246;&scram;&gs2;&yap;
<reference anchor='tls-server-end-point'>
<front>
<title>Registration of TLS server end-point channel bindings</title>
<author initials='L.' surname='Zhu' fullname='Larry Zhu'>
<organization abbrev='MSFT'>Microsoft</organization>
</author>
<date month='July' year='2008'/>
</front>
<format type='TXT' target='http://www.iana.org/assignments/channel-binding-types/tls-server-end-point'/>
</reference>
<reference anchor='tls-unique'>
<front>
<title>Registration of TLS unique channel binding (generic)</title>
<author initials='L.' surname='Zhu' fullname='Larry Zhu'>
<organization abbrev='MSFT'>Microsoft</organization>
</author>
<date month='July' year='2008'/>
</front>
<format type='TXT' target='http://www.iana.org/assignments/channel-binding-types/tls-unique'/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:05:47 |