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.
This specification addresses a number of shortfalls:
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, as well as an upgrade path for different SASL mechanisms.
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.
Clients capable of SASL2 MUST send the desired bare JID they want to authenticate for in the "from" attribute of the stream-header unless they don't know it (e.g. when using the GSS-API SASL mechanism etc.) according to section 4.7.1 of RFC 6120 [3]. 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 RFC 6120 [3]. Providing the bare JID in the "from" attribute saves one round-trip.
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 Use of Domain-Based Service Names in XMPP SASL Negotiation (XEP-0233) [4]). 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.
The <authentication/> element MAY contain a list of <upgrade/> elements each containing a string value of a possible SASL mechanism the client can perform an upgrade task for prefixed with "UPGR-". For more information, see SASL mechanism upgrade tasks.
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.
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.
The Service Name used by XMPP is unchanged from RFC 6120 [3].
All servers and clients supporting channel-binding MUST implement SASL Channel-Binding Type Capability (XEP-0440) [1].
Additional stream features that can be negotiated as part of a successful SASL authentication can be included in the <inline/> element which is a immediate child of <authentication/>.
<?xml version='1.0'?> <stream:stream from='user@example.org' to='example.org' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
<?xml version='1.0'?>
<stream:stream
from='example.org'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='user@example.org'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<authentication xmlns='urn:xmpp:sasl:2'>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<upgrade>UPGR-SCRAM-SHA-256</upgrade>
<inline>
<!-- Server indicates that XEP-0198 stream resumption can be done "inline" -->
<resume xmlns='urn:xmpp:sm:3'/>
<!-- Server indicates support for XEP-0386 Bind 2 -->
<bind xmlns='urn:xmpp:bind2:1'/>
</inline>
</authentication>
<!-- Channel-binding information provided by XEP-0440 -->
<sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'>
<channel-binding type='tls-server-end-point'/>
<channel-binding type='tls-exporter'/>
</sasl-channel-binding>
</stream:features>
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.
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 and possibly ask for an upgrade task for the server-supported SASL mechanisms. 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, an optional attribute of "upgrade", with a string value of a mechanism offered by the Server in an <upgrade/> element in the stream feature, and an optional child element of <initial-response/>, containing a base64-encoded SASL Initial Response. If the "mechanism" or "upgrade" attributes contain a string not previously announced by the server in in the stream feature, the server MUST fail the authentication.
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 Failure.
Clients SHOULD also include a <user-agent/> element, informing the server about the connecting client. The 'id' attribute is RECOMMENDED, and if present it contains a unique stable identifier for the client installation. This allows the server to provide functionality such as deriving stable resource identifiers (see Bind 2.0 (XEP-0386) [5]). The child elements <software/> and <device/> 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 Software Version (XEP-0092) [6] if required).
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='SCRAM-SHA-1-PLUS' upgrade='UPGR-SCRAM-SHA-256'>
<!-- Base64 of: 'p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6' -->
<initial-response>cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNg==</initial-response>
<user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'>
<software>AwesomeXMPP</software>
<device>Kiva's Phone</device>
</user-agent>
</authenticate>
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.
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='BLURDYBLOOP'>
<initial-response>
SSBzaG91bGQgbWFrZSB0aGlzIGEgY29tcGV0aXRpb24=
</initial-response>
<user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'>
<software>AwesomeXMPP</software>
<device>Kiva's Phone</device>
</user-agent>
<bind xmlns='urn:xmpp:bind:example'/>
</authenticate>
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.
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:
<!-- SCRAM-SHA-1-PLUS challenge issued by the server as defined in RFC 5802. Base64 of: 'r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,s=QSXCR+Q6sek8bf92,i=4096' --> <challenge xmlns='urn:xmpp:sasl:2'> cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5Ng== </challenge> <!-- The client responds with the base64 encoded SCRAM-SHA-1-PLUS client-final-message (password: 'pencil'). Base64 of: 'c=cD10bHMtZXhwb3J0ZXIsLMcoQvOdBDePd4OswlmAWV3dg1a1Wh1tYPTBwVid10VU,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,p=UApo7xo6Pa9J+Vaejfz/dG7BomU=' The c-attribute contains the GS2-header and channel-binding data blob (32 bytes) as defined in RFC 5802. --> <response xmlns='urn:xmpp:sasl:2'> Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xNY29Rdk9kQkRlUGQ0T3N3bG1BV1YzZGcxYTFXaDF0WVBUQndWaWQxMFZVLHI9MTJDNENENUMtRTM4RS00QTk4LThGNkQtMTVDMzhGNTFDQ0M2YTA5MTE3YTYtYWM1MC00ZjJmLTkzZjEtOTM3OTljMmJkZGY2LHA9VUFwbzd4bzZQYTlKK1ZhZWpmei9kRzdCb21VPQ== </response>
<!-- A server might send: --> <challenge xmlns='urn:xmpp:sasl:2'> U28sIG5leHQgRk9TREVNIC0gMjAxOCwgdGhhdCBpcy4uLg== </challenge> <!-- A client might respond: --> <response xmlns='urn:xmpp:sasl:2'> Li4uSSdsbCBidXkgYSBiZWVyIGZvciB0aGUgZmlyc3QgcGVyc29uIHdoby4uLg== </response>
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. If the client specified an "upgrade" attribute in its <authenticate/> element, the server MUST send a <continue/> element containing the task the client needs to perform for the upgrade to succeed.
If the Client is now authenticated, the Server sends a <success/> element, which 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.
If the <success/> element it the response to a SASL mechanism exchange, it MAY contain an <additional-data> element, containing additional data from the SASL mechanism that has just completed.
If the <success/> element is the response to a task exchange initiated by a <continue/> element, it MAY contain any other element defined in a future protocol containing additional data from the task that has just completed
If the client requested any stream features inline as part of the SASL negotiation, they are processed by the server at this point.
<success xmlns='urn:xmpp:sasl:2'>
<!-- Base64 of: 'v=msVHs/BzIOHDqXeVH7EmmDu9id8=' -->
<additional-data>
dj1tc1ZIcy9CeklPSERxWGVWSDdFbW1EdTlpZDg9
</additional-data>
<authorization-identifier>user@example.org</authorization-identifier>
</success>
<success xmlns='urn:xmpp:sasl:2'>
<additional-data>
ip/AeIOfZXKBV+fW2smE0GUB3I//nnrrLCYkt0Vj
</additional-data>
<authorization-identifier>juliet@montague.example/Balcony/a987dsh9a87sdh</authorization-identifier>
</success>
The results of activating any requested inline stream features are included in the server's <success/> response.
<success xmlns='urn:xmpp:sasl:2'>
<additional-data>
SGFkIHlvdSBnb2luZywgdGhlcmUsIGRpZG4ndCBJPw==
</additional-data>
<authorization-identifier>juliet@montague.example</authorization-identifier>
<resumed xmlns='urn:xmpp:sm:3' h='345' previd='124'/>
</success>
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 Continue below.
The <success> element is immediately followed by a <features> element in the "http://etherx.jabber.org/streams" namespace containing the applicable stream features of the newly authenticated stream. Note that no stream restart occurs.
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.
The server MUST NOT process any inline features requested by the client in a failed authentication request, if any.
<failure xmlns='urn:xmpp:sasl:2'> <aborted xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <optional-application-specific xmlns='urn:something:else'/> <text>This is a terrible example.</text> </failure>
A <continue/> element is used to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time. This can be used to indicate, for example, that the Client needs to perform a Second Factor Authentication ("2FA"), needs to perform an SASL mechanism upgrade task as requested by the client, or is required to change password (this list is not meant to be exhaustive in any way).
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.
Like the <success/> element, the <continue/> element MAY contain an <additional-data/> element containing additional data from the SASL mechanism that has completed.
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.
The <continue element therefore always contains a <tasks/> element, as defined above. It MAY contain an <additional-data/> element, as the <success/> element does.
Finally, it MAY contain a <text/> element, which can contain human-readable data explaining the nature of the step required.
<continue xmlns='urn:xmpp:sasl:2'>
<additional-data>
SSdtIGJvcmVkIG5vdy4=
</additional-data>
<tasks>
<task>HOTP-EXAMPLE</task>
<task>TOTP-EXAMPLE</task>
</tasks>
<text>This account requires 2FA</text>
</continue>
After the final octet of the first <continue> element, any SASL security layer negotiated in the preceding exchange SHALL be immediately in effect.
Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and MAY contain any other element as defined in a future protocol defining this task.
The concrete elements exchanged for each task after the <next/> reside inside a <task-data/> wrapper element in the namespace "urn:xmpp:sasl:2". Each wrapper element can contain any other element as defined in a future protocol defining this concrete task. Each task MUST end either by the server sending a <failure/> element, if the task failed, a <continue/> element, if the task was completed successfully and the server requests the client to perform a new task, or a <success/> element, indicating that the task was completed successfully and no further tasks are needed.
<next xmlns='urn:xmpp:sasl:2' task='TOTP-EXAMPLE'>
<totp-challenge xmlns="urn:totp:example">
SSd2ZSBydW4gb3V0IG9mIGlkZWFzIGhlcmUu
</totp-challenge>
</next>
<success xmlns='urn:xmpp:sasl:2'>
<totp-response xmlns="urn:totp:example">
SGFkIHlvdSBnb2luZywgdGhlcmUsIGRpZG4ndCBJPw==
</totp-response>
<authorization-identifier>juliet@montague.example</authorization-identifier>
</success>Modern XMPP server deployments typically store only the hash of a user's password, to improve account security. At times, it may be desirable for servers to upgrade to newer or different hash algorithms, e.g. so they can offer different authentication mechanisms for improved security or interoperability. Due to the security properties of one-way cryptographic hash algorithms, it is not possible for the server to extract the original data and simply hash it in a new format. To perform such upgrades, the cooperation of the client is necessary - because it has, or can obtain from the user, the original password to derive a hash from.
As described in the SASL mechanism negotiation section, the server can inform the client of one or more upgrades that need to be performed for the current account. The client SHOULD always request any upgrade task it recognises. To do this, it includes the 'upgrade' attribute in its <authenticate/> element naming the upgrade task it wants to perform, as specified in Initiation.
Upon successfully authenticating the client (including any secondary authentication steps required for the account), but before the final <success/> would be sent, the server sends a <continue/> element, which MUST contain a single task, matching whatever was selected by the client. The client then initiates this upgrade task by providing a corresponding <next/> element providing the task name and optionally including any further child-elements as defined by the specification for the concrete upgrade task.
Upon receiving the <next/> element for the upgrade, the server provides the elements and data needed for the client to calculate the requested data. The concrete elements and exchanges needed for the upgrade are specific to individual tasks. These tasks may be documented in other documents.
Upgrade task names SHOULD have a prefix of "UPGR-" followed by the SASL mechanism name to upgrade to, and if multiple mechanisms differ only in their support for channel-binding (e.g. SCRAM's -PLUS variants), implementations MUST use only the names of variants without channel-binding for the task names, because mechanism upgrades are independent of any channel-binding. Finally, upgrade tasks MUST NOT transmit plaintext passwords (or any reversible encoding of them) if the SASL mechanism to upgrade allows this to be avoided.
<!-- The Server requests the client to perform the upgrade task for BLOOP2 -->
<continue xmlns='urn:xmpp:sasl:2'>
<additional-data>
SSdtIGJvcmVkIG5vdy4=
</additional-data>
<tasks>
<task>UPGR-BLOOP2</task>
</tasks>
<text>This account requires an upgrade to BLOOP2 as requested by the client</text>
</continue>
<!-- The Client initiates the task -->
<next xmlns='urn:xmpp:sasl:2' task='UPGR-BLOOP2'>
<request xmlns='urn:xmpp:bloop2:example'>
UGxlYXNlIHVwZ3JhZGUgbWUh
</request>
</next>
<!-- The Server provides the needed data -->
<task-data xmlns='urn:xmpp:sasl:2'>
<data xmlns='urn:xmpp:bloop2:example'>
<data>U28sIG5leHQgRk9TREVNIC0gMjAxOCwgdGhhdCBpcy4uLg==</data>
<description>BLOOP2 is cool!</description>
</data>
</task-data>
<!-- The Client now responds -->
<task-data xmlns='urn:xmpp:sasl:2'>
<upgrade xmlns='urn:xmpp:bloop2:example'>
<response>Li4uSSdsbCBidXkgYSBiZWVyIGZvciB0aGUgZmlyc3QgcGVyc29uIHdoby4uLg==</response>
<finalize>42</finalize>
</upgrade>
</task-data>
<!-- The upgrade was performed and the Server finishes authentication -->
<success xmlns='urn:xmpp:sasl:2'>
<authorization-identifier>juliet@montague.example</authorization-identifier>
</success>
For compatibility purposes, the server SHOULD keep the older authentication data (password hashes etc.) of all configured mechanisms to continue offering the same mechanisms as before.
Relative to the SASL profile documented in RFC 6120, this introduces more data unprotected by any security layer negotiated by SASL itself.
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.
SASL security layers are sparingly used in the field, however, so this is thought to be a theoretical, rather than practical, concern.
As explained in § 13.8.3 of RFC 6120 [3], servers and clients SHOULD NOT support SASL PLAIN. Usage of PLAIN allows for trivial downgrade atacks by Man-In-The-Middle attackers circumventing any possible channel-binding or mutual authentication and even allowing the attacker to gain access to the cleartext password. If possible, PLAIN should be disabled by default on servers and clients and only be enabled when configured by the admin respective client user (if at all).
This protocol makes use of the hint of its identity contained in the stream "from" attribute as defined in RFC 6120 [3] prior to authentication. This value MUST NOT be trusted to contain the real identity of the connecting client. Varying pre-authentication responses (such as supported SASL mechanisms) based on this value may allow unauthorized parties to discover whether an account exists, and even guess at what software might be used with that account (e.g. by observing whether the client has upgraded to specific mechanisms). Minimizing differences between the default response for unregistered JIDs and registered JIDs, as well as rate-limiting (to prevent enumeration attempts), are possible countermeasures. If the server does not know the client-identity it is RECOMMENDED to randomize the list of provided SASL mechanisms to reduce these risks even further.
SASL2 MUST only be used by Clients or offered by Servers after TLS negotiation, see § 5.2 and § 5.3.4 of RFC 6120 [3].
Clients SHOULD use channel-binding, if available, when requesting an upgrade to make sure no MITM can eavesdrop that hash and subsequently use it for authentication. Note that a client can always choose to not upgrade SASL mechanisms if it can not use channel-binding or the connection is otherwise deemed not secure enough.
Clients MUST NOT send, and servers MUST NOT process, authentication requests included in the TLS 0-RTT ("early data") extension. Such data is vulnerable to replay attacks, and without adequate protection this could allow an attacker to disrupt established sessions or cause other side-effects depending on the inline features negotiated. This rule may be overridden by later specifications, provided they define appropriate protocols to mitigate these issues. Examples of these attacks and mitigations are discussed in Section 8 of RFC 8446 [7].
This provides pointers and/or clarifications to the Overview in the order and manner defined in RFC 4422, section 4.
The service name SHALL be "xmpp", as defined by RFC 6120.
Servers list mechanisms in the <mechanisms/> list in response to a <request/> by the client. (See Initiation).
Clients initiate using the <authenticate/> top level element (See Initiation.
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.
Any non-empty authorization string MUST be considered an error if the stream's from attribute (if present) does not match.
Clients MAY abort unilaterally at any time before the authentication completed by sending an <abort/> element. This element MAY contain a <text/> element containing a textual representation of the reason as well as any other element defined in some future protocol.
Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in Failure.
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 Success and Continue.
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 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.
In particular, once <success/> or <continue/> has been sent by the server, any further <authenticate/> element MUST result in a stream error.
This section provides some example flows. It aims to demonstrate the structure of SASL2 negotiation, but it does not definitively describe any of the additional extensions shown here.
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.
<!--
Client sends stream header
-->
<stream:stream
from='alice@example.org'
to='example.org'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<!--
Server sends stream features.
These are identical to SASL1, but within a different namespace.
-->
<stream:features>
<authentication xmlns='urn:xmpp:sasl:2'>
<mechanism>PLAIN</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
</authentication>
</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,
so the "=" special case no longer applies.
-->
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='PLAIN'>
<initial-response>AGFsaWNlQGV4YW1wbGUub3JnCjM0NQ==</initial-response>
<user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'>
<software>AwesomeXMPP</software>
<device>Kiva's Phone</device>
</user-agent>
</authenticate>
<!--
This completes in one step, so the Server sends a success.
A SASL2 success always includes the authorization identifier:
-->
<success xmlns='urn:xmpp:sasl:2'>
<authorization-identifier>alice@example.org</authorization-identifier>
</success>
<!--
The server immediately sends a new set of stream features at this point.
There is no stream restart.
-->
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<required/>
</bind>
</stream:features>
<!--
The client now continues with resource binding.
-->
Use of SASL2 in this simple scenario saves one round-trip (due to the lack of stream restart).
In this example, multiple potential round-trips are saved by negotiating resource binding and stream management inline.
<!--
Client sends stream header
-->
<stream:stream
from='tim@example.org'
to='example.org'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<!--
Server sends stream features.
-->
<stream:features>
<mechanisms xmlns='urn:xmpp:sasl:2'>
<mechanism>PLAIN</mechanism>
<mechanism>CRAM-MD5</mechanism>
</mechanisms>
</stream:features>
<!--
Client intiates authentication.
Here, no initial response is needed, so none is sent.
-->
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='CRAM-MD5'>
<user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'>
<software>AwesomeXMPP</software>
<device>Kiva's Phone</device>
</user-agent>
</authenticate>
<!--
CRAM-MD5 starts with a server challenge:
-->
<challenge xmlns='urn:xmpp:sasl:2'>
PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
</challenge>
<!--
And the client responds:
-->
<response xmlns='urn:xmpp:sasl:2>
dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
</response>
<!--
This completes, so the Server sends a success.
-->
<success xmlns='urn:xmpp:sasl:2'>
<authorization-identifier>tim@example.org</authorization-identifier>
</success>
<!--
The server immediately sends a new set of stream features at this point.
There is no stream restart.
-->
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<required/>
</bind>
</stream:features>
<!--
The client now continues with resource binding.
-->
This moves into the deeply hypothetical. A binding extension is posited, alongside an unrealistic 2FA mechanism which somehow mutually authenticates because why not.
<!--
Client sends stream header
-->
<stream:stream
from='alice@example.org'
to='example.org'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<!--
Server sends stream features.
Note that whilst megabind is advertised, the unrealistic 2FA mechanism is not.
-->
<stream:features>
<authentication xmlns='urn:xmpp:sasl:2'>
<mechanism>BLURDYBLOOP</mechanism>
<inline>
<megabind xmlns='urn:example:megabind'/>
</inline>
</authentication>
</stream:features>
<!--
Client intiates authentication.
-->
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='BLURDYBLOOP'>
<initial-response>
SW5pdGlhbCBSZXNwb25zZQ==
</initial-response>
<user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'>
<software>AwesomeXMPP</software>
<device>Kiva's Phone</device>
</user-agent>
<megabind xmlns='urn:example:megabind'>
<resource>this-one-please</resource>
</megabind>
</authenticate>
<!--
Maybe BLURDYBLOOP does this:
-->
<challenge xmlns='urn:xmpp:sasl:2'>
PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
</challenge>
<!--
And the client responds:
-->
<response xmlns='urn:xmpp:sasl:2>
dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
</response>
<!--
This completes, so the Server sends a continue, with the
success data (probably mutual auth) from BLURDYBLOOP.
The next task required is the unrealistic-2FA.
Note that the session is - probably - bound at this point, but
the authorization-identifier is not passed to the client until
the full authentication sequence is completed.
-->
<continue xmlns='urn:xmpp:sasl:2'>
<additional-data>
QWRkaXRpb25hbCBEYXRh
</additional-data>
<tasks>
<task>UNREALISTIC-2FA</task>
</tasks>
</continue>
<!--
The client supports the unrealistic-2FA, so can move onto the next task:
-->
<next xmlns='urn:xmpp:sasl:2' task='UNREALISTIC-2FA'>
<parameters xmlns='urn:example:unrealistic2fa'>
VW5yZWFsaXN0aWMgMkZBIElS
</parameters>
</next>
<!--
This 2FA process is both unrealistic and also uses multiple round-trips.
-->
<task-data xmlns='urn:xmpp:sasl:2'>
<question xmlns='urn:example:unrealistic2fa'>
PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
</question>
</task>
<!--
The client responds here.
-->
<task-data xmlns='urn:xmpp:sasl:2'>
<answer xmlns='urn:example:unrealistic2fa'>
dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
</answer>
</task>
<!--
Finally, the server sends a success.
Here, we have an authzid which is a full jid, since the session is now bound.
The result element here contains the mutual authentication data for the
unrealistic 2FA, and doesn't refer back to the BLURDYBLOOP exchange.
-->
<success xmlns='urn:xmpp:sasl:2'>
<result xmlns='urn:example:unrealistic2fa'>
VW5yZWFsaXN0aWMgMkZBIG11dHVhbCBhdXRoIGRhdGE=
</result>
<authorization-identifier>
alice@example.org/this-one-please
</authorization-identifier>
</success>
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.
This XEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [8].
None.
<?xml version='1.0' encoding='utf-8'?>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace="urn:xmpp:sasl:2"
xmlns="urn:xmpp:sasl:2"
elementFormDefault="qualified">
<xs:element name="authentication">
<xs:complexType>
<xs:sequence>
<xs:element name="mechanism" type="SaslMechName" minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="upgrade" type="SaslMechName" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="inline" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="abort">
<xs:complexType>
<xs:sequence>
<xs:element name="text" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="authenticate">
<xs:complexType>
<xs:attribute name="mechanism" type="SaslMechName"/>
<xs:attribute name="upgrade" type="SaslMechName" minOccurs="0" maxOccurs="1"/>
<xs:sequence>
<xs:element name="initial-response" type="SaslData" minOccurs="0" maxOccurs="1"/>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="challenge" type="SaslData"/>
<xs:element name="response" type="SaslData"/>
<xs:element name="success">
<xs:complexType>
<xs:sequence>
<xs:element name="additional-data" type="SaslData" minOccurs="0" maxOccurs="1"/>
<xs:element name="authorization-identifier" type="Jid" minOccurs="1" maxOccurs="1"/>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="continue">
<xs:complexType>
<xs:sequence>
<xs:element name="additional-data" type="SaslData"/>
<xs:element name="tasks">
<xs:complexType>
<xs:sequence>
<xs:element name="tasK" type="SaslMechName"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="next">
<xs:complexType>
<xs:attribute name="task" type="SaslMechName"/>
<xs:sequence>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="Jid">
<xs:restriction base="xs:string">
<xs:maxLength value="3071"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SaslMechName">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
<xs:maxLength value="20"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SaslData">
<xs:restriction base="xs:base64Binary"/>
</xs:simpleType>
</xs:schema>
The authors wish to share any credit with many members of the community, including Lance Stout, Ralph Meijer, Phil Roberts and Florian Schmaus.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. XEP-0440: SASL Channel-Binding Type Capability <https://xmpp.org/extensions/xep-0440.html>.
2. RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms <http://tools.ietf.org/html/rfc5802>.
3. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.
4. XEP-0233: Use of Domain-Based Service Names in XMPP SASL Negotiation <https://xmpp.org/extensions/xep-0233.html>.
5. XEP-0386: Bind 2.0 <https://xmpp.org/extensions/xep-0386.html>.
6. XEP-0092: Software Version <https://xmpp.org/extensions/xep-0092.html>.
7. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 <http://tools.ietf.org/html/rfc8446>.
8. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
Updated according to implementation experience:
@report{cridland2017sasl2,
title = {Extensible SASL Profile},
author = {Cridland, Dave and Molitor, Thilo and Wild, Matthew},
type = {XEP},
number = {0388},
version = {0.4.0},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0388.html},
date = {2017-02-07/2022-10-06},
}END