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