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.6

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1471 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-12-14 00:20:52 +00:00
parent d4ac2fe09f
commit dfcf57731d
1 changed files with 12 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
xep-0165.xml
View File

@ -23,6 +23,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.6</version>
<date>2007-12-13</date>
<initials>psa</initials>
<remark><p>Added security consideration about storage of handle in the roster.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2007-07-11</date>
@ -69,6 +75,7 @@
<section1 topic='Introduction' anchor='intro'>
<p>There are two forms of address spoofing: forging and mimicking.</p>
<p>In the context of Jabber/XMPP technologies, an address is <em>forged</em> when an entity is able to generate an XML stanza whose 'from' address does not correspond to the account credentials with which the entity authenticated onto the network -- for example, if an entity that authenticated as "stpeter@jabber.org" is able to send XML stanzas from "MaineBoy@jabber.org" or "peter@saint-andre.com".</p>
<p>Address forging is difficult in Jabber/XMPP systems given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server dialback or server-to-server authentication (see &rfc3920;). Difficult, but not impossible: a rogue server could forge JIDs at the sending domain by ignoring the stamping requirement and could even forge JIDs at other domains by means of a DNS poisoning attack. However, discussion of ways to deal with such rogue servers is out of scope for this document.</p>
<p>An address is <em>mimicked</em> when an entity provides legitimate authentication credentials for and sends XML stanzas from an account whose Jabber ID (JID) appears to a human user to be the same as another JID -- for example, in some clients "paypa1@jabber.org" (spelled with the number one as the final character of the node identifier) may appear to be the same as "paypal@jabber.org (spelled with the lower-case version of the letter "L"). <note>This phenomenon is sometimes called "typejacking".</note> A more sophisticated example of address mimicking (which may not render correctly in all browsers) is the following:</p>
<code>
&#5082;&#5026;&#5045;&#5036;&#5026;&#5036;&#5074;@&#5035;&#5034;&#5108;&#5108;&#5036;&#5074;.org</code>
@ -78,8 +85,7 @@
@
U+13AB U+13AA U+13F4 U+13F4 U+13AC U+13D2 .org</code>
<p>In this example, it is unlikely that the average user could tell the difference between the real JID and the fake JID. <note>Naturally, there is no way to distinguish with full certainty which is the fake JID and which is the real JID. For example, in some communication contexts, the Cherokee JID may be the real JID and the US-ASCII JID may thus appear to be the fake JID.</note></p>
<p>Traditionally, forging of JIDs has been very difficult in Jabber/XMPP systems given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server dialback or server-to-server authentication (see &rfc3920;). Difficult, but not impossible: a rogue server could forge JIDs at the sending domain by ignoring the stamping requirement and could even forge JIDs at other domains by means of a DNS poisoning attack. However, discussion of ways to deal with such rogue servers is out of scope for this document.</p>
<p>By contrast, it may be relatively easy to mimic (some) JIDs in Jabber/XMPP systems, especially because JIDs can contain almost any Unicode character. The possibility of address mimicking introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing. <note>Phishing has been defined as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them" (see <link url='http://fstc.org/projects/counter-phishing-phase-1/'>Financial Services Technology Consortium Counter-Phishing Initiative: Phase I</link>). To be precise, the current document (1) does not assume that such attacks will be broadly launched and (2) focuses on the misrepresentation of Jabber IDs (not any other identifiers) within the context of Jabber/XMPP systems.</note> To combat those vulnerabilities, this document recommends a set of best practices to minimize the potential impact of address mimicking on the Jabber/XMPP network. <note>This document does not cover handling of non-XMPP addresses, for example HTTP URLs. Jabber/XMPP clients SHOULD handle such addresses in accordance with best practices for the relevant non-XMPP technology.</note></p>
<p>By contrast with address forging, it may be relatively easy to mimic (some) JIDs in Jabber/XMPP systems, especially because JIDs can contain almost any Unicode character. The possibility of address mimicking introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing. <note>Phishing has been defined as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them" (see <link url='http://fstc.org/projects/counter-phishing-phase-1/'>Financial Services Technology Consortium Counter-Phishing Initiative: Phase I</link>). To be precise, the current document (1) does not assume that such attacks will be broadly launched and (2) focuses on the misrepresentation of Jabber IDs (not any other identifiers) within the context of Jabber/XMPP systems.</note> To combat those vulnerabilities, this document recommends a set of best practices to minimize the potential impact of address mimicking on the Jabber/XMPP network. <note>This document does not cover handling of non-XMPP addresses, for example HTTP URLs. Jabber/XMPP clients SHOULD handle such addresses in accordance with best practices for the relevant non-XMPP technology.</note></p>
</section1>
<section1 topic='Recommendations' anchor='rec'>
<section2 topic='Presentation of JIDs' anchor='rec-jids'>
@ -92,10 +98,10 @@
<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 "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 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>
<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 (see the <link url='#security'>Security Considerations</link> section of this document for further discussion). 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>
<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 6.4 of <cite>rfc3920bis</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>
<p>Unfortunately, cryptographic identities such as keys, certificates, and fingerprints are even less memorable than JIDs, which makes assigning a handle even more important. Therefore, if a contact provides such a cryptographic identity, a client MUST reliably associate it with the contact in a user's roster (including, as mentioned, a handle for each contact) in order to further strengthen the petname system.</p>
</section2>
<section2 topic='Referrals' anchor='rec-referrals'>
@ -151,8 +157,8 @@
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<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 client should not allow a user to assign as a handle the alleged 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. If the handle is stored in the user's roster, the handle may be compromised since roster storage is not necessarily a secure medium (e.g., the handle could be read by a server administrator). If the server is not trusted by the user, the client should store the handle locally on the user's device rather than in the roster.</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'>