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

0.8 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1840 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-05-12 19:31:10 +00:00
parent 440005e438
commit 6bd96e4513
1 changed files with 47 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
xep-0158.xml
View File

@ -25,6 +25,12 @@
<shortname>TO BE ASSIGNED</shortname>
&ianpaterson;
&stpeter;
<revision>
<version>0.8</version>
<date>2008-05-12</date>
<initials>psa</initials>
<remark><p>Move text regarding labels to new internationalization considerations section; removed necessity that ID of IQ-set shall match ID of challenge, since this is not consistent with existing usage that IDs are generated by the sender of an IQ.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2008-04-28</date>
@ -95,13 +101,13 @@
<section2 topic='Simple Challenge' anchor='protocol-simple'>
<p>An entity (client or server) MAY send a challenge immediately after receiving a stanza from another entitiy. An entity MUST NOT send challenges under any other circumstances. Hereafter, the entity that generates the stanza that triggers the challenge is called the "sender" and the entity that sends the challenge is called the "challenger".</p>
<example caption='Sender Generates Stanza'><![CDATA[
<message from='robot@spimmer.com/zombie'
<message from='robot@abuser.com/zombie'
to='innocent@victim.com'
xml:lang='en'
id='spam1'>
<body>Love pills - 75% OFF</body>
<x xmlns='jabber:x:oob'>
<url>http://www.spimmer.com/lovepills.html</url>
<url>http://www.abuser.com/lovepills.html</url>
</x>
</message>
]]></example>
@ -110,7 +116,7 @@
<p>The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not support the challenge form. Note: Even if it provides a URL, a challenger MUST always provide a challenge form. <note>A constrained client, like a mobile phone, cannot present a Web page to its user.</note></p>
<example caption='Challenger Offers a Choice of Challenges to Sender'><![CDATA[
<message from='victim.com'
to='robot@spimmer.com/zombie'
to='robot@abuser.com/zombie'
xml:lang='en'
id='F3A6292C'>
<body>
@ -179,7 +185,7 @@
<section3 topic='Response Stanza' anchor='protocol-response'>
<p>The sender's client SHOULD ignore the challenge stanza in either of the following cases:</p>
<ul>
<li>If it has not recently sent (e.g., in the last two minutes) a stanza to the JID specified in the 'from' field of the form with the 'id' specified in the 'sid' field (or with no 'id' if no 'sid' field is included). <note>Otherwise the user's presence would be disclosed, or a spim robot might dupe the user into providing answers to other people's challenges!</note></li>
<li>If it has not recently sent (e.g., in the last two minutes) a stanza to the JID specified in the 'from' field of the form with the 'id' specified in the 'sid' field (or with no 'id' if no 'sid' field is included). <note>Otherwise the user's presence would be disclosed, or a robot might dupe the user into providing answers to other people's challenges!</note></li>
<li>If the 'from' attribute of the challenge stanza does not match the 'from' field of the form. (If the values are different, then they still match if the bare JIDs are the same, or if the 'from' attribute is the domain of the other JID.)</li>
</ul>
<p>Otherwise, if the challenger provided a URL using <cite>Out-of-Band Data</cite>, then the sender's client MAY present the URL to the sender, instead of responding to the challenge form, in any of the following cases:</p>
@ -188,7 +194,7 @@
<li>if it does not support all of the <em>required</em> challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
<li>if it does not support enough of the challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
</ul>
<p>Otherwise, the sender's client MUST respond to the challenge, preserving the 'id' attribute of the challenge stanza.</p>
<p>Otherwise, the sender's client MUST respond to the challenge.</p>
<p>The sender's client MUST respond with a &notacceptable; error in any of the following cases:</p>
<ul>
<li>if it does not support all of the required challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
@ -197,7 +203,7 @@
</ul>
<example caption='Sender Reports Challenge Not Acceptable'><![CDATA[
<message type='error'
from='robot@spimmer.com/zombie'
from='robot@abuser.com/zombie'
to='victim.com'
xml:lang='en'
id='F3A6292C'>
@ -209,10 +215,10 @@
<p>Otherwise, it MUST select one challenge according to the sender's preferences and submit the sender's response form to the challenger.</p>
<example caption='Sender Sends One Response to Challenger'><![CDATA[
<iq type='set'
from='robot@spimmer.com/zombie'
from='robot@abuser.com/zombie'
to='victim.com'
xml:lang='en'
id='F3A6292C'>
id='z140r0s'>
<challenge xmlns='urn:xmpp:tmp:challenge'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
@ -238,8 +244,8 @@
<example caption='Challenger Indicates Challenge Not Found'><![CDATA[
<iq type='error'
from='victim.com'
to='robot@spimmer.com/zombie'
id='F3A6292C'>
to='robot@abuser.com/zombie'
id='z140r0s'>
<error type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -249,15 +255,15 @@
<example caption='Challenger Tells Sender it Passed'><![CDATA[
<iq type='result'
from='victim.com'
to='robot@spimmer.com/zombie'
id='F3A6292C'/>
to='robot@abuser.com/zombie'
id='z140r0s'/>
]]></example>
<p>However, if the sender submits an incorrect response the challenger SHOULD send it a &notacceptable; error with type "cancel": <note>If a large proportion of the responses a server is receiving from another IP are incorrect then it SHOULD inform the administrator of the other server using the protocol specified in &xep0161; or &xep0236;. It SHOULD also automatically block all stanzas from the abusive user, users, server or IP.</note></p>
<example caption='Challenger Tells Sender it Failed'><![CDATA[
<iq type='error'
from='victim.com'
to='robot@spimmer.com/zombie'
id='F3A6292C'>
to='robot@abuser.com/zombie'
id='z140r0s'>
<error type='cancel'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -269,7 +275,7 @@
<p>The challenger MAY demand responses to more than one of the challenges it is offering; this is done by including an 'answers' &lt;field/&gt; element in the form. The challenger also MAY require responses to particular challenges; this is done by including &lt;required/&gt; elements in the compulsory fields.</p>
<example caption='Challenger Sets Multiple Challenges'><![CDATA[
<message from='victim.com'
to='robot@spimmer.com/zombie'
to='robot@abuser.com/zombie'
xml:lang='en'
id='73DE28A2'>
<body>Your messages to innocent@victim.com are being blocked.
@ -310,7 +316,7 @@
<p>If the sender finds the request acceptable, it MUST answer all challenges that include a &lt;required/&gt; element. If the total number of answers was specified and it is greater than the number of &lt;required/&gt; elements then the sender MUST also answer one or more of the challenges without a &lt;required/&gt; element. In the example above, the sender should respond to the 'qa' challenge <em>and</em> one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').</p>
<example caption='Sender Sends Multiple Responses to the Challenger'><![CDATA[
<iq type='set'
from='robot@spimmer.com/zombie'
from='robot@abuser.com/zombie'
to='victim.com'
xml:lang='en'
id='73DE28A2'>
@ -399,12 +405,12 @@
<section1 topic='Multi-User Chat' anchor='muc'>
<p>A service that hosts multi-user chat rooms in accordance with <cite>XEP-0045</cite> MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms.</p>
<example caption='Sender Attempts to Join Chat Room'><![CDATA[
<presence from='robot@spimmer.com/zombie'
<presence from='robot@abuser.com/zombie'
to='friendly-chat@muc.victim.com'/>
]]></example>
<example caption='Challenger Offers a Choice of Challenges to Sender'><![CDATA[
<message from='muc.victim.com'
to='robot@spimmer.com/zombie'
to='robot@abuser.com/zombie'
id='A4C7303D'>
<body>
Your messages to friendly-chat@muc.victim.com are being blocked. To unblock
@ -469,23 +475,23 @@
]]></example>
</section1>
<section1 topic='Challenge Types' anchor='captcha'>
<section2 topic='Introduction' anchor='captcha-intro'>
<section1 topic='Challenge Types' anchor='challenge'>
<section2 topic='Introduction' anchor='challenge-intro'>
<p>Entities MUST address the needs of disabled people and CPU-constrained clients by offering senders a reasonable choice of different types of challenges.</p>
<p>Desktop clients running on modern PCs will typically be configured to automatically perform a specified 'SHA-256' Hashcash challenge (see below) whenever it is below a certain level of difficulty, with the result that many people may not even notice challenges most of the time. However, people using CPU-constrained clients (e.g. Web or mobile clients) would notice the performance hit. They might prefer to take a CAPTCHA challenge instead. <note>A CPU-constrained client could ask a faster computer (e.g., its server) to perform a Hashcash challenge for it.</note></p>
<p>Visually disabled people using a CPU-constrained client could configure their client to always present them with an audio CAPTCHA challenge.</p>
<p>Most of the challenges below are language sensitive. However, the evaluation of the OCR and Hashcash responses does not depend on the language the sender is using.</p>
<p>Challenge types are distinguished by the 'var' attribute of each &lt;field/&gt; element. Several types of challenges are described below. More challenges MAY be documented elsewhere and registered with the XMPP Registrar (see <link url='#registrar-formtypes'>Field Standardization</link>).</p>
</section2>
<section2 topic='SHA-256 Hashcash' anchor='captcha-hashcash'>
<p>The SHA-256 Hashcash challenge is transparent to average PC users. It is indicated when the value of the 'var' attribute is 'SHA-256'. It forces clients to perform CPU-intensive work, making it difficult to send large amounts of spim. This significantly reduces spim, but alone it will not completely stop spim being sent through large collections of 'zombie' computers. <note>The hope is that the extra CPU usage will often be noticed by the owners of the zombie machines, who will be more likely to fix them.</note></p>
<section2 topic='SHA-256 Hashcash' anchor='challenge-hashcash'>
<p>The SHA-256 Hashcash challenge is transparent to average PC users. It is indicated when the value of the 'var' attribute is 'SHA-256'. It forces clients to perform CPU-intensive work, making it difficult to send large amounts of spim. This significantly reduces spim, but alone it will not completely stop abusive stanzas from being sent through large collections of 'zombie' computers. <note>The hope is that the extra CPU usage will often be noticed by the owners of the zombie machines, who will be more likely to fix them.</note></p>
<p>The challenger MUST set the 'label' attribute of the &lt;field/&gt; element to a hexadecimal random number containing a configured number of bits (e.g., 2<span class='super'>20</span> &#8804; label &lt; 2<span class='super'>21</span>).</p>
<p>To pass the test, the sender MUST return a text string that starts with the JID the sender sent the first stanza to (i.e., the stanza that triggered the challenge). The least significant bits of the SHA-256 hash (see &nistfips180-2;) of the string MUST equal the hexadecimal value specified by the challenger (in the 'label' attribute of the &lt;field/&gt; element). For example, if the 'label' attribute is the 20-bit value 'e03d7' then the following string would be correct:</p>
<code>innocent@victim.com2450F06C173B05E3</code>
<p>Note: When configuring the number of bits to be specified by a challenger in the 'label' attribute values, administrators MUST balance the need to make mass spim as difficult as possible, with the inconvenience that may be caused to the users of less powerful computers. (Most clients will be challenged only very occasionally, so the consumption of 70% of a typical desktop CPU for 4 seconds might be considered appropriate.) Administrators SHOULD increment the configured number of bits from time to time to match increases in the performance of typical desktop PCs. If an administrator notices that spim robots never attempt the Hashcash challenge, then he SHOULD consider reducing the number of bits, to avoid inconveniencing people unnecessarily.</p>
<p>Note: When configuring the number of bits to be specified by a challenger in the 'label' attribute values, administrators MUST balance the need to make mass abuse as difficult as possible, with the inconvenience that may be caused to the users of less powerful computers. (Most clients will be challenged only very occasionally, so the consumption of 70% of a typical desktop CPU for 4 seconds might be considered appropriate.) Administrators SHOULD increment the configured number of bits from time to time to match increases in the performance of typical desktop PCs. If an administrator notices that abusive robots never attempt the Hashcash challenge, then he SHOULD consider reducing the number of bits, to avoid inconveniencing people unnecessarily.</p>
</section2>
<section2 topic='CAPTCHAs' anchor='captcha-captcha'>
<p>For those CAPTCHA types where generic instructions are possible (see table below) then the &lt;field/&gt; element SHOULD NOT include a 'label' attribute (the client MUST present generic instructions to the sender in the language of its user interface). Otherwise the 'label' attribute SHOULD ask a specific question in the language indicated by the 'xml:lang' attribute of the challenge stanza.</p>
<section2 topic='CAPTCHAs' anchor='challenge-captcha'>
<p>Note: It may be profitable to send abusive stanzas even if less than one percent of CAPTCHA responses are successful. The effectiveness of a CAPTCHA challenge needs to be close to perfect, unless it is used in combination with other anti-abuse techniques.</p>
<p>If a media type is specified (see table below) then the &lt;field/&gt; element MUST contain a &lt;media/&gt; element that includes a &lt;uri/&gt; element of that type. Clients that support the CAPTCHA type MUST be able to play or render the specified MIME-types (see table below). They MAY also support other formats. <note>Audio CAPTCHAs typically require challengers to provide at least the 'audio/x-wav' MIME-type (with the PCM codec) because more efficient patent-free formats are often not supported by constrained clients. It is RECOMMENDED that challengers provide more compact formats (like Ogg Speex or MP3) too.</note></p>
<p>The 'type' attribute of the &lt;field/&gt; element SHOULD be 'text-single', 'text-private', or 'text-multi' (if no 'type' is specified, the default is 'text-single'). <note>The 'boolean' and 'list-single' field types would make it trivial for a robot to provide a correct response at least some of the time.</note> The response MUST be provided in the language specified by the 'xml:lang' attribute of the challenge stanza.</p>
<table caption='CAPTCHAs'>
@ -494,23 +500,20 @@
<th>Name</th>
<th>Media type</th>
<th>MIME-type</th>
<th>'label'</th>
<th>Example generic instructions</th>
<th>Example generic instructions *</th>
</tr>
<tr>
<td>audio_recog</td>
<td>Audio Recognition</td>
<td>audio</td>
<td>audio/x-wav</td>
<td>No</td>
<td>Describe the sound you hear</td>
</tr>
<tr>
<td>ocr *</td>
<td>ocr **</td>
<td>Optical Character Recognition</td>
<td>image</td>
<td>image/jpeg</td>
<td>No</td>
<td>Enter the code you see</td>
</tr>
<tr>
@ -518,7 +521,6 @@
<td>Picture Question</td>
<td>image</td>
<td>image/jpeg</td>
<td>No</td>
<td>Answer the question you see</td>
</tr>
<tr>
@ -526,15 +528,13 @@
<td>Picture Recognition</td>
<td>image</td>
<td>image/jpeg</td>
<td>No</td>
<td>Describe the picture</td>
<td>Identify the picture</td>
</tr>
<tr>
<td>qa</td>
<td>Text Question and Answer</td>
<td>-</td>
<td>-</td>
<td>Yes**</td>
<td>-</td>
</tr>
<tr>
@ -542,7 +542,6 @@
<td>Speech Question</td>
<td>audio</td>
<td>audio/x-wav</td>
<td>No</td>
<td>Answer the question you hear</td>
</tr>
<tr>
@ -550,7 +549,6 @@
<td>Speech Recognition</td>
<td>audio</td>
<td>audio/x-wav</td>
<td>No</td>
<td>Enter the words you hear</td>
</tr>
<tr>
@ -558,7 +556,6 @@
<td>Video Question</td>
<td>video</td>
<td>video/mpeg</td>
<td>No</td>
<td>Answer the question in the video</td>
</tr>
<tr>
@ -566,13 +563,11 @@
<td>Video Recognition</td>
<td>video</td>
<td>video/mpeg</td>
<td>No</td>
<td>Describe the video</td>
<td>Identify the video</td>
</tr>
</table>
<p>* The image portrays random characters that humans can read but OCR software cannot. <note>See PWNtcha &lt;<link url='http://sam.zoy.org/pwntcha/'>http://sam.zoy.org/pwntcha/</link>&gt; for some example OCR CAPTCHA images.</note> To pass the challenge, the sender must simply type the characters. The correct answer SHOULD NOT depend on the language specified by the 'xml:lang' attribute of the challenge stanza.</p>
<p>** To pass the challenge, the sender must type the answer to the question in the 'label' attribute.</p>
<p>Note: It may be profitable to send spim even if less than one percent of CAPTCHA responses are successful. The effectiveness of a CAPTCHA challenge needs to be close to perfect, unless it is used in combination with other anti-spim techniques.</p>
<p>* See the <link url='#i18n'>Internationalization Considerations</link> section of this document.</p>
<p>** The image portrays random characters that humans can read but OCR software cannot. <note>See PWNtcha &lt;<link url='http://sam.zoy.org/pwntcha/'>http://sam.zoy.org/pwntcha/</link>&gt; for some example OCR CAPTCHA images.</note> To pass the challenge, the sender must simply type the characters. The correct answer SHOULD NOT depend on the language specified by the 'xml:lang' attribute of the challenge stanza.</p>
</section2>
</section1>
@ -583,7 +578,7 @@
<p>Note: Even if it provides a text question in the &BODY; element, a challenger MUST always provide a challenge form.</p>
<example caption='Challenger Includes a Legacy Challenge'><![CDATA[
<message from='innocent@victim.com/pda'
to='robot@spimmer.com/zombie'
to='robot@abuser.com/zombie'
xml:lang='en'
id='F3A6292C'>
<body>Your messages to me are being blocked. To unblock them,
@ -603,14 +598,14 @@
]]></example>
<p>Legacy clients respond to the challenger using a &MESSAGE; stanza (not an &IQ;).</p>
<example caption='Legacy Sender Responds'><![CDATA[
<message from='robot@spimmer.com/zombie' to='innocent@victim.com/pda'>
<message from='robot@abuser.com/zombie' to='innocent@victim.com/pda'>
<body>red F3A6292C</body>
</message>
]]></example>
<p>The challenger SHOULD treat the stanza as a normal message (instead of as a response to its challenge) if the legacy client either takes too long to submit it or has already responded to the challenge. The challenger MAY treat the response as a normal message even in cases where the challenge became unnecessary while the challenger was waiting for the response.</p>
<p>Otherwise the challenger MUST report the result of the challenge to the legacy client using a &MESSAGE; stanza (not an &IQ;).</p>
<example caption='Challenger Tells Legacy Sender it Passed'><![CDATA[
<message from='innocent@victim.com/pda' to='robot@spimmer.com/zombie'>
<message from='innocent@victim.com/pda' to='robot@abuser.com/zombie'>
<body>Your message was delivered. Your messages
to me are no longer being blocked.</body>
</message>
@ -618,7 +613,7 @@
<example caption='Challenger Tells Legacy Sender it Failed'><![CDATA[
<message type='error'
from='innocent@victim.com/pda'
to='robot@spimmer.com/zombie'>
to='robot@abuser.com/zombie'>
<error type='cancel'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
@ -630,16 +625,20 @@
</section1>
<section1 topic='Discontinuation Policy' anchor='stop'>
<p>It is RECOMMENDED that entities employ other techniques to combat spim in addition to those described in this document (e.g., see <cite>XEP-0161</cite> and &xep0205;).</p>
<p>It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see <cite>XEP-0161</cite> and &xep0205;).</p>
<p>It is expected that this protocol will be an important and successful tool for discouraging spim. However, much of its success is dependent on the quality of the CAPTCHAs employed by a particular implementation.</p>
<p>The administrator of a challenger MUST discontinue the use of Robot Challenges under the following circumstances:</p>
<ul>
<li>If he realises that the challenger's challenges are largely ineffective in combating spim, and that the reduction in spim does not compensate for the inconvenience to humans of responding to the challenger's challenges.</li>
<li>If he realises that the challenger's challenges are largely ineffective in combating spim, and that the reduction in abuse does not compensate for the inconvenience to humans of responding to the challenger's challenges.</li>
<li>If other, <em>more transparent</em>, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against spim.</li>
<li>If the challenger needs no protection at all because it receives only a negligible amount of spim.</li>
</ul>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>Each form field SHOULD include a 'label' attribute. If the sender did not include an 'xml:lang' attribute, then the challenger may not know the correct language for the labels. Therefore, depending on user preferences the client that receives a challenge MAY present generic but localized text instead of label text that would not be understood by the user. Recommended generic text (to be suitably localized) is provided by <link url='#table-1'>Table 1</link> in the <link url='#challenge-captcha'>CAPTCHAs</link> section of this document.</p>
</section1>
<section1 topic='Security Considerations' anchor='sec'>
<p>This document introduces no security considerations above and beyond those described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</p>
</section1>