moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

2.4pre1 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1603 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-01-24 04:21:51 +00:00
parent ea0621afe0
commit b5fb269f45
1 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
xep-0078.xml
View File

@ -27,6 +27,12 @@
</schemaloc>
<expires>2007-03-13</expires>
&stpeter;
<revision>
<version>2.4pre1</version>
<date>in progress, last updated 2008-01-23</date>
<initials>psa</initials>
<remark><p>Clarified the reasoning behind adoption of SASL and corrected the security considerations accordingly.</p></remark>
</revision>
<revision>
<version>2.3</version>
<date>2006-09-13</date>
@ -156,8 +162,8 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>Note Well: The protocol specified herein has been deprecated in favor of SASL authentication as specified in &rfc3920;.</em></p>
<p>Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. <note>Component authentication is out of scope for this document, and is specified separately in &xep0114;.</note> 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 &rfc4422;) in order to progress through the Internet Standards Process, documentation of the 'jabber:iq:auth' namespace was removed from those specifications.</p>
<p>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.</p>
<p>Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. <note>Component authentication is out of scope for this document, and is specified separately in &xep0114;.</note> 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 &rfc4422;. 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.</p>
<p>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.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>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:</p>
@ -288,9 +294,8 @@
<p>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.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Use of the 'jabber:iq:auth' method for client-server authentication is not as secure as SASL authentication (defined in <cite>RFC 3920</cite>). 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 &lt;policy-violation/&gt; stream error to the client.</p>
<p>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.</p>
<p>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.</p>
<p>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 &lt;policy-violation/&gt; stream error to the client.</p>
<p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>