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. _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
