Shifting to Jabberd2.1.1

I'm in the process of migrating our development Jabber service from an FC3 platform, where it's running a heavily patched version of jabberd2.0, to the newly revitalised jabberd2.1. 2.1 already has our local Cyrus SASL patches included, so we can drop those from the patch set, along with a large number of other improvements. In addition, I'm taking the opportunity to improve our support for non-local clients.

In the earlier incarnation, our service would only accept GSSAPI connections - it didn't support any form of password based authentication. It was repeatedly pointed out to me that this was a pain! Clients such as iChat just wouldn't work, Adium, Gaim and Psi all had to be used in a locally patched form, and it was not particularly usable. So, I've suspended my concerns about people caching their Kerberos passwords in their chat clients, and added support for doing password based authentication. This has required some reconfiguration (we now use pam for auth checking, rather than LDAP), and some code changes to jabberd2.1

The PAM authreg module that ships with jabberd2.1 has some strange ideas about what a username looks like - it uses the full JID of the user when calling into the PAM stack (so you get usernames of the form user@example.com). This doesn't work well with a conventional PAM stack, so I've patched the code to disable this behaviour.

I also wanted to be able to restrict password authentication to SSL connections, whilst still providing GSSAPI on insecure connections. Previously, jabberd2.1 didn't support having two different sets of supported SASL mechanisms, so I coded up a quick patch to implement this. It's worth noting that clients such as iChat, which use pre-standardisation authentication mechanisms submit their password despite the server telling them not to. This means that the password will be exposed, regardless of the server setting. Ho hum.

Next step is creating a migration script for the user rosters (as we're moving from machine.example.org => example.org for JIDs)

Gaim, Kerberos and Cyrus SASL

Some time ago, I added Cyrus SASL support to Gaim, so that it could do Kerberos authentication to Jabber servers. As we've developed our Jabber service locally some issues with this support has emerged.

Firstly, there's been a bug introduced which causes connections to hang if a security layer is negotiated. The fix for this is in the Gaim patch tracker.

Secondly, the code uses the user's domain name as the server name when establishing a SASL connection. This doesn't affect the 'normal' DIGEST-MD5 and PLAIN mechanisms, and also has no effect in situations where the hostname matches the domain of the user. It does, however, cause GSSAPI connections to fail when contact a server whose hostname is different from the user's domain (for example, servers that are located through SRV, rather than A records). Again, there's a fix for this in the Gaim patch tracker.

The final change is a functionality change. When I originally wrote my patch, I changed the Jabber protocol definition to indicate that passwords were optional. Whilst this stopped Gaim from prompting for a password whilst doing GSSAPI authentication, it broke any other mechanism that actually required passwords. That bit of the change was quickly reverted! However, it is useful to not have to enter a password when authenticating using a mechanism that doesn't require it.

It turns out that if you don't register a password calllback with Cyrus SASL, it will not attempt any mechanisms that require passwords. Using this, it's possible to prompt for passwords as required, rather than mandate them for a connection. This allows both GSSAPI usage without a password, with fallback to password prompting for other mechanisms. I've just uploaded the patch for this to the Gaim tracker.

GSSAPI support in Thunderbird

The GSSAPI support in Thunderbird has never returned particularly great error messages. In particular, if the server offers GSSAPI, and nothing else, you'll get told that the server doesn't support secure authentication when login fails.

For some reason, this error message seems to annoy people ...

We can't give 'real' error messages whenever GSSAPI fails, because we try GSSAPI whenever the server offers it, and there are lots of broken Linux installations out there which offer GSSAPI whenever the appropriate libraries are installed, regardless of whether the server has suitable key material or not.

So, it looks like Thunderbird needs to have some UI to say whether GSSAPI is supported or not. Of course, Jeff Altman said as much back in 2005...