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

1.5pre1 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1184 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-08-24 18:34:10 +00:00
parent cfd28a1349
commit 582be4e763
1 changed files with 25 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
xep-0115.xml
View File

@ -27,6 +27,12 @@
&hildjj;
&stpeter;
&remko;
<revision>
<version>1.5pre1</version>
<date>2007-08-24</date>
<initials>jjh/psa</initials>
<remark><p>To avoid confusion, renamed the hash attribute to the algo attribute; required inclusion of the algo attribute in non-legacy mode; clarified handling of the legacy format to assist developers.</p></remark>
</revision>
<revision>
<version>1.4</version>
<date>2007-08-13</date>
@ -120,6 +126,7 @@
<code><![CDATA[
<presence from='romeo@montague.lit/orchard'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://exodus.jabberstudio.org/#0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
@ -152,6 +159,7 @@
<code><![CDATA[
<presence from='benvolio@capulet.lit/230193'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://psi-im.org/#0.11'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
@ -161,6 +169,7 @@
<code><![CDATA[
<presence from='nurse@capulet.lit/chamber'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://psi-im.org/#0.10'
ver='uCoVCteRe3ty2wU2gHxkMaA7xhs='/>
</presence>
@ -169,6 +178,7 @@
<code><![CDATA[
<presence from='bard@shakespeare.lit/globe'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://www.chatopus.com/#2.2'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
</presence>
@ -211,23 +221,23 @@
<th>Inclusion</th>
</tr>
<tr>
<td>ext</td>
<td>A set of nametokens specifying additional feature bundles; this attribute is deprecated.</td>
<td>OPTIONAL</td>
<td>algo</td>
<td>The hashing algorithm used in generated the 'ver' attribute (see &ianahashes;); the value defaults to "sha-1".</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>hash</td>
<td>The hashing algorithm used in generated the 'ver' attribute (see &ianahashes;); the value defaults to "sha-1".</td>
<td>ext</td>
<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>OPTIONAL</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. although this information is an "FYI" in the current version of entity capabilities, it is required for backward-compatibility with older versions. It is RECOMMENDED for the value to identify both the software product and the released version in the form "ProductURL#Version", such as "http://psi-im.org/#0.11".</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. Although this information is an "FYI" in the current version of entity capabilities, it is required for backward-compatibility with older versions (see the <link url='#legacy'>Legacy Format</link> section of this document). It is RECOMMENDED for the value to identify both the software product and the released version in the form "ProductURL#Version", such as "http://psi-im.org/#0.11".</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>ver</td>
<td>A string that specifies the identity and supported features of the entity. <note>Before version 1.4 of this specification, the 'ver' attribute was used to specify the released version of the software; however, the values of the 'ver' attribute that result from use of the algorithm specified since version 1.4 are backward-compatible with the legacy approach.</note></td>
<td>A string that specifies the identity and supported features of the entity. 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>.</td>
<td>REQUIRED</td>
</tr>
</table>
@ -263,6 +273,7 @@
<example caption='Annotated presence sent'><![CDATA[
<presence>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://exodus.jabberstudio.org/#0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
@ -297,7 +308,7 @@
</iq>
]]></example>
<p>The client MUST check the identities and supported features against the 'ver' value by calculating the hash as described under <link url='#ver'>Generating the ver Attribute</link> and making sure that the values match. If the values do not match, the client MUST NOT accept or cache the 'ver' value as reliable and SHOULD check the value of another user who advertises that value (if any). This helps to prevent poisoning of entity capabilities information.</p>
<p>The client MUST check the identities and supported features against the 'ver' value by calculating the hash as described under <link url='#ver'>Generating the ver Attribute</link> and making sure that the values match. If the values do not match, the client MUST NOT accept or cache the 'ver' value as reliable and SHOULD check the service discovery identity and supported features of another user who advertises that value (if any). This helps to prevent poisoning of entity capabilities information.</p>
</section2>
@ -306,6 +317,7 @@
<example caption='Stream feature element including capabilities'><![CDATA[
<stream:features>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://jabberd.org/entity'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='>
</stream:features>
@ -346,7 +358,7 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<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 Discoery 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>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>
</section1>
@ -381,8 +393,8 @@
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='algo' type='xs:NMTOKEN' use='required' default='sha-1'/>
<xs:attribute name='ext' type='xs:NMTOKENS' use='optional'/>
<xs:attribute name='hash' type='xs:NMTOKEN' use='optional' default='sha-1'/>
<xs:attribute name='node' type='xs:string' use='required'/>
<xs:attribute name='ver' type='xs:string' use='required'/>
</xs:extension>
@ -401,7 +413,9 @@
</section1>
<section1 topic='Legacy Format' anchor='legacy'>
<p>Before Version 1.4 of this specification, the 'ver' attribute was generated differently and the 'ext' attribute was used more extensively. 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 'algo' 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>An application can determine if the legacy format is in use by checking for the presence of the 'algo' attribute, which is REQUIRED in the current format.</p>
<p>In the legacy format, the value of the 'ver' attribute is not a hash of the service discovery identity and supported features. Therefore, a processing entity cannot validate the identity and features by checking the hash. If the processing entity supports the legacy format, it SHOULD check the 'node', 'ver', and 'ext' combinations as specified in the archived version 1.3 of this specification, and MAY cache the results. If not, the processing entity SHOULD ignore the 'ver' value entirely (since it cannot be verified) and SHOULD NOT cache it.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>