[22612] in Kerberos
Re: Heimdal or MIT kerberos
daemon@ATHENA.MIT.EDU (Donn Cave)
Mon Oct 4 16:48:42 2004
From: Donn Cave <donn@u.washington.edu>
Date: Mon, 04 Oct 2004 13:33:07 -0700
Message-ID: <donn-804250.13330704102004@gnus01.u.washington.edu>
To: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
In article <471040B3-1610-11D9-9B8B-000A95909EE2@mit.edu>,
raeburn@MIT.EDU (Ken Raeburn) wrote:
> On Oct 4, 2004, at 01:40, Frank Cusack wrote:
>
> > 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@u.washington.edu
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
