XEP-0078: Non-SASL Authentication

Abstract
This document specifies a protocol for authentication with Jabber servers and services using the jabber:iq:auth namespace. Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in RFC 3920 / RFC 6120, and is now obsolete.
Author
Peter Saint-Andre
Copyright
© 1999 – 2020 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Obsolete

WARNING: This document has been obsoleted by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended. Developers desiring similar functionality are advised to implement the protocol that supersedes this one (RFC 6120).
Type
Standards Track
Version
2.5 (2008-10-29)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Draft
  4. Final
  5. Deprecated
  6. Obsolete

1. Introduction

Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in RFC 3920 [1] and RFC 6120 [2], and is now obsolete.

Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. [3] The method originally used in the Jabber community makes use of the 'jabber:iq:auth' namespace and has been documented variously in Internet-Drafts and elsewhere. When the core Jabber protocols were formalized by the IETF, the 'jabber:iq:auth' protocol was replaced by the Simple Authentication and Security Layer (SASL) as specified in RFC 4422 [5]. SASL was incorporated into XMPP because it provides a more flexible approach to authentication by enabling XMPP entities to use a wide variety of authentication methods (e.g., PLAIN, DIGEST-MD5, EXTERNAL, and ANONYMOUS), some of which are more secure than the 'jabber:iq:auth' protocol.

The 'jabber:iq:auth' protocol specified herein is now obsolete. However, because it will take some time for existing implementations and deployments to be upgraded to SASL, client and server software implementations still need to include support for 'jabber:iq:auth' in order to interoperate, and this document provides canonical documentation of the 'jabber:iq:auth' protocol. Nevertheless, implementation and deployment of SASL authentication is strongly recommended, since the 'jabber:iq:auth' protocol will eventually be obsoleted entirely.

2. Requirements

The 'jabber:iq:auth' namespace must make it possible for a Jabber client to authenticate with a server. In particular, the client must provide a username and appropriate credentials for the specific authentication method used. The methods defined herein are:

  1. plaintext
  2. digest (using the SHA1 algorithm specified in RFC 3174 [6])

Note: This document does not include the so-called "zero-knowledge" method; that method did not provide stronger security than digest authentication and thus is unnecessary.

3. Use Cases

3.1 User Authenticates with Server

In order to determine which fields are required for authentication with a server, a client SHOULD first send an IQ get to the server. A client SHOULD NOT attempt to guess at the required fields, since the nature of the required data is subject to service provisioning.

Example 1. Client Requests Authentication Fields from Server
<iq type='get' to='shakespeare.lit' id='auth1'>
  <query xmlns='jabber:iq:auth'/>
</iq>
Example 2. Server Returns Authentication Fields to Client
<iq type='result' id='auth1'>
  <query xmlns='jabber:iq:auth'>
    <username/>
    <password/>
    <digest/>
    <resource/>
  </query>
</iq>

If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in RFC 6120), it MUST return a <service-unavailable/> error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a <policy-violation/> stream error (see RFC 6120 regarding stream error syntax).

Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in RFC 6120 (e.g., to enable the server to provide the resource). The <username/> and <resource/> elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.

The foregoing stanza shows that the server supports both plaintext authentication (via the <password/> element) and digest authentication with SHA1-encrypted passwords (via the <digest/> element).

Therefore, in order to successfully authenticate with the server in this example, a client MUST provide a username, a resource, and one of password or digest.

Example 3. Client Provides Required Information (Plaintext)
<iq type='set' id='auth2'>
  <query xmlns='jabber:iq:auth'>
    <username>bill</username>
    <password>Calli0pe</password>
    <resource>globe</resource>
  </query>
</iq>

Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in RFC 6120, i.e., UTF-8 as defined in RFC 3629 [7]).

The value of the <digest/> element MUST be computed according to the following algorithm:

  1. Concatenate the Stream ID received from the server with the password. [8]
  2. Hash the concatenated string according to the SHA1 algorithm, i.e., SHA1(concat(sid, password)).
  3. Ensure that the hash output is in hexidecimal format, not binary or base64.
  4. Convert the hash output to all lowercase characters.
Example 4. Client Provides Required Information (Digest)
<iq type='set' id='auth2'>
  <query xmlns='jabber:iq:auth'>
    <username>bill</username>
    <digest>48fc78be9ec8f86d8ce1c39c320c97c21d62334d</digest>
    <resource>globe</resource>
  </query>
</iq>

The character data shown in the <digest/> element is the output produced as a result of following the algorithm defined above when the stream ID is '3EE948B0' and the password is 'Calli0pe'.

