XEP-0165: Prevention of JID Spoofing

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

1. Introduction

2. Recommendations

2.1. Presentation of JIDs

2.2. The Jabber Roster as a Petname System

2.3. Associating Security Credentials with Roster Items

2.4. Referrals

2.5. Subscription Requests

3. Security Considerations

4. IANA Considerations

5. XMPP Registrar Considerations

Notes

Revision History

ᏚᎢᎵᎬᎢᎬᏒ@ᎫᎪᏴᏴᎬᏒ.org
  

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

2.1 Presentation of JIDs

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). [6]

2.2 The Jabber Roster as a Petname System

As explained in Introduction to Petname Systems [7], no one naming or address scheme can provide names that are simultaneously global, memorable, and 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:

1. The JID "stpeter@jabber.org" is globally unique on the Jabber network, but it is not necessarily memorable.

2. The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see User Nickname [8] for more information about user-asserted nicknames.

3. The handle or petname [9] "that JSF dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique [10] but is by no means global since it has meaning only to the person who assigns it; for consistency with XEP-0172 we refer to this as a "handle".

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 <item/> element's 'name' attribute qualified by the 'jabber:iq:roster' namespace (for details regarding roster syntax, refer to RFC 3921 [11]). 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.

2.3 Associating Security Credentials with Roster Items

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, 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, an alias for each contact) in order to further strengthen the petname system.

2.4 Referrals

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 [12] protocol:

Example 1. A Basic Referral

<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'/>
  </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 user's nick as understood by the third person (encapsulated in the format defined in User Nickname [13]) and fingerprint of the user as understood by the third person (encapsulated in the format defined in the proposal available at <http://www.jabber.org/jeps/inbox/fingerprint.html>:

Example 2. Referral With Nickname and Fingerprint

<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'/>
      <nick xmlns='http://jabber.org/protocol/nick'>psa</nick>
      <print xmlns='http://jabber.org/protocol/fingerprint' hashtype='sha1' keytype='x509'>
          C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B
      </print>
    </item>
  </x>
</message>
    

The third person MUST NOT simply copy the fingerprint as communicated by the contact but instead MUST validate the fingerprint against the public key or certificate of the contact.

2.5 Subscription Requests

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 or certificate). However, at present a subscription request contains only the JID of the sender:

Example 3. A Basic Subscription Request

<presence from='stpeter@jabber.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 [14] 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 XEP-0172) and the fingerprint of the sender's certificate or key.

Example 4. Subscription Request With Nickname and Fingerprint

<presence from='stpeter@jabber.org to='MaineBoy@jabber.org' type='subscribe'>
  <nick xmlns='http://jabber.org/protocol/nick'>psa</nick>
  <print xmlns='http://jabber.org/protocol/fingerprint' hashtype='sha1' keytype='x509'>
      C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B
  </print>
</presence>
    

If one or more referrals have been received, the user or client MUST check the fingerprint provided in the subscription request against the fingerprint provided in the referral or referrals.

1. This phenomenon is sometimes called "typejacking".

2. 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. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

4. 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 of Jabber IDs (not any other identifiers) within the context of Jabber/XMPP systems.

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

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

7. Introduction to Petname Systems <http://www.skyhunter.com/marcs/petnames/IntroPetNames.html>.

8. XEP-0172: User Nickname <http://www.xmpp.org/extensions/xep-0172.html>.

9. For consistency with other XMPP specifications, wee use the term "alias" rather than "petname".

10. If not shared or leaked, it may even be securely unique.

11. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

12. XEP-0144: Roster Item Exchange <http://www.xmpp.org/extensions/xep-0144.html>.

13. XEP-0172: User Nickname <http://www.xmpp.org/extensions/xep-0172.html>.

14. XEP-0054: vcard-temp <http://www.xmpp.org/extensions/xep-0054.html>.

15. 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/>.

16. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the Jabber Software Foundation. For further information, see <http://www.xmpp.org/registrar/>.

Version 0.3 (2006-06-10)

Version 0.2 (2006-03-28)

Version 0.1 (2005-11-16)

Version 0.0.2 (2005-11-14)

Version 0.0.1 (2005-09-28)