Secure Distributed JID Discovery

DISCLAIMER: This work is subject to change and experimental.

=Problem Description= Discovering JIDs of one’s contacts via existing address books without disclosing contact details in clear-text form. Address books, on phones or desktops, usually contain names linked to phone numbers, EMail, BBN and so on. Based on this information we want to develop a protocol that allows the discovery of a JID that belongs to those details. Ideally in a distributed, secure and private manner.

JIDs are discovered by their hash keys. It could be more than one. For example: phone numbers, emails, aliases, etc... The hash keys are stored in a distributed manner and they are linked to the server that contains the jid related to those keys.

Concept Requirements

 * Allow JIDs to be discovered in a secure and private manner
 * Distributed (no central directory like JUDs)
 * Contact information should not be transmitted in clear text (to non-trusted entities)

Possible Ways of Verification

 * Email (low cost)
 * SMS (medium cost)
 * Phone call (high cost)

Alternative To Plain Verification
A reputation based system could be used instead or in addition to plain old verification. In this concept the address books of your contacts usually all claim that the same phone number belongs to your name, including your email, etc. depending on the completeness of the address book entries.

=Proposed Solution=

DHT Based Solution
XMPP components located at server-side build a DHT-overlay in the federated XMPP network. Communication between the nodes of this overlay happens via standard XMPP server-to-server protocol. The DHT builds the first entry point into the lookup/storage process.

Structure of the DHT
The DHT needs to provide the following set of functions:
 * Lookup by a set of attributes. Returns a set of domains which hold the actual JID matching the queried set of attributes.
 * Insert of new entries, mapping from a set of attributes to a domain, in the directory.
 * Automatic expiration of hash-table entries to prevent storage of old/wrong information about users.
 * Entries can only be removed by the component that added it to the hash table or by automatic expiration. No duplicate entries (duplicate keys) allowed.

Adding of Entries to the Database

 * 1) A XMPP client has a set of attributes it wants to related to an specific jid. For example {phonenumber=123456789, email=user@example.com} -> user_jid@jabber.org
 * 2) It is required that the user doing this operation MUST be logged into the account e.g. user_jid@jabber.org
 * 3) The JID owner sends the request to its server, in our example: jabber.org
 * 4) The server adds the new entry to the DHT database
 * 5) It is required that when adding a new entry to the DHT database the JID MUST not be shared. So the new entry would look like this: {phonenumber=123456789, email=user@example.com} -> jabber.org
 * 6) An entry MUST always point to the server that owns the JID. If a server answer with a JID that doesn’t belong to that server, the client MUST ignore that response.

Lookup of JID from the Database

 * 1) The XMPP client has a set of attributes it wants to lookup. For example {phonenumber=123456789, email=user@example.com}.
 * 2) The XMPP client sends its query request to a lookup service.
 * 3) Lookup service queries the DHT for the attributes resulting on possible matches
 * 4) The lookup service sends a list of possible matches back to the client.

Deleting a JID from the Database

 * 1) A JID that belongs to a server can be removed from the database by the server at any time
 * 2) A client that wish to be removed from the directory can do so by requesting its server
 * 3) In order to maintain the database, entries have expiration dates and must be renewed by their server before the date is reached

=Open Problems=
 * 1) How to prevent impersonating other users. (A user using barackobama@gov.us without owning that address)
 * 2) Verification (expensive?)
 * 3) Discovery node could lie about verifying information.
 * 4) A way to fix this is to have more  than one node involved in the verification process.
 * 5) How handle editing of database entries? Edit/remove only be the entity that added it to the database.
 * 6) Only the entity that added it should be able to modify it. Edit and modification shouldn’t be a problem unless someone is impersonating the entity and we have certificates to prevent that. - How to achieve that?
 * 7) Database not completely distributed in the current idea: Hosting Node lookup distributed, actual data retrieval only federated. Is that an issue?