If the credentials provided match those known by the server, the client will be successfully authenticated.

Example 5. Server Informs Client of Successful Authentication
<iq type='result' id='auth2'/>

Alternatively, authentication may fail. Possible causes of failure include:

  1. The user provided incorrect credentials.
  2. There is a resource conflict (i.e., there is already an active session with that resource identifier associated with the same username). The RECOMMENDED behavior is for the server to terminate the existing session and create the new one; however, the server MAY provide the opposite behavior if desired, leading to a conflict error for the newly requested login.
  3. The user did not provide all of the required information (e.g., did not provide a username or resource).

Although RFC 6120 specifies that error stanzas SHOULD include the original XML sent, error stanzas qualified by the 'jabber:iq:auth' namespace SHOULD NOT do so given the sensitive nature of the information being exchanged.

Example 6. Server Informs Client of Failed Authentication (Incorrect Credentials)
<iq type='error' id='auth2'>
  <error code='401' type='auth'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
Example 7. Server Informs Client of Failed Authentication (Resource Conflict)
<iq type='error' id='auth2'>
  <error code='409' type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
Example 8. Server Informs Client of Failed Authentication (Required Information Not Provided)
<iq type='error' id='auth2'>
  <error code='406' type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

4. Stream Feature

RFC 6120 defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).

Example 9. Advertising non-SASL authentication as a stream feature
  <stream:features>
    <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
      <mechanism>DIGEST-MD5</mechanism>
      <mechanism>PLAIN</mechanism>
    </mechanisms>
    <auth xmlns='http://jabber.org/features/iq-auth'/>
  </stream:features>

A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).

5. Error Handling

As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in RFC 6120. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.

6. Expiration Date

In accordance with Section 8 of XMPP Extension Protocols (XEP-0001) [9], on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council (now XMPP Council) changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.

7. Security Considerations

Use of SASL authentication can be more secure than the 'jabber:iq:auth' protocol, depending on which SASL mechanism is used. Because SASL provides greater flexibility and can provide stronger security, the 'jabber:iq:auth' protocol is now obsolete. If both client and server implement SASL, they MUST prefer SASL over the 'jabber:iq:auth' protocol. If a client attempts to authenticate using the 'jabber:iq:auth' namespace after an attempt at SASL authentication fails, the server MUST refuse the 'jabber:iq:auth' attempt by returning a <policy-violation/> stream error to the client.

Client implementations MUST NOT make plaintext the default mechanism, and SHOULD warn the user that the plaintext mechanism is insecure. The plaintext mechanism SHOULD NOT be used unless the underlying stream is encrypted (using SSL or TLS) and the client has verified that the server certificate is signed by a trusted certification authority. A given domain MAY choose to disable plaintext logins if the stream is not properly encrypted, or disable them entirely. If a client implements the plaintext mechanism and a server allows both the digest mechanism and the plaintext mechanism when channel encryption is not in use, a downgrade attack is possible, in which a man-in-the-middle tricks the client into revealing the user's plaintext password.

8. IANA Considerations

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

9. XMPP Registrar Considerations

9.1 Protocol Namespaces

The XMPP Registrar [11] includes the 'jabber:iq:auth' namespace in its registry of protocol namespaces.

9.2 Stream Features

The XMPP Registrar includes the 'http://jabber.org/features/iq-auth' namespace in its registry of stream feature namespaces.

10. XML Schemas

10.1 jabber:iq:auth

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='jabber:iq:auth'
    xmlns='jabber:iq:auth'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
      protocol has been superseded by SASL Authentication as
      defined in RFC 3920 and RFC 6120, and is now obsolete.

      For historical purposes, the protocol documented by this
      schema is defined in XEP-0078:

      http://www.xmpp.org/extensions/xep-0078.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='query'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='username' type='xs:string' minOccurs='0'/>
        <xs:choice>
          <xs:element name='password' type='xs:string' minOccurs='0'/>
          <xs:element name='digest' type='xs:string' minOccurs='0'/>
        </xs:choice>
        <xs:element name='resource' type='xs:string' minOccurs='0'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

10.2 Stream Feature

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/features/iq-auth'
    xmlns='http://jabber.org/features/iq-auth'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
      protocol has been superseded by SASL Authentication as
      defined in RFC 3920 and RFC 6120, and is now obsolete.

      For historical purposes, the protocol documented by this
      schema is defined in XEP-0078:

      http://www.xmpp.org/extensions/xep-0078.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='auth' type='empty'/>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

