Per a vote of the XMPP Council, changed status to Obsolete.
Note Well: The protocol specified herein has been deprecated in favor of SASL authentication as specified in &rfc3920;.
+Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in &rfc3920;, and is now obsolete.
Jabber technologies have long included a wire protocol that enables a client to authenticate with a server.
The 'jabber:iq:auth' protocol 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' protocol. Nevertheless, implementation and deployment of SASL authentication is strongly recommended, since the 'jabber:iq:auth' protocol will eventually be obsoleted entirely.
+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.
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:
@@ -294,7 +299,7 @@In accordance with Section 8 of &xep0001;, 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.
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 has been deprecated. 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.
+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.
An external component is called "trusted" because it authenticates with a server using authentication credentials that include a shared secret. This secret is commonly specified in the configuration files used by the server and component, but could be provided at runtime on the command line or extracted from a database. An external component is commonly trusted to do things that clients cannot, such as write 'from' addresses for the server's domain(s). Some server may also allow components to send packets that are used by the server's internal protocol (e.g., <log/> and <xdb/> packets in the jabberd 1.x series); however, those internal protocols are out of scope for this document.
The main difference between the jabber:component:* namespaces and the 'jabber:client' or 'jabber:server' namespace is authentication. External components do not use the older &xep0078; protocol (i.e., the 'jabber:iq:auth' namespace), nor do they (yet) use SASL authentication as defined in &xmppcore; (although a future component protocol would most likely use SASL). Instead, they use a special <handshake/> element whose XML character data specifies credentials for the component's session with the server. The protocol flow for stream negotiation and authentication using jabber:component:accept is as follows:
+The main difference between the jabber:component:* namespaces and the 'jabber:client' or 'jabber:server' namespace is authentication. External components do not use the obsolete &xep0078; protocol (i.e., the 'jabber:iq:auth' namespace), nor do they (yet) use SASL authentication as defined in &xmppcore; (although a future component protocol would most likely use SASL). Instead, they use a special <handshake/> element whose XML character data specifies credentials for the component's session with the server. The protocol flow for stream negotiation and authentication using jabber:component:accept is as follows:
It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has an IM session, as specified in Section 3 of RFC 3921 or its equivalent (e.g., &xep0078;), whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".
+It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one active or connected resource as defined in &rfc3920bis; and &rfc3921bis; (whether that user is actively sending XML stanzas or is idle). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".
A sample protocol flow for this use case is shown below.
RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.
+RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the obsolete jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.
Note: The recommendations described herein have been incorporated into rfc3920bis.
The 'auth' attribute is REQUIRED. It represents whether and how the hop in question is authenticated, in particular via one of the following means: