[jdev] GSSAPI and service hostname

[Simon Wilkinson]

On 16 Jan 2009, at 13:02, Tomasz Sterna wrote:

> Dnia 2009-01-15, czw o godzinie 17:21 +0100, Robin Redeker pisze:
>> I've received a bugreport for my Perl module AnyEvent::XMPP recently,
>> that says that I should not pass the domain of the JID as service  
>> hostname
>> to SASL (and later the GSSAPI mechanism).
>
> I think you should.

Not with GSSAPI, and not if you want to be compatible with anyone else.

The GSSAPI SASL mechanism needs to know the service hostname so it can  
talk construct a request for the correct service principal to the KDC.  
It has to know a hostname, because that's the way that Kerberos has  
traditionally worked - a service principal contains the name of the  
host running the service, not of the domain that the service is being  
run for. This has been discussed a number of times on the jdev list,  
and within the Kerberos community, and those of us who have  
implemented XMPP clients and servers supporting GSSAPI have come to  
the consensus that this is the current correct behaviour.

In the longer term, as I noted in a previous post, domain based names  
are the way forwards. This is going to definitely require changes to  
the common SASL APIs, and possibly to the SASL GSSAPI wire  
specification (although 'GSSAPI' which we're all still using has  
already been superceded by GS2)

> It's server job to map the provided domain name to a specific  
> hostname.
> Just like it is server job to map the domain name to a realm, in  
> case of
> DIGEST-MD5.

The server can't do this in a way that's safe - bear in mind that with  
Kerberos, it's the client side that needs to know who it's talking to  
- it's not a case of mapping incoming connections into an  
authentication realm (in the way that DIGEST-MD5 does). Allowing the  
client to ask the server 'who are you today?' immediately opens the  
way for MITM attacks, and defeats the whole point of using GSSAPI in  
the first place.

>> I also wonder which server supports GSSAPI mechanims, so that I can
>> test implementation.
>
> http://jabberd2.xiaoka.com/
> Although its not tested much.

We're using a version of jabberd2 with Cyrus SASL to provide GSSAPI  
support. It works well for us, and is what most of the client GSSAPI  
support (Pidgin, Adium, etc) which I wrote was originally tested  
against, but it's not what's currently being distributed. Openfire has  
a GSSAPI implementation that libpurple's code has been tested against  
that a number of big Kerberos users are using in production. I believe  
there are also patches for Kerberos support in ejabberd, but I'm not  
sure if they've been integrated, and I'm not aware of any  
interoperability testing that has been done.

Cheers,

Simon.