One document matched: draft-ietf-sasl-channel-bindings-02.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 scram PUBLIC   '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.newman-auth-scram.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 symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<rfc updates='rfc4422' category="std" ipr="trust200902" docName="draft-ietf-sasl-channel-bindings-02.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.</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'/>.</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 order to use SASL <xref target='RFC4422'/> with
		channel binding <xref target='RFC5056'/> the client and
		server applications MUST provide the SASL mechanism with
		channel bindings data and channel binding type names for
		all available channel binding types for the channel to
		be bound.  These channel bindings data MUST be provided
		to the mechanism before the first authentication message
		is produced or consumed by the mechanism.  The mechanism
		MUST use at least one, and MAY use more than one of the
		provided channel binding types.</t>
	    
	    <t>Channel binding is OPTIONAL, but when used, channel
		binding failure MUST cause authentication failure.</t>

	    <t>Use of channel binding must be negotiable.  Either or
		both of the client and server might not support channel
		binding in any given exchange.  But because channel
		binding is all or nothing we need a method for
		negotiating its use.  We accomplish this by using a
		convention by which the server can indicate whether it
		supports channel binding in its mechanism list.  That
		is, we overload the mechanism negotiation to obtain
		channel binding negotiation.</t>

	    <t>The convention is that the specification for any SASL
		mechanism that supports optional channel binding MUST
		specify two mechanism names: one that indicates server
		support for channel binding, and one that indicates the
		opposite.  Otherwise these two names MUST be equivalent.
		Mechanisms that require the use of channel bindings
		SHOULD have a single mechanism name.  We RECOMMEND the
		use of a mechanism name suffix, specifically "-PLUS" to
		indicate server support for channel binding.</t>

	    <t>The server MUST NOT advertise mechanism names indicating
		support for channel binding if the server application or
		the mechanism implementations do not support channel
		binding.  Conversely, the server MUST advertise
		mechanism names indicating support for channel binding
		if the server application and the mechanism
		implementations do support channel binding.</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.</t>

	</section>

        <section title="IANA Considerations">

	    <t>This document changes the procedures for registration of
		SASL mechanism names in the IANA SASL mechanism name
		registry.  Henceforth any SASL mechanism registration
		MUST indicate a) whether the mechanism supports channel
		binding, b) whether it requires channel binding, and, if
		the mechanism supports optional channel binding then c)
		two mechanism names and an indication of which name
		indicates server support for channel binding.</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 channel binding is 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>

        </section>

    </middle>

    <back>
        <references
            title="Normative References">&rfc2119;&rfc4422;&rfc5056;</references>
        <references
            title="Informative References">&scram;&gs2;</references>
    </back>

</rfc>