XEP-0078: Non-SASL Authentication

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 deprecated in favor of SASL authentication as specified in RFC 3920.

WARNING: This document has been deprecated by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended. Developers desiring similar functionality should implement the protocol that supersedes this one (if any).

Document Information

Series: XEP
Number: 0078
Publisher: XMPP Standards Foundation
Status: Deprecated
Type: Standards Track
Version: 2.3
Last Updated: 2006-09-13
Expires: 2007-03-13
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 3174
Supersedes: None
Superseded By: RFC 3920
Short Name: iq-auth
Schema: <http://www.xmpp.org/schemas/iq-auth.xsd>
Wiki Page: <http://wiki.jabber.org/index.php/Non-SASL Authentication (XEP-0078)>

Author Information

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the XSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) 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.

Conformance Terms

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

Table of Contents

1. Introduction

Note Well: The protocol specified herein has been deprecated in favor of SASL authentication as specified in RFC 3920 [1].

Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. [2] 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. Because the XMPP specifications required upgraded authentication methods using SASL (see RFC 4422 [4]) in order to progress through the Internet Standards Process, documentation of the 'jabber:iq:auth' namespace was removed from those specifications.

The 'jabber:iq:auth' method specified herein has been deprecated. 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' method. Nevertheless, implementation and deployment of SASL authentication is strongly recommended, since the 'jabber:iq:auth' method 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 [5])

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

<stream:stream to='shakespeare.lit'
               xmlns='jabber:client'
               xmlns:stream='http://etherx.jabber.org/streams'>
    

<stream:stream from='shakespeare.lit'
               xmlns='jabber:client'
               xmlns:stream='http://etherx.jabber.org/streams'
               id='3EE948B0'>
    

<iq type='get' to='shakespeare.lit' id='auth1'>
  <query xmlns='jabber:iq:auth'/>
</iq>
    

<iq type='result' id='auth1'>
  <query xmlns='jabber:iq:auth'>
    <username/>
    <password/>
    <digest/>
    <resource/>
  </query>
</iq>
    

<iq type='set' id='auth2'>
  <query xmlns='jabber:iq:auth'>
    <username>bill</username>
    <password>Calli0pe</password>
    <resource>globe</resource>
  </query>
</iq>
    

<iq type='set' id='auth2'>
  <query xmlns='jabber:iq:auth'>
    <username>bill</username>
    <digest>48fc78be9ec8f86d8ce1c39c320c97c21d62334d</digest>
    <resource>globe</resource>
  </query>
</iq>
    

<iq type='result' id='auth2'/>
    

<iq type='error' id='auth2'>
  <error code='401' type='auth'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq type='error' id='auth2'>
  <error code='409' type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<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 3920 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 11. Advertising non-SASL authentication as a stream feature

<?xml version='1.0' encoding='utf-8'?>
<stream:stream xmlns:stream='http://etherx.jabber.org/streams/'
    xmlns='jabber:client'
    from='somedomain'
    version='1.0'>
  <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 3920. 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 [8], 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 the 'jabber:iq:auth' method for client-server authentication is not as secure as SASL authentication (defined in RFC 3920). If both client and server implement SASL, they MUST use SASL. 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 certificate 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.

Authentication using the 'jabber:iq:auth' method is known to be less secure than SASL authentication, which is one reason why the 'jabber:iq:auth' method has been deprecated.

8. IANA Considerations

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

9. XMPP Registrar Considerations

10. XML Schemas

<?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>
      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>
    

<?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>
      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>
    

Notes

Revision History

END