Heimdal or MIT kerberos

[sam]

Hi,

I m not sure which kerberos I should use. With Heimdal, it is a
thread-safe implementation, while MIT's kerberos is not.

Please correct me if I m wrong, it appears that there is more
applicatoins support MIT kerberos than Heimdal.

I basically want to use kerbeors as a SSO server and allows various
internet/network service to securely authenticate with users.
Applications I would like to be kerberized is samba, apache, email (ldap)..

So which kerberos should be used to avoid future difficulty of
integration with the above application?

thanks
sam

[Frank Cusack]

Post by sam
Hi,
I m not sure which kerberos I should use. With Heimdal, it is a
thread-safe implementation, while MIT's kerberos is not.
Please correct me if I m wrong, it appears that there is more
applicatoins support MIT kerberos than Heimdal.
I basically want to use kerbeors as a SSO server and allows various
internet/network service to securely authenticate with
users. Applications I would like to be kerberized is samba, apache,
email (ldap)..
So which kerberos should be used to avoid future difficulty of
integration with the above application?

Heimdal does not have a functioning replay cache, so if your app
needs that you must go with MIT. MIT also seems to be more actively
developed. (That's not to say that heimdal doesn't get worked on.)

Most software these days still depends on MIT, however porting to
heimdal is pretty easy.

What my site does is use the heimdal server and MIT clients. And
local apps (client or server) are all built against MIT. We use
heimdal for the PK-INIT support.

If heimdal is thread-safe, that's news to me. You shouldn't care
if the apps you plan to use are off the shelf (sounds that way).

Apache kerberization is a long hard road. You're much better off
going with pubcookie or some such system.
http://middleware.internet2.edu/webiso/ is a good page that
points to lots of web sso software.

Samba? good luck there as well.

I don't understand why you wrote 'email (ldap)', what does ldap
have to do with sso for email? Anyway, email kerberization is
relatively easy, but for the end-user, relatively non-eventful
since every mail client will store the user's password for them
(and you can do imaps or imap with digest auth to protect the
secrets). LDAP kerberization is also fairly well handled these
days (but again, little to do with email authentication as such).

Summary: I'd stick with MIT.

/fc

[Luke Howard]

Post by Frank Cusack
If heimdal is thread-safe, that's news to me. You shouldn't care
if the apps you plan to use are off the shelf (sounds that way).

Recent snapshots have explicit concurrency support -- I'm not sure
which, if any, of the releases include this.

-- Luke

--

[Sam Hartman]

Post by Frank Cusack
If heimdal is thread-safe, that's news to me. You shouldn't
care if the apps you plan to use are off the shelf (sounds that
way).

Luke> Recent snapshots have explicit concurrency support -- I'm
Luke> not sure which, if any, of the releases include this.


As do recent snapshots of MIt Kerberos; the upcoming 1.4 release will
include this work.

--Sam

[Andreas]

Post by Sam Hartman
Luke> Recent snapshots have explicit concurrency support -- I'm
Luke> not sure which, if any, of the releases include this.
As do recent snapshots of MIt Kerberos; the upcoming 1.4 release will
include this work.

This is great news, I hope to be able to test it.

[sam]

Post by Frank Cusack

Post by sam
Hi,
I m not sure which kerberos I should use. With Heimdal, it is a
thread-safe implementation, while MIT's kerberos is not.
Please correct me if I m wrong, it appears that there is more
applicatoins support MIT kerberos than Heimdal.
I basically want to use kerbeors as a SSO server and allows various
internet/network service to securely authenticate with
users. Applications I would like to be kerberized is samba, apache,
email (ldap)..
So which kerberos should be used to avoid future difficulty of
integration with the above application?

Heimdal does not have a functioning replay cache, so if your app
needs that you must go with MIT. MIT also seems to be more actively
developed. (That's not to say that heimdal doesn't get worked on.)
Most software these days still depends on MIT, however porting to
heimdal is pretty easy.
What my site does is use the heimdal server and MIT clients. And
local apps (client or server) are all built against MIT. We use
heimdal for the PK-INIT support.
If heimdal is thread-safe, that's news to me. You shouldn't care
if the apps you plan to use are off the shelf (sounds that way).
Apache kerberization is a long hard road. You're much better off
going with pubcookie or some such system.
http://middleware.internet2.edu/webiso/ is a good page that
points to lots of web sso software.
Samba? good luck there as well.
I don't understand why you wrote 'email (ldap)', what does ldap
have to do with sso for email? Anyway, email kerberization is
relatively easy, but for the end-user, relatively non-eventful
since every mail client will store the user's password for them
(and you can do imaps or imap with digest auth to protect the
secrets). LDAP kerberization is also fairly well handled these
days (but again, little to do with email authentication as such).
Summary: I'd stick with MIT.
/fc

