moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-24 16:48:52 -05:00
Code Issues Releases Wiki Activity

Changed XEP-0078 to Obsolete per XMPP Council vote

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2456 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-10-28 19:32:10 +00:00
parent 74bdbf6868
commit b8d2333902
6 changed files with 33 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0073.xml
View File

@ -24,8 +24,8 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>XEP-0211</spec>
<spec>XEP-0212</spec>
<spec>XEP-0242</spec>
<spec>XEP-0243</spec>
</supersededby>
<shortname>N/A</shortname>
&stpeter;

37
xep-0078.xml
View File

@ -7,10 +7,10 @@
<xep>
<header>
<title>Non-SASL Authentication</title>
<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 deprecated in favor of SASL authentication as specified in RFC 3920.</abstract>
<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, and is now obsolete.</abstract>
&LEGALNOTICE;
<number>0078</number>
<status>Deprecated</status>
<status>Obsolete</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@ -25,8 +25,13 @@
<schemaloc>
<url>http://www.xmpp.org/schemas/iq-auth.xsd</url>
</schemaloc>
<expires>2007-03-13</expires>
&stpeter;
<revision>
<version>2.5</version>
<date>2008-10-28</date>
<initials>psa</initials>
<remark><p>Per a vote of the XMPP Council, changed status to Obsolete.</p></remark>
</revision>
<revision>
<version>2.4</version>
<date>2008-01-30</date>
@ -161,9 +166,9 @@
</revision>
</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><em>Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in &rfc3920;, and is now obsolete.</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. 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>
<p>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.</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>
@ -294,7 +299,7 @@
<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 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>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 &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'>
@ -321,8 +326,14 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0078: http://www.xmpp.org/extensions/xep-0078.html
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
protocol has been superseded by SASL Authentication as
defined in RFC 3920, 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>
@ -354,8 +365,14 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0078: http://www.xmpp.org/extensions/xep-0078.html
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
protocol has been superseded by SASL Authentication as
defined in RFC 3920, 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>

2
xep-0114.xml
View File

@ -79,7 +79,7 @@
<p>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., &lt;log/&gt; and &lt;xdb/&gt; packets in the jabberd 1.x series); however, those internal protocols are out of scope for this document.</p>
</section1>
<section1 topic='Protocol Flow' anchor='proto'>
<p>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 &lt;handshake/&gt; 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:</p>
<p>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 &lt;handshake/&gt; 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:</p>
<example caption='Component sends stream header to server'><![CDATA[
<stream:stream
xmlns='jabber:component:accept'

2
xep-0133.xml
View File

@ -1229,7 +1229,7 @@
]]></example>
</section2>
<section2 topic='Get Number of Online Users' anchor='get-online-users-num'>
<p>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 <cite>RFC 3921</cite> 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".</p>
<p>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".</p>
<p>A sample protocol flow for this use case is shown below.</p>
<example caption='Admin Requests Number of Online Users'><![CDATA[
<iq from='bard@shakespeare.lit/globe'

2
xep-0193.xml
View File

@ -59,7 +59,7 @@
</header>
<section1 topic='Introduction' anchor='proto'>
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> 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 <cite>RFC 3920</cite>, 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.</p>
<p><cite>RFC 3920</cite> 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 <cite>RFC 3920</cite>, 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.</p>
<p>Note: The recommendations described herein have been incorporated into <cite>rfc3920bis</cite>.</p>
</section1>
<section1 topic='Unbinding a Resource' anchor='unbind'>

2
xep-0219.xml
View File

@ -213,7 +213,7 @@
<p>The 'auth' attribute is REQUIRED. It represents whether and how the hop in question is authenticated, in particular via one of the following means:</p>
<ul>
<li>A Simple Authentication and Security Layer mechanism (see &rfc4422; for the specification and &ianasasl; for a list of registered SASL mechanisms; the names for standardized, non-obsolete mechanisms are used as values of the 'auth' attribute).</li>
<li>The legacy &xep0078; protocol using the "plaintext" or "digest" method.</li>
<li>The obsolete &xep0078; protocol using the "plaintext" or "digest" method.</li>
<li>The server dialback protocol ("dialback") as specified in <cite>RFC 3920</cite>.</li>
</ul>
</section2>