[Wocky] jabberd GSSAPI authentication support status

[Greg Hudson]

I spent a couple of days this week looking at how we might integrate
GSSAPI support into jabberd, given that it's not in 2.0s10 as I
previously thought.

The short summary is that wocky.mit.edu is currently running a jabberd
2.1 snapshot with our krb5 authreg module added back in.  I had to fix
a few bugs and adjust some configurations, but it currently offers
GSSAPI as an authentication mechanism, and password authentication
over SSL still works.  The current setup should be adequate for
client code testing, but needs a lot of cleanup.

The longer play-by-play:

I found that jabberd's CVS repository didn't seem to have a commits
mailing list, making it hard to figure out what commits might have
been made related to Cyrus SASL support.  I also found that jabberd
might be relatively close to a 2.1 release, in that they're releasing
2.1 snapshots.  So I decided for now to give up on a backport of the
SASL support to 2.0, and to just start testing the latest 2.1
snapshot.

The 2.1 code requires a fairly recent version of Cyrus SASL, more
recent than the Athena build in /usr/athena/lib on wocky (network
appears to using a layered Athena install on that machine).  I did a
local build of a more recent version of Cyrus SASL and ran into a host
of library and linker path issues with that build.  They were all
solvable with enough effort, but I wonder if trying to build jabberd
without /usr/athena in the include and library paths (which would
imply using the native Kerberos build) would be better.  I'll look
into that later.

While peering at the code responsible for requiring a recent version
of Cyrus SASL, I noticed an apparent bug and fired off an email
message to Simon Wilkinson asking for clarification.  I haven't gotten
an answer back, which is a little worrisome.

The jabberd 2.1 code added some certificate verification support which
was aimed at making c2s and s2s verify client certs presented by
connecting hosts (see
http://j2.openaether.org/bugzilla/show_bug.cgi?id=56).  However, on
our server it had the undesired side effect of making most of the
jabberd components fail to connect to the router component because
they couldn't verify the server cert provided by router (because it
ends in a self-signed MIT cert).  Since I'm not sure why it's
desirable to be using SSL between jabberd components, I disabled the
pemfile setting in the router.xml config file, thus disabling SSL
connections between components and working around the problem.  I also
submitted a comment to bug 56 about this side-effect, but haven't
received a response.

With that problem fixed, the server starts up (and can be convinced to
offer the GSSAPI mechanism by adding a config line to c2s.xml), but
wouldn't accept password authentication over gaim any more.  After a
great deal of tracing, I discovered that some of the password-checking
callbacks in the new SASL code weren't being passed to the SASL
library and thus weren't taking effect; the upshot is that authreg
modules don't work if they can't supply the desired password in plain
text.  I fixed that, along with another shallow bug revealed by that,
and now password authentication works again.  I sent more mail to
Simon Wilkinson about my findings.  If I continue to get no response,
I can air this and the SSL certificate issue on the jabberd dev list.

There don't appear to be massive code changes between 2.0 and 2.1
aside from the new SASL support.  That means a backport of the SASL
support is probably not a big deal, but it also means we might be
better off just going with 2.1 since it's still a pretty familiar
beast.