Thread-safe libraries

[Cesar Garcia]

>>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

>> It is also worth noting, that, while Heimdal is not thread safe (at least there 
>> are no guarantees), it has proven to be much more thread-robust than MIT. 
>> OpenLDAP page and a couple of users have expirienced problems with MIT and 
>> threaded OpenLDAP server, while Heimdal performed flawlessly.
>> 
>> It could be that Heimdal IS thread-safe, just nobody knows for sure. :-)

Ken> I believe that many of the problems of thread-safeness in MIT Kerberos
Ken> result from the lack of any file locking in the replay cache code.

Ken> Heimdal solves this part of thread-safeness by not having a replay
Ken> cache, at a cost to security.  How much this affects security in
Ken> practice is debatable; I'm not aware of any current attacks against
Ken> Kerberos application servers via ticket replay, but it's certainly
Ken> possible.

wrt to gssapi and 1.3.1 ...

Since we're pointing out lack of replay cache detection, note that if
acquiring creds for GSS_C_NO_NAME, then no replay cache is used.
(specifically looking at 1.3.1 - lib/gssapi/krb5/acquire_cred.c)

Acquiring creds for GSS_C_NO_NAME is also a result of invoking
gss_accept_sec_context with a verifier cred of GSS_C_NO_CREDENTIAL.
(This is very convenient for certain apps).

Of course, in the case of MIT - the choice is yours (at least
implicitly).