moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

1.24pre1

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1943 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-06-11 04:24:36 +00:00
parent 513246e8c0
commit b94c3bfd31
1 changed files with 19 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
xep-0045.xml
View File

@ -53,11 +53,7 @@
<version>1.24pre1</version>
<date>in progress, last updated 2008-06-10</date>
<initials>psa</initials>
<remark>
<ul>
<li>Added more examples of the reason element.</li>
</ul>
</remark>
<remark><p>Added more examples of the reason element; removed mention of nick inclusion with regard to ban lists; added denial of service considerations.</p></remark>
</revision>
<revision>
<version>1.23</version>
@ -426,10 +422,10 @@
<p>This document explicitly does <em>not</em> address the following:</p>
<ul>
<li>Relationships between rooms (e.g., hierarchies of rooms)</li>
<li>Management of multi-user chat services (e.g., managing permissions across an entire service or registering a global room nickname)</li>
<li>Management of multi-user chat services (e.g., managing permissions across an entire service or registering a global room nickname); such use cases are specified in &xep0133;</li>
<li>Moderation of individual messages</li>
<li>Security and encryption at the level of a room or service</li>
<li>Advanced features such as attaching files to a room, integrating whiteboards, and interfacing with audio chat services</li>
<li>Encryption of messages sent through a room</li>
<li>Advanced features such as attaching files to a room, integrating whiteboards, and interfacing with audio or video chat services</li>
<li>Interaction between MUC deployments and foreign chat systems (e.g., gateways to IRC or to legacy IM systems)</li>
<li>Mirroring or replication of rooms among multiple MUC deployments</li>
</ul>
@ -2747,7 +2743,7 @@
<p>If an admin or owner attempts to ban himself, the service MUST deny the request and return a &conflict; error to the sender. (Note: This is different from the recommended service behavior on kicking oneself, which a service may allow.)</p>
</section2>
<section2 topic='Modifying the Ban List' anchor='modifyban'>
<p>A room admin may want to modify the ban list. Note: The ban list is always based on a user's bare JID, although a nick (perhaps the last room nickname associated with that JID) MAY be included for convenience. To modify the list of banned JIDs, the admin first requests the ban list by querying the room for all users with an affiliation of 'outcast'.</p>
<p>A room admin may want to modify the ban list. Note: The ban list is always based on a user's bare JID. To modify the list of banned JIDs, the admin first requests the ban list by querying the room for all users with an affiliation of 'outcast'.</p>
<example caption='Admin Requests Ban List'><![CDATA[
<iq from='kinghenryv@shakespeare.lit/throne'
id='ban2'
@ -2809,7 +2805,7 @@
<li>&lt;domain/resource&gt; (only that resource matches)</li>
<li>&lt;domain&gt; (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)</li>
</ol>
<p>Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document (but see &xep0133;).</p>
<p>Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document, instead being defined in <cite>XEP-0133</cite>.</p>
</section2>
<section2 topic='Granting Membership' anchor='grantmember'>
<p>An admin can grant membership to a user; this is done by changing the user's affiliation to "member" (normally based on nick if the user is in the room, or on bare JID if not; in either case, if the nick is provided, that nick becomes the user's default nick in the room if that functionality is supported by the implementation):</p>
@ -4523,6 +4519,19 @@
<section2 topic='Anonymity' anchor='security-anon'>
<p>Depending on room configuration, a room MAY expose each occupant's real JID to other occupants (if the room is non-anonymous) and will almost certainly expose each occupant's real JID to the room owners and administrators (if the room is not fully-anonymous). A service MUST warn the user that real JIDs are exposed in the room by returning a status code of "100" with the user's initial presence, and the user's client MUST so warn the user (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether real JIDs are exposed in the room). A client MUST also warn the user if the room's configuration is subsequently modified from semi-anonymous or fully-anonymous to non-anonymous (which the client will discover when the room sends status code 172) and SHOULD warn the user if the room's configuration is subsequently modified from fully-anonymous to semi-anonymous (which the client will discover when the room sends status code 173).</p>
</section2>
<section2 topic='Denial of Service' anchor='security-dos'>
<p>Public MUC rooms can be subject to a number of attacks, most of which reduce to denial of service attacks. Such attacks include but are not limited to:</p>
<ol>
<li>Stuffing the room with a large number of illegitimate occupants and therefore preventing legitimate users from joining the room.</li>
<li>Sending abusive messages and then leaving the room before a kick or ban can be applied.</li>
<li>Making rapid and repeated presence changes.</li>
<li>Using long nicknames to route around lack of voice.</li>
<li>Abusing the room administrators or other room occupants.</li>
<li>Registering multiple nicknames across a service and therefore denying the use of those nicknames.</li>
<li>Mimicking another occupant's roomnick (e.g., by adding a space at the end or substituting visually similar characters), then sending messages from that roomnick in an effort to confuse the occupants.</li>
</ol>
<p>These attacks can be mitigated but not completely prevented through the liberal use of administrative actions such as banning, the presence of automated room bots with administrative privileges, implementation of intelligent content filtering, checking the IP addresses of connected users (not always possible in a distributed system), applying voice rules to presence as well as messaging, matching room nicks using more stringent rules than the Resourceprep profile of stringprep, etc. However, experience has shown that it is impossible to fully prevent attacks of this kind.</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>