Support Jabber GSSAPI/Kerberos Authentication

[dax@…]

GAIM v2.0 (and 1.5 with a patch) supports GSSAPI/Kerberos authentication. There are two open source Jabber servers that support GSSAPI/Kerberos authentication. We use jabberd2+gaim in our office for some single sign on goodness. I would like to use gajim.

The servers that support it are: Jabberd2cvs & Wildfire 3.01

[asterix]

done in [10437]

[anonymous]

see #4507 for whole story -- morale is that gajim cannot connect to the Openfire server without using password, whereas finch (finch-2.5.2-2.fc10.i386) can.

[mcepl]

<?xml version='1.0'?>
<stream:stream xmlns="jabber:client" to="redhat.com" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xml:lang="cs" >

<?xml version='1.0' encoding='UTF-8'?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="redhat.com" id="3086b781" xml:lang="cs" version="1.0">
<stream:features>
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<mechanism>GSSAPI</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<compression xmlns="http://jabber.org/features/compress">
<method>zlib</method>
</compression>
<auth xmlns="http://jabber.org/features/iq-auth"/>
</stream:features>

<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="GSSAPI" />

<failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<not-authorized/>
</failure>

[mcepl]

gajim -v -l gajim=DEBUG > gajim-log.txt 2>&1

[mcepl]

log from running finch against the same account

[mcepl]

from #pidgin on Freenode:

[00:22:38] etan2: Well, so the problem is quite clearly that gajim isn't sending the initial GSSAPI data. The question is why not. I don't know enough about GSSAPI, kerberos, or gajim to say. But if you take the gajim log and the GSSAPI snippet of the finch log and ask the gajim people they might be able to figure it out.

[mcepl]

I think that the finch logs gets interesting somewhere around line 76.

[asterix]

what is the name of your key? it must be xmpp@server

[mcepl]

you mean my principal? mcepl@…

[asterix]

it's why Gajim don't find this key. Gajim look for a key named xmpp@server_name. So probably xmpp@… in your case.

So maybe a GUI to ask the user which key to use is needed. I see 2 options:

In account settings window, under the password, a new entry "GSSAPI key name". But most users won't understand what that it.

On first connection, a GUI pops up listing the keys and asking which one to use. This key name will then me saved and shown under password in account settings window.

What do you think about that?

[mcepl]

This must be wrong:

a) finch never asked me for this, b) why cannot gajim run some kind of equivalent of klist and find out the name of the default principal by itself?

[mcepl]

and of course domain of JID doesn't have to be server name (and in this case isn't).

[asterix]

hmmm what I read from GSSAPI is that this principal is the service name. So calling it xmpp@server sounds the right way to do.

Another thing is that python-kerberos don't ofer a way to list principals, so we cannot do what I told you before (listing keys) but we could show a text entry to type it. Finch is written in C, not in python. The C library must be more complete.

But according to my first point, I think a warning dialog saying "There is no principal called xmpp@server" sounds enough to me. It's obvious enough that you have to rename yours.

[asterix]

I see something that could be usefull, could you try that:

$ python
>>> import kerberos
>>> kerberos.getServerPrincipalDetails('xmpp', 'redhat.com')

What does that return?

[mcepl]

According to test.py in my python-kerberos package I think better service is xmpp@… and server should be real FQDN (from _xmpp-client._tcp.redhat.com DNS SRV record) which is chat.corp.redhat.com. So I tried

kerberos.getServerPrincipalDetails("xmpp@…","chat.corp.redhat.com")

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

kerberos.KrbError?: ('Cannot get sequence cursor from keytab', 2)

Just for the sake completness I tried even what you asked me for:

kerberos.getServerPrincipalDetails('xmpp', 'redhat.com')

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

kerberos.KrbError?: ('Cannot get sequence cursor from keytab', 2)

[asterix]

ok getServerPrincipalDetails doesn't work. But if you rename your key to xmpp@…, GSSAPI should work in Gajim, could you confirm?

[mcepl]

ehm, "rename your key" --- how would I do it?

[anonymous]

The service principal is installed into the keytab file on the Jabber server. You don't have access it to (and you don't need it).

As the client all you need to know is the name of the service principal so you can request a service ticket for that service from the KDC.

For Jabber/XMPP it should be xmpp/FQDN@REALM (eg: xmpp/mail.gurulabs.com@…).

[asterix]

You're right. Author did it for jabberd2, maybe it's not the same name there?

mcepl tested with xmpp/chat.corp.redhat.com@…, but without success.

I mailed the guy who implemented this in Gajim, I'll see his answer ...

[mcepl]

Just to note, there is currently openfire @ redhat.com

[anonymous]

Attaching working patch (created by Simo Sorce, ssorce at redhat dot com) which works against openfire with GSSAPI authentication. The only problem (which is rather cosmetic one) is that apparently gajim is not content when I mark empty password as the one which it needs to remember, and asks me for it every time I try to connect.

[mcepl]

patch to make gajim authorise using GSSAPI

[asterix]

(In [10711]) [Simo Sorce] fix GSSAPI to use FQDN. See #2465

[asterix]

Now I'll look how to not ask password when GSSAPI is used.

thanks for the patch

[mcepl]

and some error recovery (and error message) when ticket is not present, but that shouldn't be a blocker IMHO. Neither that non-asking of password should be.

[mcepl]

yes, and one more thing -- you should explicitly say that you require pyKerberos >= 1.1

[anonymous]

thqt reauire indeed a lot of chqnges in xmpp lib itself, because it requires the password before it knows which mechanism is used. I'll chnage that after bosh branch has been merged.