moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

1.5pre10

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1461 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-12-07 02:33:22 +00:00
parent 9da54b8a4f
commit 2258275fef
1 changed files with 37 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
xep-0115.xml
View File

@ -27,17 +27,23 @@
&hildjj;
&stpeter;
&remko;
<author>
<firstname>Jacek</firstname>
<surname>Konieczny</surname>
<email>jajcus@jajcus.net</email>
<jid>jajcus@jabber.bnet.pl</jid>
</author>
<revision>
<version>1.5pre9</version>
<date>in progress, last updated 2007-11-20</date>
<version>1.5pre10</version>
<date>in progress, last updated 2007-12-06</date>
<initials>jjh/psa</initials>
<remark><p>Removed hash attribute since only SHA-1 is used; clarified meaning of node attribute; further specified security considerations; clarified handling of the legacy format to assist developers; defined optional v attribute for the software version.</p></remark>
<remark><p>Specified that inclusion of hash attribute is required and removed default value of sha-1; mentioned pre-image attack and added reference to RFC 4270; clarified meaning of node attribute; specified that node attribute shall be included in disco#info request for backwards-compatibility; further specified security considerations; clarified handling of the legacy format to assist developers; defined optional v attribute for the software version.</p></remark>
</revision>
<revision>
<version>1.4</version>
<date>2007-08-13</date>
<initials>psa/jjh</initials>
<remark><p>In response to persistent security concerns over caps poisoning, redefined ver attribute to be a hash of the service discovery identity and features in a way that is backward-compatible with the legacy format.</p></remark>
<initials>psa/jk/jjh</initials>
<remark><p>In response to persistent security concerns over caps poisoning, redefined ver attribute to be a hash of the service discovery identity and features in a way that is backwards-compatible with the legacy format.</p></remark>
</revision>
<revision>
<version>1.3</version>
@ -126,6 +132,7 @@
<code><![CDATA[
<presence from='romeo@montague.lit/orchard'>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://code.google.com/p/exodus/'
v='0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
@ -138,7 +145,8 @@
id='disco1'
to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</iq>
]]></code>
<p>The response is:</p>
@ -147,7 +155,8 @@
id='disco1'
to='juliet@capulet.lit/chamber'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='>
<identity category='client' name='Exodus 0.9.1' type='pc'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
@ -159,6 +168,7 @@
<code><![CDATA[
<presence from='benvolio@capulet.lit/230193'>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://psi-im.org/'
v='0.11'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
@ -169,6 +179,7 @@
<code><![CDATA[
<presence from='nurse@capulet.lit/chamber'>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://psi-im.org/'
v='0.10'
ver='uCoVCteRe3ty2wU2gHxkMaA7xhs='/>
@ -178,6 +189,7 @@
<code><![CDATA[
<presence from='bard@shakespeare.lit/globe'>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://www.chatopus.com/'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
</presence>
@ -224,6 +236,11 @@
<td>A set of nametokens specifying additional feature bundles; this attribute is deprecated (see the <link url='#legacy'>Legacy Format</link> section of this document).</td>
<td>DEPRECATED</td>
</tr>
<tr>
<td>hash</td>
<td>The hashing algorithm used to generate the 'ver' attribute; expected values are sha-1 and sha-256, although other values may be used (such values SHOULD be as registered in the &ianahashes;).</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>node</td>
<td>A unique identifier for the software underlying the entity, typically a URL at the website of the project or company that produces the software. *</td>
@ -242,7 +259,7 @@
</table>
<p>* Note: It is RECOMMENDED for the value of the 'node' attribute to be an HTTP URL at which a user could find further information about the software product, such as "http://psi-im.org/" for the Psi client; this enables a processing application to also determine a unique string for the generating application, which it could maintain in a list of known products (e.g., associating the name received via the disco#info reply with the URL found in the caps data).</p>
<p>** Note: Before version 1.5 of this specification, the version information was contained in the 'ver' attribute as described below.</p>
<p>*** Note: Before version 1.4 of this specification, the 'ver' attribute was used to specify the released version of the software; while the values of the 'ver' attribute that result from use of the algorithm specified herein are backward-compatible, applications SHOULD appropriately handle the <link url='#legacy'>Legacy Format</link>.</p>
<p>*** Note: Before version 1.4 of this specification, the 'ver' attribute was used to specify the released version of the software; while the values of the 'ver' attribute that result from use of the algorithm specified herein are backwards-compatible, applications SHOULD appropriately handle the <link url='#legacy'>Legacy Format</link>.</p>
</section1>
<section1 topic='Generation of ver Attribute' anchor='ver'>
@ -250,13 +267,13 @@
<p>Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.</p>
<ol>
<li>Initialize an empty string S.</li>
<li>Sort the service discovery identities by category and then by type (if it exists), formatted as 'category' '/' 'type'.</li>
<li>Sort the service discovery identities <note>A registry of service discovery identities is located at &DISCOCATEGORIES;.</note> by category and then by type (if it exists), formatted as 'category' '/' 'type'.</li>
<li>For each identity, append the 'category/type' to S, followed by the '&lt;' character.</li>
<li>Sort the supported features.</li>
<li>Sort the supported service discovery features. <note>A registry of service discovery features is located at &DISCOFEATURES;.</note></li>
<li>For each feature, append the feature to S, followed by the '&lt;' character.</li>
<li>Compute ver by hashing S using the SHA-1 algorithm as specified in &rfc3174; (with binary output) and encoding the hash using Base64 as specified in Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero). <note>The OpenSSL command for producing such output is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".</note></li>
<li>Compute ver by hashing S using the algorithm specified in in the 'hash' attribute (e.g., SHA-1 as defined in &rfc3174;. The hashed data MUST be generated with binary output and encoded using Base64 as specified in Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero). <note>The OpenSSL command for producing such output with SHA-1 is is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".</note></li>
</ol>
<p>For example, consider an entity whose service discovery category is "client", whose service discovery type is "pc", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". The value of the 'ver' attribute would be generated as follows:</p>
<p>For example, consider an entity whose service discovery category is "client", whose service discovery type is "pc", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". Using the SHA-1 algorightm, the value of the 'ver' attribute would be generated as follows:</p>
<ol>
<li>S = ''</li>
<li>Only one identity: "client/pc"</li>
@ -275,6 +292,7 @@
<example caption='Annotated presence sent'><![CDATA[
<presence>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://code.google.com/p/exodus/'
v='0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
@ -290,7 +308,8 @@
id='disco1'
to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</iq>
]]></example>
@ -304,6 +323,7 @@
to='juliet@capulet.lit/balcony'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='>
<identity category='client' type='pc'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
@ -321,6 +341,7 @@
<example caption='Stream feature element including capabilities'><![CDATA[
<stream:features>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://jabberd.org/entity'
v='1.6.1'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='>
@ -365,6 +386,7 @@
<p>Use of the protocol specified in this document might make some client-specific forms of attack slightly easier, since the attacker could more easily determine the type of client being used. However, since most clients respond to Service Discovery and Software Version requests without performing access control checks, there is no new vulnerability. Entities that wish to restrict access to capabilities information SHOULD use &xep0016; to define appropriate communications blocking (e.g., an entity MAY choose to allow IQ requests only from "trusted" entities, such as those with whom it has a subscription of "both").</p>
<p>Adherence to the algorithm defined in the <link url='#ver'>Generation of ver Attribute</link> section of this document for both generation and checking of the 'ver' attribute helps to guard against poisoning of entity capabilities information by malicious or improperly implemented entities.</p>
<p>If the value of the 'ver' attribute is a hash as defined herein (i.e., if the 'ver' attribute is not generated according to the legacy format), inclusion of the 'hash' attribute is required. Knowing explicitly that the value of the 'ver' attribute is a hash enables the recipient to avoid spurious notification of invalid hashes.</p>
<p>Theoretically it may become possible to launch a "pre-image" attack (see &rfc4270;) against the hashes used in the 'ver' attribute, at least when the SHA-1 algorithm is used. However, such attacks are not currently practical, and may not become practical in the foreseeable future. If and when such attacks become practical, this specification will be updated to strongly recommend use of a hashing algorithm that is safer than SHA-1, such as SHA-256. Nevertheless, the SHA-256 algorithm can be used today if implementors are concerned about the safety of the SHA-1 algorithm.</p>
<p>The 'name' attribute of the service discovery &lt;identity/&gt; element is not included in the hash generation method. The primary reason for excluding it is that it is human-readable text and therefore may be provided in different localized versions. As a result, its inclusion would needlessly multiply the number of possible hash values and thus the time and resources required to validate values of the 'ver' attribute.</p>
</section1>
@ -400,6 +422,7 @@
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='ext' type='xs:NMTOKENS' use='optional'/>
<xs:attribute name='hash' type='xs:NMTOKEN' use='required'/>
<xs:attribute name='node' type='xs:string' use='required'/>
<xs:attribute name='v' type='xs:string' use='optional'/>
<xs:attribute name='ver' type='xs:string' use='required'/>
@ -419,7 +442,7 @@
</section1>
<section1 topic='Legacy Format' anchor='legacy'>
<p>Before Version 1.4 of this specification, the 'ver' attribute was generated differently, the 'ext' attribute was used more extensively, and the 'hash' attribute was absent. For historical purposes, Version 1.3 of this specification is archived at &lt;<link url='http://www.xmpp.org/extensions/attic/xep-0115-1.3.html'>http://www.xmpp.org/extensions/attic/xep-0115-1.3.html</link>&gt;. For backward-compatibility with the legacy format, the 'node' attribute is REQUIRED and the 'ext' attribute MAY be included.</p>
<p>Before Version 1.4 of this specification, the 'ver' attribute was generated differently, the 'ext' attribute was used more extensively, and the 'hash' attribute was absent. For historical purposes, Version 1.3 of this specification is archived at &lt;<link url='http://www.xmpp.org/extensions/attic/xep-0115-1.3.html'>http://www.xmpp.org/extensions/attic/xep-0115-1.3.html</link>&gt;. For backwards-compatibility with the legacy format, the 'node' attribute is REQUIRED and the 'ext' attribute MAY be included.</p>
<p>An application can determine if the legacy format is in use by checking for the presence of the 'hash' attribute, which is REQUIRED in the current format.</p>
<p>If an application supports the legacy format, it SHOULD proceed as follows:</p>
<ul>