<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE xep SYSTEM 'xep.dtd' [ <!ENTITY % ents SYSTEM 'xep.ent'> %ents; ]> <?xml-stylesheet type='text/xsl' href='xep.xsl'?> <xep> <header> <title>Incident Reporting</title> <abstract>This specification defines methods for incident reporting among XMPP server deployments.</abstract> &LEGALNOTICE; <number>xxxx</number> <status>ProtoXEP</status> <type>Standards Track</type> <sig>Standards</sig> <approver>Council</approver> <dependencies> <spec>XMPP Core</spec> </dependencies> <supersedes/> <supersededby/> <shortname>NOT_YET_ASSIGNED</shortname> <discuss>operators</discuss> <author> <firstname>Artur</firstname> <surname>Hefczyc</surname> <email>artur.hefczyc@gmail.com</email> <jid>artur.hefczyc@tigase.org</jid> </author> <author> <firstname>Florian</firstname> <surname>Jensen</surname> <email>admin@flosoft.biz</email> <jid>admin@im.flosoft.biz</jid> </author> <author> <firstname>Mickaël</firstname> <surname>Rémond</surname> <email>mickael.remond@process-one.net</email> <jid>mremond@process-one.net</jid> </author> &stpeter; <author> <firstname>Matthew</firstname> <surname>Wild</surname> <email>mwild1@gmail.com</email> <jid>mwild1@jaim.at</jid> </author> <revision> <version>0.0.3</version> <date>2009-04-30</date> <initials>psa</initials> <remark><p>Per Council feedback, moved server rosters to a separate specification.</p></remark> </revision> <revision> <version>0.0.2</version> <date>2009-04-27</date> <initials>psa/fj</initials> <remark><p>Refactored XML format; added elements for sub-categories, locations, related incidents, solutions, and suggestions.</p></remark> </revision> <revision> <version>0.0.1</version> <date>2009-04-13</date> <initials>ah/fj/psa/mr/mw</initials> <remark><p>First draft.</p></remark> </revision> </header> <section1 topic='Introduction' anchor='intro'> <p>As XMPP technologies have been deployed more widely, the open XMPP network has become a more significant target for attacks. This specification defines ways for XMPP server deployments to share information with each other and therefore handle such attacks in a more real-time fashion. In particular, it defines a format for sharing incident reports among XMPP server deployments. (For some related considerations, see &rfc2350;, &rfc3067;, and &rfc5070;.)</p> </section1> <section1 topic='Incident Reports' anchor='reports'> <p>An incident report consists of an XMPP &MESSAGE; stanza containing an <incident/> child element that includes an 'id' attribute whose value is a UUID as described in &rfc4122;. An example is shown below. A server deployment SHOULD send incident reports only to peer servers that it trusts, for example peers that are in its "server roster".</p> <example caption="An incident report"><![CDATA[ <message from='jabber.org' to='im.flosoft.biz'> <incident xmlns='urn:xmpp:incident:0' id='BA51A035-7710-4558-9BBF-34838A4C5B24'> <description> <discuss> <admin>stpeter@jabber.org</admin> <muc>operators@conference.jabber.org</muc> </discuss> <info> <category>muc</category> <type>presence</type> <type>long-messages</type> </info> <locs> <loc>jdev@conference.jabber.org</loc> <loc>jabber@conference.jabber.org</loc> </locs> <rels> <rel>133BCE2E-E669-4ECE-B0F8-766B9E65630D</rel> </rels> <severity>2</severity> <source> <ips> <ip>192.0.2.1</ip> </ips> <jids> <jid>abuser@abuse.lit</jid> <jid>loser@abuse.lit</jid> </jids> </source> <text xml:lang='en'>lots of MUC spammers from abuse.lit!</text> <time> <begin>2009-04-13T19:05:20Z</begin> <end>2009-04-13T19:27:22Z</end> <report>2009-04-13T19:31:07Z</report> </time> </description> </incident> </message> ]]></example> <p>The defined children of the <description/> element are as follows:</p> <table caption='<description/> children'> <tr> <th>Element Name</th> <th>Description</th> </tr> <tr> <td><discuss/></td> <td>This element contains the JID of the server admin who generated the incident report (<admin/>), as well as a &xep0045; room where the incident can be discussed (<muc/>).</td> </tr> <tr> <td><info/></td> <td>Structured information about the incident. The defined values of the <category/> and <type/> elements shall be provided via a registry. It is envisioned that the <category/> values shall be "muc" for &xep0045; incidents, "pubsub" for &xep0060; incidents, "reg" for account registration (&xep0077;) incidents, and "stanzas" for general XMPP traffic incidents.</td> </tr> <tr> <td><locs/></td> <td>The place or places on the XMPP network where the incident has occurred (such as a multi-user chat room, a publish-subscribe service, or a general XMPP server), each contained in a separate <loc/> element.</td> </tr> <tr> <td><rels/></td> <td>The IDs of one or more incidents to which this incident might be related, each contained in a separate <rel/> element.</td> </tr> <tr> <td><severity/></td> <td>The seriousness of the problem, from 5 (least serious) to 1 (most serious).</td> </tr> <tr> <td><source/></td> <td>The IP address(es) and JabberID(s) where the incident originated.</td> </tr> <tr> <td><text/></td> <td>A natural-language description of the event. This element SHOULD possess an 'xml:lang' attribute. Multiple <text/> elements MAY be included, each with a different 'xml:lang' value.</td> </tr> <tr> <td><time/></td> <td>The time when the incident began and ended (include an empty <end/> element if the incident is still happening) and, optionally, was reported. The dates MUST conform to the DateTime profile specified in &xep0082;</td> </tr> </table> </section1> <section1 topic='Incident Solutions' anchor='solutions'> <p>If the reporting entity determines a solution to the problem, it MAY send out a revised incident report containing a <solution/> element.</p> <example caption="An incident solution"><![CDATA[ <message from='jabber.org' to='im.flosoft.biz'> <incident xmlns='urn:xmpp:incident:0' id='BA51A035-7710-4558-9BBF-34838A4C5B24'> <description> ... </description> <solution> <text xml:lang='en'>banned the offenders</text> </solution> </incident> </message> ]]></example> <p>Further definition of the <solution/> element will be provided in a future version of this specification.</p> </section1> <section1 topic='Incident Suggestions' anchor='suggestions'> <p>If an entity that receives an incident report has a suggested solution to the problem, it MAY send an incident message containing a <suggestion/> element.</p> <example caption="An incident solution"><![CDATA[ <message from='im.flosoft.biz' to='jabber.org'> <incident xmlns='urn:xmpp:incident:0' id='BA51A035-7710-4558-9BBF-34838A4C5B24'> <suggestion> <text xml:lang='en'>here is how we solved the problem...</text> </suggestion> </incident> </message> ]]></example> <p>Further definition of the <suggestion/> element will be provided in a future version of this specification.</p> </section1> <section1 topic='Security Considerations' anchor='security'> <p>To follow.</p> </section1> <section1 topic='IANA Considerations' anchor='iana'> <p>To follow.</p> </section1> <section1 topic='XMPP Registrar Considerations' anchor='registrar'> <p>To follow.</p> </section1> <section1 topic='XML Schema' anchor='schema'> <p>To follow.</p> </section1> </xep>