moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

0.5

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1036 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-07-11 13:52:57 +00:00
parent 9fc8be7936
commit b7f29c155f
1 changed files with 35 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
xep-0165.xml
View File

@ -6,8 +6,8 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Best Practices to Prevent JID Mimicking</title>
<abstract>This document recommends best practices to prevent mimicking of Jabber IDs.</abstract>
<title>Best Practices to Discourage JID Mimicking</title>
<abstract>This document recommends best practices to discourage mimicking of Jabber IDs.</abstract>
&LEGALNOTICE;
<number>0165</number>
<status>Experimental</status>
@ -23,6 +23,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.5</version>
<date>2007-07-11</date>
<initials>psa</initials>
<remark><p>Updated to reflect changes to XEP-0189 syntax; completed editorial review.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2006-12-20</date>
@ -77,16 +83,16 @@
</section1>
<section1 topic='Recommendations' anchor='rec'>
<section2 topic='Presentation of JIDs' anchor='rec-jids'>
<p>Every human user of Jabber/XMPP technologies presumably has a preferred language (or, in some cases, a small set of preferred languages), which an XMPP application SHOULD gather either explicitly from the user or implicitly via the user's operating system. Furthermore, every language has a range of characters normally used to represent that language in textual form. Therefore, an XMPP application SHOULD warn the user when presenting a JID that uses characters outside the normal range of the user's preferred language(s). <note>This recommendation is not intended to discourage communication across language communities; instead, it simply recognizes the existence of such language communities and encourages due caution when presenting unfamiliar character sets to human users.</note></p>
<p>Every human user of Jabber/XMPP technologies presumably has a preferred language (or, in some cases, a small set of preferred languages), which an XMPP application SHOULD gather either explicitly from the user or implicitly via the operating system of the user's device. Furthermore, every language has a range of characters normally used to represent that language in textual form. Therefore, an XMPP application SHOULD warn the user when presenting a JID that uses characters outside the normal range of the user's preferred language(s). <note>This recommendation is not intended to discourage communication across language communities; instead, it simply recognizes the existence of such language communities and encourages due caution when presenting unfamiliar character sets to human users.</note></p>
</section2>
<section2 topic='The Roster as a Petname System' anchor='rec-petname'>
<p>As explained in &petnames;, no one naming or address scheme can provide names that are simultaneously global, memorable, and unique. However, certain <em>combinations</em> of names and addresses can provide all three properties, and such combinations are commonly called "petname systems". Consider the following combination of names:</p>
<p>As explained in &petnames;, no one naming or address scheme can provide names that are simultaneously global, memorable, and unique. However, certain <em>combinations</em> of names and addresses can provide all three properties, and such combinations are commonly called "petname systems". In particular, the information contained in a user's roster (see &xmppim;) can be combined with information provided by a user's contacts to construct a petname system. Consider the following combination of names:</p>
<ol>
<li><p>The JID "stpeter@jabber.org" is globally unique on the Jabber/XMPP network, but it is not necessarily memorable.</p></li>
<li><p>The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &xep0172; for more information about user-asserted nicknames.</p></li>
<li><p>The handle or petname <note>For consistency with other XMPP specifications, we use the term "handle" rather than "petname"; in <cite>RFC 3921</cite> this was referred to as an "alias" but in <cite>rfc3921bis</cite> the term has been changed to "handle".</note> "that protocol dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique <note>If not shared or leaked, it may even be securely unique.</note> but is by no means global since it has meaning only to the person who assigns it; for consistency with <cite>XEP-0172</cite> we refer to this as a "handle".</p></li>
<li><p>The handle or petname "that protocol dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique <note>If not shared or leaked, it may even be securely unique.</note> but is by no means global since it has meaning only to the person who assigns it; for consistency with <cite>XEP-0172</cite> and &rfc3921bis; we refer to this as a "handle". <note>In <cite>RFC 3921</cite> this was referred to as an "alias".</note></p></li>
</ol>
<p>A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored as the value of the &lt;item/&gt; element's 'name' attribute qualified by the 'jabber:iq:roster' namespace (for details regarding roster syntax, refer to &rfc3921;). A client SHOULD then present that handle instead of or in addition to the contact's JID or nickname (e.g., in the user's roster and in chat interfaces). This will help to prevent mimicked addresses from being presented as equivalent to the address that is being mimicked.</p>
<p>A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored in the roster as the value of the &lt;item/&gt; element's 'name' attribute. A client SHOULD then present that handle instead of or in addition to the contact's JID or nickname (e.g., in the user's roster and in chat interfaces). This will help to discourage mimicked addresses from being presented as equivalent to the address that is being mimicked.</p>
</section2>
<section2 topic='Associating Security Credentials with Roster Items' anchor='rec-secure'>
<p>Although a Jabber ID can be considered globally unique, the petname system in which it is embedded can be strengthened by associating that JID with a key that can be used for signing and encryption (such as an OpenPGP key, X.509 certificate, or RSA key), preferably a key that encapsulates the associated XMPP address (e.g., as described in Section 5.1.1 of <cite>RFC 3920</cite>). A client SHOULD associate a key with the user of that client, and SHOULD generate such a key if the user does not have one.</p>
@ -102,55 +108,52 @@
</message>
]]></example>
<p>Here, the 'name' attribute encapsulates what in petname systems is known as an "alleged name", that is, the name for an entity proposed by a third party.</p>
<p>Such a referral SHOULD also include the user's nick as understood by the third person (encapsulated in the format defined in &xep0172;) and fingerprint of the user as understood by the third person (encapsulated in the format defined in &xep0189;:</p>
<p>Such a referral SHOULD also include the user's nick as understood by the third person (encapsulated in the format defined in XEP-0172) and fingerprint of the user as understood by the third person (encapsulated in the format defined in &xep0189;):</p>
<example caption='Referral With Nickname and Public Key'><![CDATA[
<message from='peter@saint-andre.com' to='MaineBoy@jabber.org'>
<x xmlns='http://jabber.org/protocol/rosterx'>
<item jid='stpeter@jabber.org' name='Peter Saint-Andre'/>
<item jid='stpeter@jabber.org' name='Peter Saint-Andre'>
<nick xmlns='http://jabber.org/protocol/nick'>psa</nick>
<pubkeys xmlns='http://www.xmpp.org/extensions/xep-0189.html#ns'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterRSAkey1</KeyName>
...
</KeyInfo>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterX509cert1</KeyName>
...
</KeyInfo>
</pubkeys>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterRSAkey1</KeyName>
...
</KeyInfo>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterX509cert1</KeyName>
...
</KeyInfo>
</item>
</x>
</message>
]]></example>
<p>The third person MUST NOT simply copy the key as communicated by the contact but instead MUST validate it against the public key of the contact.</p>
<p>The third person MUST NOT simply copy the key as communicated by the user but instead MUST validate it against the public key of the user.</p>
</section2>
<section2 topic='Subscription Requests' anchor='rec-subscriptions'>
<p>We have seen that, at a minimum, three names or address types are needed to provide a petname system for XMPP: a JID, a nickname, and a handle (preferably strengthened by inclusion of a fingerprint derived from a key). However, at present a subscription request contains only the JID of the sender:</p>
<example caption='A Basic Subscription Request'><![CDATA[
<presence from='stpeter@jabber.org to='MaineBoy@jabber.org' type='subscribe'/>
]]></example>
<p>Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in <cite>XEP-0172</cite>) and the sender's key or keys.</p>
<p>Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system (see &xep0154;). However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in <cite>XEP-0172</cite>) and the sender's key or keys.</p>
<example caption='Subscription Request With Nickname and Key'><![CDATA[
<presence from='stpeter@jabber.org to='MaineBoy@jabber.org' type='subscribe'>
<nick xmlns='http://jabber.org/protocol/nick'>psa</nick>
<pubkeys xmlns='http://www.xmpp.org/extensions/xep-0189.html#ns'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterRSAkey1</KeyName>
...
</KeyInfo>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterX509cert1</KeyName>
...
</KeyInfo>
</pubkeys>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterRSAkey1</KeyName>
...
</KeyInfo>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>stpeterX509cert1</KeyName>
...
</KeyInfo>
</presence>
]]></example>
<p>If one or more referrals have been received, the user or client MUST check the key or keys provided in the subscription request against the key or keys provided in the referral or referrals.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>In order for a user-assigned handle to strengthen the security of the petname system, it MUST NOT be shared with anyone other than the user who assigned it. The user SHOULD NOT assign as a handle the alleded name received in a referral.</p>
<p>A user SHOULD NOT place more trust a referral than he or she places in the person who sends it.</p>
<p>A client SHOULD NOT allow a user to assign as a handle the alleded name received in a referral.</p>
<p>In order for a user-assigned handle to strengthen the security of the petname system, the user must not shared the handle with other individuals.</p>
<p>A user should not place more trust in a referral than he or she places in the person who sends it.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>