Thank you very much for your suggestion. I think I will use Heimdal as a
server as well.

Thanks
Sam

[Ken Raeburn]

Post by Frank Cusack
Heimdal does not have a functioning replay cache, so if your app
needs that you must go with MIT.
If heimdal is thread-safe, that's news to me. You shouldn't care
if the apps you plan to use are off the shelf (sounds that way).

MIT's use of a replay cache also leads to poorer performance of
application servers under very heavy load (but if you're not under
heavy load, do you care about that extra tiny fraction of a second
delay?). I believe the replay cache may also be a contributor to MIT's
reported worse behavior in multithreaded servers; none of that code is
thread-safe, and we can spend quite a few cycles there.

I did some thread-safety work that's in the current snapshots, and it's
a goal of the next release. Though testing to ensure thread safety is
difficult at best, and we don't run a lot of threaded Kerberos apps on
a day-to-day basis in the MIT Kerberos group. (None of our programs
will use threads in the next release, it's just the libraries being
updated so that they can be used in applications that do use threads.)
So if anyone wants to test the snapshots and give feedback, help us
find problems, etc., and make the thread safety support more solid
before we ship it, please do!

Our next release will also have a mechanism to explicitly disable the
replay cache for an application, though we don't recommend it unless
it's known that the application protocol is protected against replays.
Actually, it's a little more complicated -- every application protocol
using the same service principal must be so protected, or use of one
service may provide data that can be used in a replay-like attack on
another.

Ken

[Donn Cave]

In article <471040B3-1610-11D9-9B8B-000A95909EE2 at mit.edu>,

Post by Ken Raeburn

Post by Frank Cusack
Heimdal does not have a functioning replay cache, so if your app
needs that you must go with MIT.
If heimdal is thread-safe, that's news to me. You shouldn't care
if the apps you plan to use are off the shelf (sounds that way).

MIT's use of a replay cache also leads to poorer performance of
application servers under very heavy load (but if you're not under
heavy load, do you care about that extra tiny fraction of a second
delay?). I believe the replay cache may also be a contributor to MIT's
reported worse behavior in multithreaded servers; none of that code is
thread-safe, and we can spend quite a few cycles there.

That fits with my observations with Cyrus SASL GSSAPI
authentication in an LDAP service. Heimdal is commonly
recommended there. I tried both, and MIT was indeed slower
and crashed in the GSSAPI code under heavy load.

But it's really pretty simple to add an interlock to the
SASL GSSAPI module, which disposes of the issue entirely,
and I felt that authentication was acceptably fast and we
didn't need to abandon replay checking.

Donn Cave, donn at u.washington.edu

[Henry B. Hotz]

Date: Sun, 03 Oct 2004 22:40:50 -0700
From: Frank Cusack <fcusack at fcusack.com>
To: kerberos at MIT.EDU
Subject: Re: Heimdal or MIT kerberos
Message-ID: <m3ekkfvy59.fsf at magma.savecore.net>
References: <cjqfj4$1rss$1 at news.hgc.com.hk>
Precedence: list
Message: 2

Post by sam
I m not sure which kerberos I should use.

They're both good. Don't sweat it too much.

Heimdal does not have a functioning replay cache, so if your app
needs that you must go with MIT.

Very true, but it depends on the app whether it matters or not.
Heimdal doesn't support password history checking either, but there's
public code to add that if you don't run a very large site.

Apache kerberization is a long hard road. You're much better off
going with pubcookie or some such system.
http://middleware.internet2.edu/webiso/ is a good page that
points to lots of web sso software.

Hmmm. If you use a recent Mozilla-derivative and mod_auth_kerb with
Apache it seems to handle the basics. Haven't checked interop with MS
products.

Which one you choose may depend on whether you need some add-on. There
are a couple of hardware pre-authentication devices supported only with
MIT patches, but the PKINIT patches are only for Heimdal.
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu