>>>>> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> 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). ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos