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

1.5pre14 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1579 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-01-15 03:29:43 +00:00
parent c5df7be8b0
commit 9435a2a10c
1 changed files with 25 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
xep-0115.xml
View File

@ -34,22 +34,20 @@
<jid>jajcus@jabber.bnet.pl</jid>
</author>
<revision>
<version>1.5pre13</version>
<date>in progress, last updated 2008-01-11</date>
<initials>jjh/psa</initials>
<version>1.5pre14</version>
<date>in progress, last updated 2008-01-14</date>
<initials>psa/jjh</initials>
<remark>
<ul>
<li>Defined SHA-1 as mandatory to implement</li>
<li>Specified that inclusion of hash attribute is required</li>
<li>Defined the nature of possible preimage attacks</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>Defined recommended v attribute to include the software version as in older verions of the protocol</li>
<li>Added service discovery feature for caps optimization to prevent confusion regarding server support of caps vs. caps optimization</li>
</ul>
</remark>
@ -435,20 +433,34 @@
<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>
<section2 topic='Friendly Name' anchor='impl-name'>
<p>The 'name' attribute of the service discovery &lt;identity/&gt; element enables a responding application to specify the "friendly name" for its node. However, this attribute is excluded from the hash generation method, primarily because 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. However, a receiving application MAY send a service discovery information request to a particularly JID+node combination in order to determine the friendly name, then cache the result for that JID+node only.</p>
</section2>
</section1>
<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'>
<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>
<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 vulnerable to <link url='#security-preimage'>Preimage Attacks</link>.</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>
<p>Although the entity capabilities protocol is not vulnerable to collision attacks, it may become possible to launch a preimage attack against the hashes used as the values of the 'ver' attribute in the entity capabilities protocol (on the difference between collision attacks and preimage attacks, see &rfc4270;).</p>
<p>In theory, such a preimage attack would take one of the following forms:</p>
<ul>
<li>Given knowledge of a particular value V of the 'ver' attribute, an attacker can find an input message X such that hash(X) yields V (this is known as a "first preimage attack").</li>
<li>Given knowledge of a particular value S used as the input message to the hash function, an attacker can find a value S' that yields V (this is known as a "second preimage attack").</li>
</ul>
<p>In practice, a preimage attack would need to meet all of the following criteria in order to be effective against the entity capabilities protocol:</p>
<ol>
<li>The hashing algorithm used would need to be found not only theoretically but practically vulnerable to first or second preimage attacks (e.g., this is not yet true of the MD5 or SHA-1 algorithms, but may become true in the future).</li>
<li>An attacker would need to find an input message X or S' that matches the hash V for a particular value of V or S, which may not be practical given that (a) the values of S used as input to the hash function in entity capabilities are relatively short and (b) cryptanalysis to date indicates that existing hash functions may not be vulnerable to preimage attacks except in the case of relatively long input messages (on the order of 2<span class='super'>55</span> blocks).</li>
<li>The input message X or S' would need to conform to the structure of S as specified under <link url='#ver'>Generation of the ver Attribute</link>, including the order of service discovery identity or identities followed by service discovery features, delimited by the '&lt;' character and sorted using "i;octet" collation.</li>
<li>The input messsage X or S' would need to make it seem as if a desirable feature (e.g., end-to-end encryption) is not supported by other entities that advertise the same hash V even though the feature is indeed supported (i.e., the attacker would need to return a set of service discovery identities and features that match X or S', and have that set be plausible for an entity that communicates via XMPP).</li>
<li>The attacker would need to propagate the hash V before some other entity with the true input message S could broadcast presence with the relevant entity capabilities data and provide the true service discovery response (thus the attacker might need to subvert the development process of a particular software project or subvert the namespace issuance process of the &REGISTRAR;, or both).</li>
</ol>
<p>It currently seems extremely unlikely that an attacker could meet all of the foregoing conditions in the foreseeable future. However, the XMPP Council shall continue to monitor the state of cryptanalysis regarding the mandatory-to-implement hash function as well as the possibility that any vulnerabilities in that function might lead to practical threats against the entity capabilities protocol. If and when it becomes practical (or even possible) to launch effective preimage attacks against the entity capabilities protocol, the XMPP Council shall consider updating this specification to change the mandatory-to-implement hashing algorithm to a safer technology.</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>
@ -456,7 +468,7 @@
</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>
<p>A client MAY 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 SHOULD assume that the version is intended to be private and SHOULD NOT automatically send Software Version requests to the sender.</p>
</section2>
</section1>