<p>While SASL provides an excellent framework that has served us well over the past 18 years, a number of shortcomings in the profile - the syntax binding to XMPP - that is in use.</p>
<p>This specification addresses a number of shortfalls:</p>
<ul>
<li>Number of round trips</li>
<li>Extensibility</li>
<li>Support for second factor</li>
<li>Support for mandatory password changes</li>
</ul>
<p>The new SASL profile documented herein is primarily a syntactic change to allow extensibility, combined with removal of the (largely) redundant stream restart, and additional results beyond total success or abject failure.</p>
<section2topic="Terminology">
<p>Although initiating entities, in general, use SASL, and receiving entities offer it, the SASL specification and common parlance both use "Client " and "Server"; this specification uses Client and Server and assumes C2S links. This is not intended to preclude use of this SASL profile on S2S links. The term "SASL2" is used to mean the new SASL profile specified in this document; however the same RFC 4422 definition of SASL (and SASL profiles) applies.</p>
<p>Examples often use hypothetical SASL mechanisms and sub-extensions; this specification does not intend to make a position on any particular SASL mechanism, and the Mandatory To Implement mechanisms are unaffected.</p>
<p>Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:1" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233).</p>
<p>Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered.</p>
<p>The feature so advertised, and its child content, SHOULD be stable for the given stream to and from attributes and encryption state, and therefore MAY be cached by clients for later connections.</p>
<p>The Service Name used by XMPP is unchanged from RFC 6120.</p>
<p>In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string. Challenges and responses with no data do not occur in SASL, and so require no special handling. To indicate the absence of an initial response, or the absence of success data, the element is simply not included.</p>
<p>Clients, upon observing this stream feature, initiate the authentication by the use of the <authenticate/> top-level element, within the same namespace. The nature of this element is to inform the server about properties of the final stream state, as well as initiate authentication itself. To achieve the latter, it has a single mandatory attribute of "mechanism", with a string value of a mechanism name offered by the Server in the stream feature, and an optional child element of <initial-response/>, containing a base64-encoded SASL Initial Response.</p>
<p>On subsequent connections, if a Client has previously cache the stream feature, the Client MAY choose to send it before seeing the stream features - sending it "pipelined" with the Stream Open tag for example.</p>
<p>In order to provide support for other desired stream states beyond authentication, additional child elements are used. For example, a hypothetical XEP-0198 session resumption element might be included, and/or Resource Binding requests.</p>
<examplecaption="An authentication request with a (hypothetical) bind request"><![CDATA[
<section2topic="Challenges and Responses"anchor="challenge">
<p>Server Challenges MAY then be sent. Each Challenge MUST be responded to by a Client in a Client Response. These are not extensible, and contain the corresponding base64 encoded SASL data:</p>
<examplecaption="A challenge and response exchange"><![CDATA[
<p>At any time while authentication is in progress, neither Client nor Server sends any element (including stanzas) or other data except the top-level elements defined herein. Clients MUST NOT send whitespace, and MUST send only <response/> elements as appropriate or an <abort/> element to immediately cause an error. Servers MUST disconnect Clients immediately if any other traffic is received. Servers are similarly REQUIRED to send no whitespace, and only the <response/> and completion elements from the section below.</p>
</section2>
<section2topic="Completing Authentication">
<p>Authentication may complete in one of three ways. It may complete successfully, in which case the client is authenticated. It may also fail, in which case the client is not authenticated and the stream and session state remain entirely unchanged.</p>
<p>Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication.</p>
<p>If the Client is now authenticated, the Server sends a <success/> element, which contains contains an <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID.</p>
<p>It MAY contain an <additional-data> element, containing additional data from the exchange (task or SASL mechanism) that has just completed.</p>
<p>Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>"), if it has not already taken effect at a <continue> - see <linkurl='#continue'>Continue</link> below.</p>
<p>The <success> element is immediately followed by a <features> element containing the applicable stream features of the newly authenticated stream. Note that no stream restart occurs.</p>
<p>A <failure/> element is used by the server to terminate the authentication attempt. It MAY contain application-specific error codes, and MAY contain a textual error. It MUST contain one of the SASL error codes from RFC 6120 Section 6.5.</p>
<p>A <continue/> element is used to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time.</p>
<p>This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password.</p>
<p>Such tasks are presented within a <tasks> element, which contains a sequence of <task> elements, each containing a name. These tasks are analogous to a SASL mechanism, but have a number of differences - they may never attempt to negotiate a new authorization identifier, nor a new security layer.</p>
<p>A client MAY choose any one of the offered tasks; if multiple are required a sequence of <continue> exchanges will occur until all mandatory tasks are complete.</p>
<p>The <continue element therefore always contains a <tasks/> element, as defined above. It MAY contain an <additional-data/> element, as the <success/> element does.</p>
<p>After the final octet of the first <continue> element, any SASL security layer negotiated in the preceding exchange SHALL be immediately in effect.</p>
<p>Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and contains an OPTIONAL base64 encoded initial response contained in an <initial-response> element.</p>
<p>This provides pointers and/or clarifications to the <linkurl="#overview">Overview</link> in the order and manner defined in RFC 4422, section 4.</p>
<p>If a Client specifies an authorization string which is non-empty, the identifier is normalized by treating it as a JID, and performing normalization as described in RFC 7622.</p>
<p>In general, implementors are advised that a non-empty authorization string MAY be considered an error if the stream's from attribute (if present) does not match.</p>
<p>Security Layers take effect after the SASL mechanism itself (ie, the first negotiation) has completed successfully, after the final octet of the server's <success> or <continue>. See <linkurl="#success">Success</link> and <linkurl="#continue">Continue</link>.</p>
<p>Although the <continue/> concept does use tasks analogous to multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer.</p>
<p>This section provides a fictional example. It is important to note that many of the extensions used wihtin this section do not, in fact, exist and therefore are to be avoided.</p>
<section2topic="Syntactic Equivalence">
<p>Where no additional features that SASL2 makes available are used, the flow of information is identical to the original SASL profile. This example shows the new syntax and draws the reader's attention to the differences.</p>
<examplecaption="PLAIN Authentication"><![CDATA[
<!--
Server sends stream features.
These are identical to SASL1, but within a different namespace.
-->
<stream:features>
<mechanismsxmlns='urn:xmpp:sasl:1'>
<mechanism>PLAIN</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
</mechanisms>
</stream:features>
<!--
Client intiates authentication.
Beyond the element local name and namespace,
the main distinction is that initial-response data is held within an element,
The server immediately sends a new set of stream features at this point.
There is no stream restart.
-->
<stream:features>
<bindxmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<required/>
</bind>
</stream:features>
<!--
The client now continues with resource binding.
-->
]]></example>
<p>Use of SASL2 in this simple scenario again simply saves one round-trip.</p>
</section2>
<section2topic="Advanced Usage">
<p>This moves into the deeply hypothetical. A binding extension is posited, alongside an unrealistic 2FA mechanism which somehow mutually authenticates because why not.</p>
Here, we have an authzid which is a full jid, since the session is now bound.
The additional-data element here contains the mutual authentication data for the
unrealistic 2FA, and doesn't refer back to the BLURDYBLOOP exchange.
-->
<successxmlns='urn:xmpp:sasl:1'>
<additional-data>
VW5yZWFsaXN0aWMgMkZBIG11dHVhbCBhdXRoIGRhdGE=
</additional-data>
<authorization-identifier>
alice@example.org/this-one-please
</authorization-identifier>
</success>
<!--
The Server also sends an (empty) features element.
The client can simply continue and send stanzas.
-->
<stream:features/>
]]></example>
<p>Although the unrealistic 2FA here uses 2 round-trips (real ones will probably use one), the embedding of resource binding as shown here means that a second RTT is saved by SASL2, and there's no net change. A more realistic example would see RTTs saved, and additional negotiations could be added to further reduce RTTs.</p>
<p>While no actual exchanges are introduced that are unprotected, the nature of this exchange might allow for (for example) a resource binding extension to be introduced.</p>
<p>The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, Phil Roberts and Florian Schmaus.</p>
