Feel free to send any comments by Jabber or email to da@weeno.xxx (.xxx = .net, no spam thanks).
Table of contents
1. Initial problem
We have two entities, A and B, communicating over a given channel. We want to provide a mechanism allowing A to prove its identity to B. For example, the channel is a client/server HTTP communication: the user is surfing on a website, and wants to log into the member area.
A common approach is to let the user have an account on that website (through a registration process for example), and the server asks a username and a password on each visit.
This pre-shared password approach has several problems. One of them, becoming more crucial over time, is that people have to create more and more accounts, which is annoying, and remember more and more passwords, which is annoying too. Of course, they are free to always use the same username and/or password, but it's still very hackish. Though this issue is most prevalent on websites, it remains true with other channels that involve user accounts, for example mail hosts.
2. What do we want anyway?
In fact, we want to get rid of that multiple account spread. An average user has an account on many servers (particularly web forums), say between 2 and 50. Moreover, what happens when a user forgets their password? No problem: they simply say so, and they receive a new one by email.
This raises two interesting ideas:
- Why is it necessary to remember my password at all, if I can receive a new one each time I need it?
- If I pretend to be someone else, I can easily have their password reset, which is quite annoying to them. Sometimes, they receive a confirmation email instead of an immediate password reset, but at least I can have them spammed with confirmation emails, which is quite annoying to them too.
From the first idea, we see that remembering a password is clearly something that could be easily avoided: the user can ask for a new ad-hoc password each time they need to prove their identity (provided the process is convenient and fast enough). As soon as the password has been used, or has expired, the user can forget it, and the password can be disabled.
What about the second idea? If you intend to request an ad-hoc password, you have to do it over a channel on which the sender address cannot be spoofed. Obviously, the SMTP protocol is not a good candidate in this matter. Instead, there exists a communication protocol that takes this aspect into consideration: XMPP. The good news about XMPP, moreover, is that it is user-oriented, fast, and extensible enough to design the mechanism we need.
3. Scenario / Mechanism
We have an entity (which we call the 'Client'), communicating with another entity (the 'Server') over a given 'Channel'. The Client wants to prove their XMPP identity to the Server. For example, the Channel is an HTTP communication, the Server is a website, and the Client is a user who wants to log in the member area of the website. Additionaly, running somewhere on the internet, there is an XMPP-enabled 'Agent' associated to the Server and trusted by it.
The following 3-step process allows the Client to prove their XMPP identity to the Server:
In step 1, the Agent sends the ticket to the JID associated to it. Thus, having the ticket is a proof that you're the owner of the JID.
Notes
The first thing to note is that before anything, the Client must have a way to know the JID of the Server's Agent. The server can advertise the JID of its Agent in a more or less formal way: using a FAQ, a directory, a hint during the communication (welcome message, protocol-specific header, etc.), or anything else. For flexibility and modularity reasons, describing how exactly this is supposed to happen has been left outside the scope of this paper. However, this page advises some ways to advertise the DIAS Agent within some widespread protocols.
For the same reasons, describing how the Server is supposed to get information from the Agent about a particular ticket is not discussed herein, since the most convenient way depends on the protocol in use and on how the Server is able to communicate with its Agent: same filesystem, over the internet, etc.. Nevertheless, this document gives ideas of how it can be done.
It is interesting to note that the Server does not necessarily know the Client already, i.e. there is no need to fill any database with user information through a registration process. In fact, the XMPP network can be seen as a big decentralized user database, with a unique naming scheme. In this database, the Client already has an account. Of course, the Server may still associate extra information to the Client's JID in its own database, but this is not necessary.
Last, but not least: even though the Server identifies the Client on a JID basis, this does not mean that it will use this piece of information for anything else, nor disclose it anywhere. In fact, it can even let the Client choose a username the first time (or each time) they show up, and display only that username to the "outside world". For instance, this is already how things are done on Jabber MUCs: you choose a nick when you enter a chatroom, and then people on the room don't see anything but that nick, even though the chat server knows you by your JID.
4. Use cases
Depending on people's needs, this mechanism covers different use cases.
4.1. Transient identification
Sometimes, you don't want to store any particular user-related information, but you still want to distinguish users between each other, for example in a polling system, on blog comments (optional identification), etc..
4.2. Authentication
If there is already an existing user database, and every user has a known JID, the current login/password authentication process can be replaced with DIAS without changing anything else in the existing user management system. The only thing to do is to ask a ticket number instead of a login + password.
Alternatively, the login/password mechanism can be left available, allowing the users to use whichever system they find the more convenient. Moreover, this approach suppresses the need to know every user's JID.
4.3. Address verification
DIAS provides a generic address-proving mechanism that is not limited to traditional authentication: it can be used, for example, as a simple and efficient way to verify one's JID upon editing contact information, by asking the ticket as a confirmation. Note that asking the JID isn't even necessary at all, the ticket is sufficient.
5. Security considerations
5.1. Phishing
One easy attack from an evil Server is to advertise the agent's JID of another (target) Server. This way, the Client asks a ticket to the target's Agent without realizing it, gets the ticket and shows it to the evil Server. At that point, the people running the evil Server have managed to 'steal' the ticket and can use it on the target Server.
To avoid this, the Client must check very carefully the relation between the initial Server and the agent that it advertises. For example, in order to protect itself, every Agent should have a VCard with detailed, non-ambiguous information, so that Clients can fetch the information from the VCard and perform the ticket request only if the information is OK.
Additionally, the ticket request may indicate the "referer", i.e. the URL of the Server. This allows agent-side detection of phishing attempts, but only works for Servers identifiable through an URL (those using a protocol such as HTTP, FTP, IMAP, etc.).
Last, the agent may give the Client, along with the ticket, an URL that can be accessed directly, thus preventing the client to give the ticket to the wrong Server. Here again, it only works with URL-aware communication protocols.
5.2. Anonymity
Though we're describing the fact of using several distinct accounts as a problem in the beginning of this document, it can be seen as a strength of the Internet: keeping people anonymous by using a separate identifier each time.
Still:
- Many people already do use the same identifier everywhere.
- People concerned with anonymity matters can use several JIDs, exactly the same way as they already use several usernames and/or email addresses.
5.3. Password leak
Allowing people to send a request using their JID is nice, but it raises one problem: what if someone steals your password for that JID? They will then be able to authenticate against every DIAS-compliant system on your behalf.
In fact, while this is a true concern, the problem is not new:
- Many people already do use the same password and/or email address (in case they forget their password) everywhere.
- People who are concerned with security matters can use several JIDs, exactly the same way as they already use different passwords and/or email addresses.
The solution is, as always, to change your password regularly. The point is that it is much more feasible here than when you have to visit each and every place where you remember having an account.
5.4. Communication confidentiality and integrity
There are two communication channels involved in DIAS: the initial Channel and the XMPP network. Thus, the confidentiality and integrity issues are those of these two channels. Though discussing each and every protocol's security is far beyond the scope of this document, we will simply recall some ways of securing an XMPP communication:
- Optional use of SSL for client-to-server and server-to-server communication
- Optional use of signing/ciphering for end-to-end communication, using the methods already available in Jabber: XML signature, GPG keys, etc.
Please refer to the correponding section of the RFC 3920 (XMPP Core) for more details on XMPP security.