This document recommends best practices to prevent the spoofing of Jabber IDs.
WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Last Updated: 2005-11-16
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/Prevention of JID Spoofing (JEP-0165)>
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
There are two forms of address spoofing: forging and mimicking. In the context of Jabber technologies, an address is forged when a 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 authenticated as "email@example.com" but is able to send XML stanzas from "MaineBoy@jabber.org" or "firstname.lastname@example.org". An address is mimicked 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 "email@example.com" (spelled with the number one as the final character of the node identifier) may appear to be the same as "firstname.lastname@example.org (spelled with the lower-case version of the letter "L"). A more sophisticated example (which may not render correctly in all browsers) is the following:
That JID is not an uppercase version of "email@example.com" in US-ASCII characters, but a fake JID made up mostly of Cherokee characters, namely:
U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 @ U+13AB U+13AA U+13F4 U+13F4 U+13AC U+13D2 .org
In this example, it is unlikely that the average user could tell the difference between the real JID and the fake JID. 
Traditionally, forging of JIDs has been very difficult in Jabber/XMPP systems given the requirement for servers to stamp 'from' addresses and for servers to verify sending domains via server dialback or server-to-server authentication (see RFC 3920 ). However, 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. 
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. 
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). 
As explained in Introduction to Petname Systems , no one naming or address scheme can provide names that are simultaneously global, memorable, and securely unique. However, certain combinations of names and addresses can provide all three properties, and such combinations are commonly called "petname systems". Consider the following combination of names:
A client SHOULD require an end user to assign a petname for every contact added to the person's roster, which SHOULD be stored as the value of the <item/> element's 'name' attribute qualified by the 'jabber:iq:roster' namespace. A client SHOULD then present that petname 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.
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 or certificate that can be used for signing and encryption (such as a PGP key or X.509 certificate), preferably a key or certificate that encapsulates the associated XMPP address (e.g., as described in Section 5.1.1 of RFC 3920). A client SHOULD associate a key or certificate with the user of that client, and SHOULD generate such a key or certificate if the user does not have one.
Unfortunately, keys, certificates, and fingerprints are even less memorable than JIDs, which makes the specification of a petname or alias even more important. Therefore, a client SHOULD keep track of the keys or certificates associated with the contacts in a user's roster in order to further strengthen the petname system.
We have seen that, at a minimum, three name or address types are needed to provide a petname system: a JID, a nickname, and an alias (preferably strengthened by inclusion of a key or certificate). However, at present a subscription request contains only the JID of the sender:
<presence firstname.lastname@example.org to='MaineBoy@jabber.org' type='subscribe'/>
Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, vcard-temp  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 Profile Data Representation  format: 
<presence email@example.com to='MaineBoy@jabber.org' type='subscribe'> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'><value>http://jabber.org/protocol/profiledata</value></field> <field var='nickname'><value>psa</value></field> </x> </presence>
In addition, the subscription request SHOULD also include the fingerprint of a key or certificate associated with the sender (encapsulated via the fingerprint protocol described below):
<presence firstname.lastname@example.org to='MaineBoy@jabber.org' type='subscribe'> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'><value>http://jabber.org/protocol/profiledata</value></field> <field var='nickname'><value>psa</value></field> <field var='x509_fingerprint_sha1'> <value>C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B</value> </field> </x> </presence>
The key or certificate SHOULD include the user's XMPP address, e.g. as described in Section 5.1.1 of RFC 3920.
In order to strengthen the web of interaction and trust between Jabber/XMPP users, it is helpful for them to share roster items. In particular, when a user wants to subscribe to the presence of a potential contact, the user SHOULD seek a referral from a third person who knows both the user and the contact. Such a referral consists of a roster item sent from the third person to the potential contact, encapsulated using the Roster Item Exchange  protocol:
<message email@example.com' to='MaineBoy@jabber.org'> <x xmlns='http://jabber.org/protocol/rosterx'> <item firstname.lastname@example.org' name='Peter Saint-Andre'/> </x> </message>
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.
Such a referral SHOULD also include the nick and fingerprint of the user as understood by the third person:
<message email@example.com' to='MaineBoy@jabber.org'> <x xmlns='http://jabber.org/protocol/rosterx'> <item firstname.lastname@example.org' name='Peter Saint-Andre'/> </x> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'><value>http://jabber.org/protocol/profiledata</value></field> <field var='nickname'><value>psa</value></field> <field var='x509_fingerprint_sha1'> <value>C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B</value> </field> </x> </message>
Here again, when a Jabber/XMPP client receives a referral, it SHOULD warn the contact if the JID uses characters outside the normal range of the contact's preferred language(s).
This entire document addresses security considerations.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) .
This document requires no interaction with the Jabber Registrar .
1. 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.
3. 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 Financial Services Technology Consortium Counter-Phishing Initiative: Phase I). To be precise, the current document (1) does not assume that such attacks will be broadly launched and (2) focuses on the misrepresentation only of Jabber IDs within the context of Jabber/XMPP systems.
4. 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.
5. 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.
6. Introduction to Petname Systems <http://www.skyhunter.com/marcs/petnames/IntroPetNames.html>.
9. While it could be argued that a less verbose format would be preferable (e.g., a specialized XML format), presence subscription requests are infrequent enough that the slightly more verbose format of Profile Data Representation is acceptable in this context.
11. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
12. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.