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

added missing disco support

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3372 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Unknown User 2009-08-31 17:49:16 +00:00
parent feebebbf46
commit ede68a2281
1 changed files with 37 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
xep-0076.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>Malicious Stanzas</title> <title>Malicious Stanzas</title>
<abstract>This document defines an XMPP protocol extension for flagging malicious stanzas within Jabber/XMPP.</abstract> <abstract>This document defines an XMPP protocol extension for flagging malicious stanzas.</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0076</number> <number>0076</number>
<status>Active</status> <status>Active</status>
@ -30,24 +30,24 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction'> <section1 topic='Introduction'>
<p>&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &XSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for Jabber support of evil.</p> <p>&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &XSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for XMPP support of evil.</p>
</section1> </section1>
<section1 topic='Requirements and Approach'> <section1 topic='Requirements and Approach'>
<p>There are three basic Jabber stanza types that may be sent within XML streams:</p> <p>There are three basic XMPP stanza types that may be sent within XML streams:</p>
<ul> <ul>
<li>&lt;message/&gt; -- a "push" medium for sending information to other entities.</li> <li>&lt;message/&gt; -- a "push" medium for sending information to other entities.</li>
<li>&lt;presence/&gt; -- a "broadcast" medium for publishing information to entities that have subscribed to an entity's availability status.</li> <li>&lt;presence/&gt; -- a "broadcast" medium for publishing information to entities that have subscribed to an entity's availability status.</li>
<li>&lt;iq/&gt; -- a "request-response" medium for executing basic but structured transactions with other entities.</li> <li>&lt;iq/&gt; -- a "request-response" medium for executing basic but structured transactions with other entities.</li>
</ul> </ul>
<p>Any one of the foregoing data elements can be used with malicious intent. Therefore a generalized mechanism is needed. Because XML namespaces are used within Jabber to properly scope data, this document proposes a new namespace ('http://jabber.org/protocol/evil') to implement the desired functionality.</p> <p>Any one of the foregoing data elements can be used with malicious intent. Therefore a generalized mechanism is needed. Because XML namespaces are used within XMPP to properly scope data, this document proposes a new namespace ('http://jabber.org/protocol/evil') to implement the desired functionality.</p>
</section1> </section1>
<section1 topic='Use Cases'> <section1 topic='Use Cases'>
<section2 topic='Evil Messages'> <section2 topic='Evil Messages'>
<p>If a Jabber entity sends an evil message, it MUST include an appropriately namespaced extension in the message stanza:</p> <p>If an evil entity sends an evil message, it MUST include an appropriately namespaced extension in the message stanza:</p>
<example caption='Jabber Entity Sends Evil Message'><![CDATA[ <example caption='Evil Entity Sends Evil Message'><![CDATA[
<message <message
from='iago@shakespeare.lit/pda' from='iago@shakespeare.lit/pda'
to='emilia@shakespeare.lit/cell'> to='emilia@shakespeare.lit/mobile'>
<body> <body>
I told him what I thought, and told no more I told him what I thought, and told no more
Than what he found himself was apt and true. Than what he found himself was apt and true.
@ -57,8 +57,8 @@
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Evil Presence'> <section2 topic='Evil Presence'>
<p>If a Jabber entity sends evil presence information, it MUST include an appropriately namespaced extension in the presence stanza:</p> <p>If an evil entity sends evil presence information, it MUST include an appropriately namespaced extension in the presence stanza:</p>
<example caption='Jabber Entity Sends Evil Presence'><![CDATA[ <example caption='Evil Entity Sends Evil Presence'><![CDATA[
<presence from='iago@shakespeare.lit/pda'> <presence from='iago@shakespeare.lit/pda'>
<show>dnd</show> <show>dnd</show>
<status>Fomenting dissension</status> <status>Fomenting dissension</status>
@ -67,12 +67,11 @@
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Evil IQs'> <section2 topic='Evil IQs'>
<p>If a Jabber entity provides evil information in an IQ exchange, it MUST include an appropriately namespaced extension in the IQ stanza:</p> <p>If an evil entity provides evil information in an IQ exchange, it MUST include an appropriately namespaced extension in the IQ stanza:</p>
<example caption='Jabber Entity Sends Evil Message'><![CDATA[ <example caption='Evil Entity Sends Evil Message'><![CDATA[
<iq <iq from='iago@shakespeare.lit/pda'
from='iago@shakespeare.lit/pda' id='evil1'
to='emilia@shakespeare.lit/cell' to='emilia@shakespeare.lit/mobile'>
id='evil1'>
<query xmlns='jabber:iq:version'> <query xmlns='jabber:iq:version'>
<name>Stabber</name> <name>Stabber</name>
<version>666</version> <version>666</version>
@ -83,8 +82,30 @@
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Determining Support' anchor='disco'>
<p>Evil entities MUST advertise their support for this protocol in their responses to &xep0030; information ("disco#info") requests by returning a feature of "http://jabber.org/protocol/evil":</p>
<example caption='A disco#info query'><![CDATA[
<iq from='emilia@shakespeare.lit/mobile'
id='disco1'
to='iago@shakespeare.lit/pda'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq from='iago@shakespeare.lit/pda'
id='disco1'
to='emilia@shakespeare.lit/mobile'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='http://jabber.org/protocol/evil'/>
</query>
</iq>
]]></example>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>
<p>Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Jabber entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this document defines per-stanza evil only.</p> <p>Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this document defines per-stanza evil only.</p>
</section1> </section1>
<section1 topic='IANA Considerations'> <section1 topic='IANA Considerations'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>