XMPP & Kerberos 5
Oliver Schmidt
I'm currently trying to setup an XMPP server with Kerberos 5
authentication. I've been using eJabberd 2.0.5 with username/password
authentication for a while. Now, I would like to use Kerberos in order to
make my services more comfortable with SSO.
Unfortunately, I failed using an GSSAPI patch for eJabberd together with
my Kerberos system. After that, I tried using Openfire, which didn't work
out for me either. Now, that I've read about that institution-wide XMPP
service the MIT offers, I know that XMPP _must_ work with Kerberos
somehow. Can you tell me how you set it up and, respectively, which
software you did use?
Thank you in advance!
Yours
O. Schmidt
Greg Hudson
> Unfortunately, I failed using an GSSAPI patch for eJabberd together with
> my Kerberos system. After that, I tried using Openfire, which didn't work
> out for me either. Now, that I've read about that institution-wide XMPP
> service the MIT offers, I know that XMPP _must_ work with Kerberos
> somehow. Can you tell me how you set it up and, respectively, which
> software you did use?
MIT uses Openfire. I did the initial setup. You might take a look at:
The most complicated part comes if you want to allow people to log in
with passwords over TLS (since many XMPP clients do not have GSSAPI
support) and check those passwords against the KDC. Openfire does not
have native support for that, but it can be done via an authentication
plugin. I wrote a module to do so using Sun's JAAS; the code is
referenced in the URL above, but here's a direct link (which also has
our configuration files):
http://web.mit.edu/afs/dev.mit.edu/project/jabber/src/mitopenfire/
Please be aware that the password-checking code is not entirely secure.
A proper krb5 authentication module uses a service key (such as a host
key) to verify the returned TGT, in order to prevent an attacker from
spoofing the KDC. Unfortunately, the JAAS Krb5LoginModule does not
contain this functionality.
Dax Kelson
> On Mon, 2009-11-30 at 04:25 -0500, Oliver Schmidt wrote:
> > Unfortunately, I failed using an GSSAPI patch for eJabberd together with
> > my Kerberos system. After that, I tried using Openfire, which didn't work
> > out for me either. Now, that I've read about that institution-wide XMPP
> > service the MIT offers, I know that XMPP _must_ work with Kerberos
> > somehow. Can you tell me how you set it up and, respectively, which
> > software you did use?
>
> MIT uses Openfire. I did the initial setup. You might take a look at:
>
> http://itlab.stanford.edu/blog/archives/2009/test-services/openfire-and-kerberos-implementation-notes
>
> The most complicated part comes if you want to allow people to log in
> with passwords over TLS (since many XMPP clients do not have GSSAPI
> support) and check those passwords against the KDC. Openfire does not
Don't most people use Kerberos in conjunction with LDAP? Also isn't it
typical to have LDAP server doing passthrough authentication (for simple
bind operations) to the KDC?
The way our Openfire is configured (a native configuration possibility)
is to allow passwords over TLS which is authenticating via LDAP server
(which uses the KDC for auth).
This way our Openfire server does native GSSAPI/Kerberos with clients
that support it, and passwords over TLS for those clients that do not.
In either case, the password is the same.
Dax Kelson
Guru Labs
Russ Allbery
> Don't most people use Kerberos in conjunction with LDAP? Also isn't it
> typical to have LDAP server doing passthrough authentication (for simple
> bind operations) to the KDC?
I certainly hope not. I suspect that it's far more common than I'd like,
but it's a violation of the Kerberos security model and exposes the user's
password to rather more systems than should need to see it.
We require GSSAPI binds for all authenticated access to our LDAP servers
and don't allow simple binds at all except for anonymous binds.
The correct way of using Kerberos is for the user's credentials to never
leave the local system. In practice, it's an ideal that usually can't be
reached, but every place where the Kerberos password leaves the local
system and is validated on a remote system is a place that's going to
break when you want to switch to something better than passwords, such as
smart-card authentication.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Garrett Wollman
Russ Allbery <r...@stanford.edu> wrote:
>The correct way of using Kerberos is for the user's credentials to never
>leave the local system. In practice, it's an ideal that usually can't be
>reached, but every place where the Kerberos password leaves the local
>system and is validated on a remote system is a place that's going to
>break when you want to switch to something better than passwords, such as
>smart-card authentication.
On our systems, we require users to have two distinct passwords: their
Kerberos password, which is only used for login-equivalent
authentication and certificate generation, and their "email" password,
which is used by the IMAP server (Cyrus), the outgoing mail relay
(Exim), and the XMPP server (eJabberd). Doing this for IMAP was
necessary in order to support webmail, and having done so, it made
sense to piggyback other applications requiring non-login password
authentication on the IMAP passwords. I don't know how many users
have ended up changing their two passwords to be the same (we
discourage that but we don't have a mechanism to prevent it), but we
ensure that they at least start out different.
Since no commonly-used XMPP clients support GSSAPI authentication, we
have not looked seriously at supporting it on the server side. We do
support it for email.
-GAWollman
(in this case writing from, but not for, MIT CSAIL)
--
Garrett A. Wollman | What intellectual phenomenon can be older, or more oft
wol...@bimajority.org| repeated, than the story of a large research program
Opinions not shared by| that impaled itself upon a false central assumption
my employers. | accepted by all practitioners? - S.J. Gould, 1993
Russ Allbery
> Since no commonly-used XMPP clients support GSSAPI authentication, we
> have not looked seriously at supporting it on the server side. We do
> support it for email.
This isn't our experience, for what it's worth. We require GSSAPI
authentication to talk to our IM servers and don't support password
authentication at all, and this works with enough clients that we have no
trouble (iChat, Adium, Pidgin on Linux or Windows, Finch). We don't
officially support iChat because its implementation of the XMPP protocol
is very buggy, particularly around handling of SRV records, but the GSSAPI
authentication basically works.
Shumon Huque
> MIT uses Openfire. I did the initial setup. You might take a look at:
>
> http://itlab.stanford.edu/blog/archives/2009/test-services/openfire-and-kerberos-implementation-notes
>
> The most complicated part comes if you want to allow people to log in
> with passwords over TLS (since many XMPP clients do not have GSSAPI
> support) and check those passwords against the KDC. Openfire does not
> plugin. I wrote a module to do so using Sun's JAAS; the code is
> referenced in the URL above, but here's a direct link (which also has
> our configuration files):
>
> http://web.mit.edu/afs/dev.mit.edu/project/jabber/src/mitopenfire/
>
> Please be aware that the password-checking code is not entirely secure.
> A proper krb5 authentication module uses a service key (such as a host
> key) to verify the returned TGT, in order to prevent an attacker from
> spoofing the KDC. Unfortunately, the JAAS Krb5LoginModule does not
> contain this functionality.
Generally, my sentiments are in agreement with Russ Alberry about not
violating the Kerberos security module, and trying to use native Kerberos
authentication as widely as possible, rather than using Kerberos as a
glorified password verification backend ...
So, I hate to admit this, but we too allow password-over-SSL
authentication on our XMPP servers (in addition to SASL/GSSAPI).
We do use Openfire, but rejected Sun's JAAS precisely because of
the security issue (lack of verification of the KDC response with
a stored service key). Instead, we decided to write a small JNI
function that wrapped some C code that used the MIT krb5 API to
do this properly. It's much messier to integrate into Openfire
though. A colleague of mine suggested that we should plan to
replace this with Java code that used lower level interfaces, eg.
http://www.docjar.com/docs/api/sun/security/krb5/internal/package-index.html
but that looks like a bunch of work and we're a bit lacking in
programmers motivated to write Java :-)
It'd be nice if there was a Java version of the MIT krb5 API or
a more capable version of JAAS.
--Shumon.
Edward Murrell
OpenLDAP, with the Cyrus saslauthd daemon to allow plain text logins.
This link was incredibly helpful for getting saslauthd to comply;
http://www.semicomplete.com/articles/openldap-with-saslauthd/
GSSAPI and plain text logins work off the same password. As Russ
Allberry pointed out in the other sub thread, this is not the best
policy, so all the non-SSL channels, XMPP or otherwise, are disabled.
(If this was for a company, rather than a personal domain, I'd probably
do things slightly differently.)
Cheers,
Edward
On Mon, 2009-11-30 at 10:25 +0100, Oliver Schmidt wrote:
> Hi,
>
> I'm currently trying to setup an XMPP server with Kerberos 5
> authentication. I've been using eJabberd 2.0.5 with username/password
> authentication for a while. Now, I would like to use Kerberos in order to
> make my services more comfortable with SSO.
>
> Unfortunately, I failed using an GSSAPI patch for eJabberd together with
> my Kerberos system. After that, I tried using Openfire, which didn't work
> out for me either. Now, that I've read about that institution-wide XMPP
> service the MIT offers, I know that XMPP _must_ work with Kerberos
> somehow. Can you tell me how you set it up and, respectively, which
> software you did use?
>
> Thank you in advance!
>
> Yours
>
> O. Schmidt
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
Russ Allbery
> GSSAPI and plain text logins work off the same password. As Russ
> Allberry pointed out in the other sub thread, this is not the best
> policy, so all the non-SSL channels, XMPP or otherwise, are disabled.
We were very pleasantly surprised at how universal both GSSAPI and TLS
support are in current XMPP clients. We were expecting requiring one or
the other to be a big hassle, but we require both and haven't had many
serious problems.
http://im.stanford.edu/ has our user documentation, in case anyone finds
it useful. We're running OpenFire as the server. (It has some serious
issues and I'd rather run something else, but the GSSAPI support at least
is fairly good. Even if it gets horribly confused by unqualified
principal names in places and then starts throwing Java exceptions.)