<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 <authentication/>, qualified by the "urn:xmpp:sasl:2" 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 &xep0233;). The mechanism elements MUST only offer mechanisms the server can offer for the JID provided by the client in the "from" attribute of the stream-header. If that atrribute is omitted or does not contain a recognised bare JID, the server SHOULD only offer mechanisms it can provide independently of the JID. Note that varying responses based on whether an account exists or not may leak the existence of accounts to unauthorized parties. See the security considerations section for more information. If the "from" attribute is not empty and the domain used in this attribute does not match the domain used in the "to" attribute the server SHOULD respond with an invalid-from error as defined in §4.9.3.9 of &rfc6120;.</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>Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered if not at least one mechanism can be provided.</p>
<p>The Service Name used by XMPP is unchanged from &rfc6120;.</p>
<p>All servers and clients supporting channel-binding MUST implement &xep0440;.</p>
<p>Additional stream features that can be negotiated as part of a successful SASL authentication can be included in the <inline/> element which is an immediate child of <authentication/>.</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 this, 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. If the "mechanism" attribute contains a string not previously announced by the server in in the stream feature, the server MUST fail the authentication.</p>
<p>If the stream's from attribute (if present) does not match the non-empty authorization string, the server MUST fail the authentication as defined in <linkurl="#failure">Failure</link>.</p>
<p>Clients SHOULD also include a <user-agent/> element, informing the server about the connecting client. The 'id' attribute is RECOMMENDED, and if present contains a unique stable identifier for the client installation. The contents of the 'id' attribute MUST be a UUID v4. This allows the server to provide functionality such as deriving stable resource identifiers (see &xep0386;). The child elements <software/> and <device/> MAY be supplied by clients and contain text descriptions of the client software and the device it is installed on. These allow the server to keep the user informed about what devices are connected to their account. Servers MUST NOT expose this information to other entities (such functionality is available in &xep0092; if required).</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"><