Subject: [Wocky] Adium and GSSAPI

From: Ken Raeburn <[email-masked]>
Date: Fri, 28 Dec 2007 00:03:44 -0500

It looks like Adium 1.2 is likely to support GSSAPI authentication to  
the Jabber server.  The current beta (1.2b5) has some of the code,  
but because of how some workarounds for OS bugs were handled, it will  
prefer password-based authentication when running on Tiger.  (Also,  
1.2b5 breaks authenticated Zephyr support.)

Patches have gone in that should fix the problem on Tiger, and clean  
up some UI issues; I'll try out the next beta when it comes along,  
and try to make sure it's working.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 31 Dec 2007 05:56:13 -0500

On Dec 28, 2007, at 00:03, I wrote:
> It looks like Adium 1.2 is likely to support GSSAPI authentication  
> to the Jabber server.  [...]

Now 1.2b7 is out, and it has some of the problems fixed.  However, I  
can't authenticate to the mit.edu jabber server at all now!  It's  
trying to get credentials to xmpp/web.mit.edu, presumably because  
it's mapping mit.edu to 18.7.22.69 to web.mit.edu somewhere, possibly  
in the Kerberos support (a known and long-standing issue), possibly  
elsewhere.  That service doesn't exist in our database, so the  
authentication attempt fails.

I'm also not 100% sure whether xmpp/mit.edu (based on the user- 
supplied account name) or xmpp/jabber.mit.edu (based on the name of  
the server actually in use, which is looked up insecurely in DNS SRV  
records) is the correct name to use.  It looks like Athena's gaim  
uses the latter; is that what the spec says?  I vaguely recall some  
discussion on this point long ago, but I don't remember the details  
and haven't managed to track down any info online so far.

To make matters worse, if GSSAPI authentication fails, Adium 1.2b7  
delays and tries again; it doesn't fall back to password-based  
authentication.

Ken

---

From: Greg Hudson <[email-masked]>
Date: Mon, 31 Dec 2007 11:01:45 -0500

On Mon, 2007-12-31 at 05:56 -0500, Ken Raeburn wrote:
> uses the latter; is that what the spec says?

Believe yes.  That's certainly what jabber.mit.edu has a keytab for, and
Spark does it that way as well as Pidgin.  In fact, I'm a little puzzled
that Adium differs from Pidgin on this front, since they both use
libpurple.  Could be a version skew issue, since I know Pidgin had this
bug for a littlw while; I will try to find time to peer into their svn
repository and see.

If you're not in a position to build Adium from source, you will
probably run into another bug, this time in Openfire, until our server
is upgraded to 3.4.2.  This bug is that if the client doesn't specify an
"authz name", the server will reject with an authorization failure.  The
server upgrade is expected to happen soon.

You can test against wocky.mit.edu; it won't have the domain name
mismatch issue (since the XMPP domain matches the hostname for our test
server) and it's running 3.4.2 so it won't have the authz name bug.

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 31 Dec 2007 22:35:10 -0500

> server) and it's running 3.4.2 so it won't have the authz name bug.

This seems to work fine.  (And from the debug log window, it looks  
like the server has my full contact list copied from jabber.mit.edu,  
though [email-masked] isn't allowed to actually see anyone.)   
So I guess it's a matter of fixing the server name determination, and  
the 3.4.2 issue.  (And then there's fixing the Zephyr issues.)

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Sun, 6 Jan 2008 06:00:08 -0500

Okay, it looks like 1.2 has been released, and I didn't have time to  
get some fixes made and submitted.  So, here are my observations:

* By default, strict certificate checking is on for Jabber servers.   
It'll complain about mit.edu because it has a self-signed cert.   
There is an account option to disable the strict checking, but of  
course better would be to get server certificates signed by the MIT  
CA and get the MIT CA into people's trusted servers.

* If a "connect server" of jabber.mit.edu is specified for an mit.edu  
Jabber account, then GSSAPI authentication will fail.  Unfortunately,  
in this case, it doesn't fall back to password authentication.  So  
you need to remove the connect server, if you have one listed.  (Note  
that IS&T's current recommended settings for Adium include the  
connect server.)

* There's a bug in the old version of the OpenFire server running on  
jabber.mit.edu -- Greg knows the details -- which causes session  
establishment to fail even though GSSAPI authentication succeeded.   
Then, Adium falls back to password authentication, but for some  
reason it doesn't seem to be working for me.  I'm not sure if this is  
related to the OpenFire issue or something new.

* The Zephyr support has been compiled without Kerberos support, and  
is therefore useless; it cannot talk to the MIT servers.

So, my recommendation (unofficial, not endorsed by IS&T, caveat  
emptor, your mileage may vary, no lifeguard on duty, etc, etc) is:  
Don't even bother right now.

Ken