One document matched: draft-ietf-sasl-channel-bindings-00.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-00.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 the introduction into SASL of an abstract
		interface to channel binding <xref
		    target='RFC5056'/>.</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 title="Channel Binding Semantics and Negotiation for SASL">

	    <t>In order to use SASL <xref target='RFC4422'/> with
		channel binding the client and server applications MUST
		provide a channel binding type and channel binding data
		to the selected SASL mechanism before the first
		mechanism's authentication message is produced (client
		side) or consumed (server side).  Channel binding
		failure MUST cause authentication failure.</t>

	    <t>Use of channel binding must be negotiable.  The client need
		not use channel binding, and the server may not support
		the use of channel binding.  But because channel binding
		is all or nothing we need a method for negotiating its
		used.  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 channel binding MUST specify two
		mechanism names: one that indicates server support for
		channel binding, and one that indicates the
		opposite.  We RECOMMEND the use of a mechanism name suffix,
		specifically "-PLUS" to indicate server support for
		channel binding..</t>

	    <t>A 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.  A
		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>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.  Henceforth any SASL mechanism
		registration MUST indicate a) whether the mechanism
		supports channel binding, and, if it does, b) 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"/>.</t>

        </section>

    </middle>

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

</rfc>