Anatomy Of A Jabber Address
In much the same way as an e-mail address is constructed, a Jabber address is also composed from multiple individual components. Jabber-IDs (JIDs) take the form node@domain.tld, which makes them about as easy to remember as e-mail addresses. On the client-side, JIDs may be associated with additional resource data, much like the resource fork associated with file names in the Mac OS. This enables users to establish parallel connections with a Jabber server using the same JID for each individual connection. Thus, for example, a user might create a permanent connection from his or her home PC to a specific Jabber server with a JID, but also to use the same JID to connect to the Jabber network from a notebook PC while on the road. The resource data includes a priority setting, to enable the Jabber server to determine exactly which IP address to use when interacting inside a specific chat setting.
Encrypted Communications
In addition to encrypting the link between a Jabber client and a Jabber server - in addition to those used for server-to-server communications, as described earlier - Jabber also permits encryption for client-to-client communications as well. In fact, users may employ any of three different encryption methods to this end. As with e-mail encryption, one such method makes use of secure multipurpose Internet mail extensions, aka S/MIME, as described in . Alas, this implementation comes with considerable overhead and a steep learning curve, so that the majority of Jabber developers tend to skip it when building client software.
One of the most widely used encryption methods in the Jabber developer community is based on Open PGP. This particular XEP is described in the Jabber Open PGP Usage document, with the proviso that this encryption method has yet to be enshrined as an Internet standard. Another issue is that OpenPGP-based encryption is subject to a vulnerability: because user encryption keys assigned to users may not be changed for long periods of time, captured communications can be decrypted if the encryption key is stolen or cracked through brute-force methods. This also permits unauthorized third parties to determine who else was a party to such communications, as well as who said what and when over time.
Without the right key, decryption is impossible. That's good, because encryption of IM communications is at least as important as it is for e-mail messages.
To mitigate this vulnerability, a special form of off-the-record (OTR) messaging was created. In this context, temporary throwaway encryption keys come into play, and are changed frequently during the course of ongoing communications. OTR uses a cryptography library developed by Ian Goldberg and Nikita Borisov that employs AES, SHA1-HMAC, and various RSA encryption algorithms, and that manages key exchange and tracking. Keys are shared via the Diffie-Hellman key exchange protocol.
The third encryption method for Jabber is currently assigned experimental status. It's described in a document entitled XEP-0116: Encrypted Session Negotiation. The encryption technique uses SSH, SSH Transport Layer Protocol, and OTR, and could one day supersede the two aforementioned methods. For now, though, XMPP.org recommends it be used only for experimental purposes, not for production systems.
The encryption methods available to Jabber clients depend on which methods developers have chosen to implement. Users interested in trying the OTR method should dig into the Cyperpunks.ca Plug-ins available for numerous popular Jabber client packages.
