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

1.5pre13

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1572 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-01-11 23:26:26 +00:00
parent 2817a14b24
commit 4098ca0b22
1 changed files with 53 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
xep-0115.xml
View File

@ -34,10 +34,25 @@
<jid>jajcus@jabber.bnet.pl</jid>
</author>
<revision>
<version>1.5pre12</version>
<date>in progress, last updated 2007-12-18</date>
<version>1.5pre13</version>
<date>in progress, last updated 2008-01-11</date>
<initials>jjh/psa</initials>
<remark><p>Specified that inclusion of hash attribute is required, removed default value of sha-1, and added reference to IANA registry; mentioned pre-image attack and added reference to RFC 4270; clarified meaning and construction of caps node attribute and disco 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; added service discovery feature for caps optimization to prevent confusion regarding server support of caps vs. caps optimization.</p></remark>
<remark>
<ul>
<li>Defined SHA-1 as mandatory to implement</li>
<li>Specified that inclusion of hash attribute is required</li>
<li>More clearly specified security considerations</li>
<li>More clearly specified implementation notes</li>
<li>Added internationalization considerations</li>
<li>Mentioned preimage attacks and added reference to RFC 4270</li>
<li>Clarified meaning and construction of caps node attribute and disco node attribute</li>
<li>Specified that node attribute shall be included in disco#info request for backwards-compatibility</li>
<li>Further specified security considerations</li>
<li>Clarified handling of the legacy format to assist developers</li>
<li>Defined optional v attribute for the software version</li>
<li>Added service discovery feature for caps optimization to prevent confusion regarding server support of caps vs. caps optimization</li>
</ul>
</remark>
</revision>
<revision>
<version>1.4</version>
@ -237,7 +252,7 @@
</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>The hashing algorithm used to generate the 'ver' attribute; see <link url='#security-mti'>Mandatory-to-Implement Technologies</link> regarding supported hashing algorithms.</td>
<td>REQUIRED</td>
</tr>
<tr>
@ -257,7 +272,7 @@
</tr>
</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 software implementations (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 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 backwards-compatible, applications SHOULD appropriately handle the <link url='#legacy'>Legacy Format</link>.</p>
</section1>
@ -360,11 +375,6 @@
</section2>
</section1>
<section1 topic='Caps Optimization' anchor='optimization'>
<p>A server that is managing an connected client's presence session MAY optimize presence notification traffic sent through the server by stripping off redundant capabilities annotations. Because of this, receivers of presence notifications MUST NOT expect an annotation on every presence notification they receive. If the server performs caps optimization, it MUST ensure that the first presence notification each subscriber receives contains the annotation. The server MUST also ensure that any changes in the caps infomration (e.g., an updated 'ver' attribute) are sent to all subscribers.</p>
<p>If a connected client determines that its server supports caps optimization, MAY choose to send the capabilities annotation only on the first presence packet, as well as whenever its capabilities change.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports the entity capabilities protocol, it MUST advertise that fact by returning a feature of <strong>'http://jabber.org/protocol/caps'</strong> in response to a service discovery information request.</p>
<example caption="Service discovery information request"><![CDATA[
@ -410,21 +420,44 @@
]]></example>
</section1>
<section1 topic='Directed Presence' anchor='directed'>
<p>If two entities exchange messages but they do not normally exchange presence (i.e., via presence subscription), the entities MAY choose to send directed presence to each other, where the presence information SHOULD be annotated with the same capabilities information as each entity sends in broadcasted presence. Until and unless capabilities information has not been received from another entity, an application MUST assume that the other entity does not support capabilities.</p>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Hashing Algorithm Support' anchor='impl-hash'>
<p>An application should maintain a list of hashing algorithms it supports, which MUST include the <link url='#security-mti'>Mandatory-to-Implement Technologies</link>. If the application receives a caps notification that was generated using one of its supported hashing algorithms, then it SHOULD verify the hash and cache the value globally. If the application receives a caps notification generated using a hash it does not support, then it SHOULD NOT attempt to verify the hash but SHOULD cache it on a per-JID basis (i.e., it SHOULD send a service discovery information request to the JID and cache the results for that JID only).</p>
</section2>
<section2 topic='Caching' anchor='impl-cache'>
<p>It is RECOMMENDED for an application that processes entity capabilities information to cache associations between the 'ver' attribute and discovered features within the scope of one presence session. This obviates the need for extensive service discovery requests within a session.</p>
<p>It is OPTIONAL for an application to cache associates across presence sessions. However, since this obviates the need for extensive service discovery requests at the beginning of a session, such caching is strongly encouraged, especially in bandwidth-constrained environments.</p>
</section2>
<section2 topic='Directed Presence' anchor='impl-presence'>
<p>If two entities exchange messages but they do not normally exchange presence (i.e., via presence subscription), the entities MAY choose to send directed presence to each other, where the presence information SHOULD be annotated with the same capabilities information as each entity sends in broadcasted presence. Until and unless capabilities information has not been received from another entity, an application MUST assume that the other entity does not support capabilities.</p>
</section2>
<section2 topic='Caps Optimization' anchor='impl-optimize'>
<p>A server that is managing an connected client's presence session MAY optimize presence notification traffic sent through the server by stripping off redundant capabilities annotations. Because of this, receivers of presence notifications MUST NOT expect an annotation on every presence notification they receive. If the server performs caps optimization, it MUST ensure that the first presence notification each subscriber receives contains the annotation. The server MUST also ensure that any changes in the caps infomration (e.g., an updated 'ver' attribute) are sent to all subscribers.</p>
<p>If a connected client determines that its server supports caps optimization, MAY choose to send the capabilities annotation only on the first presence packet, as well as whenever its capabilities change.</p>
</section2>
</section1>
<section1 topic='Caching' anchor='caching'>
<p>It is RECOMMENDED for an application that processes entity capabilities information to cache associations between the 'ver' attribute and discovered features within the scope of one presence session. This obviates the need for extensive service discovery requests within a session.</p>
<p>It is OPTIONAL for an application to cache associates across presence sessions. However, since this obviates the need for extensive service discovery requests at the beginning of a session, such caching is strongly encouraged, especially in bandwidth-constrained environments.</p>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<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>
<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 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 presence subscription of "both"); note, however, that such restrictions may be incompatible with the recommendation regarding <link url='#directed'>Directed Presence</link>.</p>
<p>Adherence to the algorithm defined in the <link url='#ver'>Generation of the 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 <link url='#legacy'>Legacy Format</link>), 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>
<section2 topic='Mandatory-to-Implement Technologies' anchor='security-mti'>
<p>The SHA-1 hashing algorithm is mandatory to implement. All implementations MUST support SHA-1.</p>
<p>An implementation MAY support other algorithms. Any such algorithm SHOULD be registered in the &ianahashes;.</p>
<p>In the future, the &COUNCIL; may, at its discretion, modify the mandatory-to-implement hashing algorithm if it determines that SHA-1 has become practically (not just theoretically) vulnerable to <link url='#security-preimage'>Preimage Attacks</link>. If the Council </p>
</section2>
<section2 topic='Preimage Attacks' anchor='security-preimage'>
<p>Theoretically it may become possible to launch a "preimage" attack (see &rfc4270;) against the hashes used in the 'ver' attribute, i.e., if the hashing algorithm used is found to be vulnerable to such attacks. However, such attacks are not currently practical against the SHA-1 algorithm, and may not become practical in the foreseeable future. The XMPP Council shall monitor the state of cryptanalysis regarding the SHA-1 algorithm. If and when preimage attacks become practical against SHA-1, this specification shall be updated to change the mandatory-to-implement hashing algorithm from SHA-1 to a safer algorithm (e.g., SHA-256).</p>
</section2>
<section2 topic='Caps Poisoning' anchor='security-poisoning'>
<p>Adherence to the method defined in the <link url='#ver'>Generation of the 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 <link url='#legacy'>Legacy Format</link>), 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 or poisoned hashes.</p>
</section2>
<section2 topic='Information Exposure' anchor='security-exposure'>
<p>Use of entity capabilities might make it easier for an attacker to launch certain application-specific attacks, since the attacker would know what kind of more easily determine the type of client being used as well as its capabilities. 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 presence subscription of "both"); note, however, that such restrictions may be incompatible with the recommendation regarding <link url='#directed'>Directed Presence</link>.</p>
<p>A client SHOULD enable a human user to disable inclusion of the 'v' attribute, which specifies a version of the software. If the 'v' attribute is not included, the receiver MUST assume that the version is intended to be private, and MUST NOT automatically send Software Version requests to the sender.</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>