Appendices

Appendix A: Document Information

Series
XEP
Number
0078
Publisher
XMPP Standards Foundation
Status
Obsolete
Type
Standards Track
Version
2.5
Last Updated
2008-10-29
Approving Body
XMPP Council
Dependencies
XMPP Core, RFC 3174
Supersedes
None
Superseded By
RFC 6120
Short Name
iq-auth
Schema
<http://www.xmpp.org/schemas/iq-auth.xsd>
Source Control
HTML

This document in other formats: XML  PDF

Appendix B: Author Information

Peter Saint-Andre
Email
xsf@stpeter.im
JabberID
peter@jabber.org
URI
http://stpeter.im/

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).

Permissions

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

Visual Presentation

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.

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.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

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. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

2. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

3. Component authentication is out of scope for this document, and is specified separately in Jabber Component Protocol (XEP-0114) [4].

4. XEP-0114: Jabber Component Protocol <https://xmpp.org/extensions/xep-0114.html>.

5. RFC 4422: Simple Authentication and Security Layer (SASL) <http://tools.ietf.org/html/rfc4422>.

6. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.

7. RFC 3629: UTF-8, a transformation format of ISO 10646 <http://tools.ietf.org/html/rfc3629>.

8. In Digest authentication, password characters that map to predefined XML entities SHOULD NOT be escaped as they are for plaintext passwords, but non-US-ASCII characters MUST be encoded as UTF-8 since the SHA-1 hashing algorithm operates on byte arrays.

9. XEP-0001: XMPP Extension Protocols <https://xmpp.org/extensions/xep-0001.html>.

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

11. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

Appendix H: Revision History

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

  1. Version 2.5 (2008-10-29)

    Per a vote of the XMPP Council, changed status to Obsolete.

    psa
  2. Version 2.4 (2008-01-30)

    Clarified the reasoning behind adoption of SASL and corrected the security considerations accordingly.

    psa
  3. Version 2.3 (2006-09-13)

    Per a vote of the Jabber Council, changed status to Deprecated.

    psa
  4. Version 2.2 (2005-06-28)

    Corrected error in schema and example (username is not required in IQ-get).

    psa
  5. Version 2.1 (2004-12-09)

    Changed SHOULD to MUST regarding priority of SASL (RFC 3920) over jabber:iq:auth (XEP-0078).

    psa
  6. Version 2.0 (2004-10-20)

    Per a vote of the Jabber Council, advanced status to Final.

    psa
  7. Version 1.8 (2004-10-18)

    Specified advertising iq-auth stream feature is implementation-specific; clarified several small matters in the text.

    psa
  8. Version 1.7 (2004-07-27)

    Added reference to character escaping in digest authentication; required inclusion of stream feature when server supports stream features and it is safe to advertise non-SASL authentication.

    psa
  9. Version 1.6 (2004-07-21)

    Removed reference to UTF-16, which is disallowed by XMPP Core; removed reference to character escaping in digest authentication pending list discussion.

    psa
  10. Version 1.5 (2004-02-18)

    Added optional stream feature.

    psa
  11. Version 1.4 (2004-02-03)

    Clarified that username and resource are required for authentication.

    psa
  12. Version 1.3 (2003-11-26)

    Added XMPP error handling.

    psa
  13. Version 1.2 (2003-11-06)

    Addressed case of attempting jabber:iq:auth after SASL failure.

    psa
  14. Version 1.1 (2003-10-02)

    Moved change password use case to XEP-0077.

    psa
  15. Version 1.0 (2003-06-18)

    Per a vote of the Jabber Council, advanced status to Draft.

    psa
  16. Version 0.8 (2003-06-18)

    Changes to address Council concerns.

    psa
  17. Version 0.7 (2003-06-13)

    Added change password use case; added more details to security considerations.

    psa
  18. Version 0.6 (2003-06-12)

    Added digest example; clarified escaping requirements; further specified error conditions; added more details to security considerations.

    psa
  19. Version 0.5 (2003-06-06)

    Removed XMPP-style error conditions until formats are stable.

    psa
  20. Version 0.4 (2003-05-30)

    Removed "enhanced digest" content, added information about expiration date.

    psa
  21. Version 0.3 (2003-05-28)

    Added "enhanced digest" method.

    psa
  22. Version 0.2 (2003-05-20)

    Slight editorial revisions.

    psa
  23. Version 0.1 (2003-04-10)

    Initial version.

    psa

END