Adding SASL support into XMPP/Jabber

I've been looking for a while at building a secure IM system which would intergrate with our Kerberos infrastructure. Whilst XMPP (RFC 3920) requires implementations support SASL, most clients and servers only support the mandatory-to-implement mechanisms PLAIN and DIGEST-MD5, without including useful mechanisms such as GSSAPI.

So, I've gone on a bit of a rampage, and added Cyrus SASL (which in turn gives us GSSAPI, in turning giving us Kebreros support) to a server and a number of clients. I'm going to try and get these patches rolled back, and we'll see what happens.

This page is mainly to serve as notes for myself. If you've stumbled across it on the Internet, and are interested in any of these patches, please mail me at simon (at) sxw.org.uk

Servers

I've only bothered looking at one server ...

jabberd2

Jabberd2 used to have Cyrus SASL support until it was removed in 2003, due to it being too hard to configure, and requiring that users were stored in external databases.

I've reimplemented the Cyrus support, integrating the old 2003 code with the newer callback mechanisms. This allows the use of jabberd2's internal databases to configure username and passwords, and means that Cyrus SASL should be no more complicated to set up than the old 'scod' SASL mechanism.

One caveat remains. Few jabber clients have good mechanisms for handling SASL negotiation or failure. Most assume that authentication failure is due to an incorrect password being supplied, and so do not try alternate mechanisms.

For this reason, its important that the server doesn't offer SASL mechanisms it has no means of supporting. Mechanisms such as 'GSSAPI' should only be enabled if they are intended to work. Enabling 'GSSAPI' (or the Kerberos v4 mechanism) on machines which aren't configured for Kerberos, or which don't have a valid service key, will cause all clients supporting that mechanism to fail when connecting to the server.

The jabberd2 patch still needs support for better configuring the list of available mechanisms.

Clients

I've looked at a number of clients. Some of these are good, some bad, some ugly.

Cocinella

Cocinella supports Cyrus SASL with a number of minor alterations to the source code. It requires the 'tclsasl' package to be included on the machine in question.

Note that Cocinella suffers from the SASL negotiation problem mentioned above. If you're using a patched Cocinella against a server which is GSSAPI capabale, and you don't have valid Kerberos keys, all attempts at SASL authentication will fail. This requires further work.

Cocinella negotiates no security layers.

Gaim

I've got a set of patches for Gaim which implement comprehensive Cyrus SASL support. They handle the renegotiation problem, so will continue with authentication even if a mechanism fails, and deal properly with security layers.

Jarl

Jarl can support Cyrus SASL with a working Authen::SASL::Cyrus module (we had to make a number of fixes to ours). However, it doesn't appear to support security layers, and fails shortly after negotiation.

Tkabber

Aside from what appears to be a small bug in the SASL code, this works with Cyrus "out of the box". It doesn't negotiate security layers.

-- SimonWilkinson - 01 Jul 2005

Topic revision: r3 - 06 Apr 2014 - 15:28:55 - IanDurkacz
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies