XMPP x.509 client cert managament

[Arc Riley <arcriley gmail com>]

Hey Stef, all

I've been talking to Adam tonight about adding support for publishing/managing client auth certs to an XMPP server.  Here's a background for why and how;

Currently most XMPP client authenticates with a username/password via SASL over a TLS-encrypted stream.  This is secure, but often the client stores the password cleartext on their hard drive for autologin.  This is a real problem in that for many users their XMPP server is gmail.com, meaning someone getting their password also gets access to their email.

SASL EXTERNAL provides support for allowing password-less login when the x.509 client cert used to establish TLS is known to the server to belong to the given user.  What has until recently been undefined is how the server establishes this.  XEP-0257 describes an method to publish and manage client x.509 certs such that a password is only needed to cert management, and the IM client thus never needs access to the password.  If, ie, your mobile phone is stolen, you can log in from home using your password and remove the cert your mobile phone uses from your account using your password.

There may also be a number of XMPP clients installed and in-use by a single user at one time, since XMPP is being used for much more than basic IM.  We're integrating it into our game engine, for example, to share buddy list and chat between games and out of game, and I'm very concerned about the temptation of stealing online identities through game "patch" code.

To make this easy to use, I proposed integrating this into gkr and providing x.509 certs only to clients authorized for that specific cert, thus allowing (but not requiring) every XMPP client to have their own unique cert while giving the user a single place on their desktop to manage all their keys.  I discussed this earlier tonight with some Gnome developers who sent me to talk to Adam.

Seahorse already handles x.509 cert management and gkr.  The interaction with clients is already taken care of.  The part I'm proposing to add is in interfacing with the XMPP server to publish and manage the certificates.  To do this in a short amount of code I'm going to need to add an XMPP client library as a "soft dependency".

Adam suggested using the same library as Telepathy, to keep Gnome's dependency list small.  Telepathy currently uses loudmouth and are migrating away from it for the same reason we're moving away from it for our game engine.  There are many crappy XMPP client libraries in the community.  The original author of Icecast and an xmpp.org board member, Jack Moffitt, recently wrote a small (78k compiled, 7k lines of code) library called libstrophe to replace loudmouth.  I have a high degree of faith in Jack and will also note that seahorse's use of XMPP will be limited to logging in and publishing certs, getting a list of currently added certs, and removing them from the server.

Telepathy is in the early stages of writing their internal replacement, they can't use libstrophe because it's licensed GPL and Telepathy is LGPL.  At ~78k, I think we're bikeshedding the issue, especially as a better alternative isn't currently available.  There'll only be around 100 lines of code added to seahorse which interface with the XMPP library so replacing it in the future should not be difficult.  libstrophe by default compiles as a static library and appears to be intended to distribute bundled with packages that depend on it.  I've started packaging it for different distros as a share library so our game engine can use it as such.  It could just as ready be bundled with seahorse as a static library or just include the source files from it into the XMPP code to be added to seahorse.

The other questions that are raised are what the UI for managing keys on the server.  Adam suggested reusing the keyserver results window with a context menu providing a "remove" option.  I don't know enough about how this would look to suggest an alternative, I'd just like the window not to be titled or otherwise present the listed keys as search results.

This extension is an experimental draft, so in adding this functionality I'll be taking responsibility to update the code to reflect any changes in the protocol until the XEP is accepted (which may be years from now, many XEPs are supported in software before they're standardized).

http://xmpp.org/extensions/xep-0257.html