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.

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.

Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:0" 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).

Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered.

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.

The Service Name used by XMPP is unchanged from RFC 6120.

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, which is used to indicate no data (ie, the absence of the data). In order to explicitly transmit a zero-length SASL challenge or response, the sending party sends a single equals sign character ("=").

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.

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.

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.

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:

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.

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.

Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication.

The service name SHALL be "xmpp", as defined by RFC 6120.

Servers list mechanisms during stream features (See ) and within the <continue/> element (See ).

TODO: Neither this specification nor RFC 6120 allow clients access to the mechanism list after SASL negotiation...?

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.

Clients MAY abort unilaterally by sending <abort/> as specified in .

Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in .

See .

Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last.

Although the <continue/> concept does use multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer.

In particular, once <success/> has been sent by the server, any further <authenticate/> element MUST result in a stream error.