XEP-0388: Extensible SASL Profile

Abstract:This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility.
Author:Dave Cridland
Copyright:© 1999 – 2017 XMPP Standards Foundation. SEE LEGAL NOTICES.
Type:Standards Track
Last Updated:2017-08-14

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction
    1.1. Terminology
2. Overview
    2.1. Discovering Support
    2.2. SASL Data Encoding
    2.3. Initiation
    2.4. Challenges and Responses
    2.5. During Authentication
    2.6. Completing Authentication
       2.6.1. Success
       2.6.2. Failure
       2.6.3. Continue
3. SASL Profile Definition
    3.1. Service Name
    3.2. Mechanism negotiation
    3.3. Message Definitions
       3.3.1. Initiation
       3.3.2. Server Challenges and Client Responses
       3.3.3. Outcome
    3.4. Non-Empty Authorization Strings
    3.5. Aborting
    3.6. Security Layer Effect
    3.7. Security Layer Order
    3.8. Multiple Authentication
4. Security Considerations
5. IANA Considerations
6. XMPP Registrar Considerations
7. Acknowledgements

    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

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.

1.1 Terminology

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.

2. Overview

2.1 Discovering Support

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).

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.

2.2 SASL Data Encoding

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.

2.3 Initiation

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.

Example 1. An authentication request

<authenticate xmlns='urn:xmpp:sasl:1' mechanism="BLURDLYBLOOP">


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.

Example 2. An authentication request with a (hypothetical) bind request

<authenticate xmlns='urn:xmpp:sasl:1' mechanism='BLURDYBLOOP'>
  <bind xmlns='urn:xmpp:bind:example'/>


2.4 Challenges and Responses

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:

Example 3. A challenge and response exchange

<!-- A server might send: -->
<challenge xmlns='urn:xmpp:sasl:1'>

<!-- A client might respond: -->
<response xmlns='urn:xmpp:sasl:1'>


2.5 During Authentication

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.

2.6 Completing Authentication

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.

2.6.1 Success

If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <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.

Example 4. Successful authentication

<success xmlns='urn:xmpp:sasl:1'>

Other extension elements MAY also be contained by the <success/> element.

Example 5. Successful re-authentication and resumption

<success xmlns='urn:xmpp:sasl:1'>
  <sm:resumed xmlns='urn:xmpp:sm:3:example' h='345' previd='124'/>

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 containing the applicable stream features of the newly authenticated stream. Note that no stream restart occurs.

2.6.2 Failure

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.

Example 6. Failure

<failure xmlns='urn:xmpp:sasl:1'>
  <aborted xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
  <optional-application-specific xmlns='urn:something:else'/>
  <text>This is a terrible example.</text>

2.6.3 Continue

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 that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password.

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.

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.

Example 7. Continue Required

<continue xmlns='urn:xmpp:sasl:1'>
  <text>This account requires 2FA</text>

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 contains an OPTIONAL base64 encoded initial response.

Example 8. Client Continues

<next xmlns='urn:xmpp:sasl:1' task='TOTP-EXAMPLE'>

3. SASL Profile Definition

This provides pointers and/or clarifications to the Overview in the order and manner defined in RFC 4422, section 4.

3.1 Service Name

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

3.2 Mechanism negotiation

Servers list mechanisms during stream features (See Discovering Support).

3.3 Message Definitions

3.3.1 Initiation

Clients initiate using the <authenticate/> top level element (See Initiation.

3.3.2 Server Challenges and Client Responses

See Challenges and Responses.

3.3.3 Outcome

See Completing Authentication.

3.4 Non-Empty Authorization Strings

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.

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.

3.5 Aborting

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

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

3.6 Security Layer Effect

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.

3.7 Security Layer Order

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

3.8 Multiple Authentication

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/> has been sent by the server, any further <authenticate/> element MUST result in a stream error.

4. Security Considerations

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.

5. IANA Considerations

This XEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [1].

6. XMPP Registrar Considerations


7. Acknowledgements

The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, and Florian Schmaus.


Appendix A: Document Information

Series: XEP
Number: 0388
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.2.0
Last Updated: 2017-08-14
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: sasl2
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Dave Cridland

Email: dave.cridland@surevine.com
JabberID: dave.cridland@surevine.com

Appendix C: Legal Notices


This XMPP Extension Protocol is copyright © 1999 – 2017 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.

Disclaimer of Warranty

## 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. ##

Limitation of Liability

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.

IPR Conformance

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).

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

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 <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

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".

Appendix G: Notes

1. 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/>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.2.0 (2017-08-14)

Updated according to implementation experience:


Version 0.1.0 (2017-03-16)

(XEP Editor (ssw))

Version 0.0.1 (2017-02-07)