On Feb 3, 2009, at 14:48, matthieu wrote: > I'm currently writing a kerberized daemon and would like to disable > replay cache. I'm using krb5-1.6.1 (RedHat 5.2). > > I did not find any relevant function in the API. I finally find the > krb5_rc_resolve_full function in the krb5 source code and use it for > now with a replay cache file name like "none:nofile". It works quite > great. I just have to free the returned krb5_rcache structure manually > to prevent a memory leak.
There's an environment variable you can set -- three, actually, though you only need one here. The library looks for KRB5RCACHETYPE, KRB5RCACHENAME, and KRB5RCACHEDIR. If you set KRB5RCACHETYPE to "none" it should disable the cache. Unfortunately, as you've noticed, the public API doesn't have good hooks for managing this. I recall writing up some notes once about how we might specify replay caches per service via the config file -- so multiple services using the same key could be told to use the same non-default cache without hacking the code or environment for each one in sync -- but after poking around with google a little I can't find a public record of it. If you're interested in writing some code to do something like this, let me know. :-) > Is there an other way to do that ? The reason why I have to do this is > that I need to write a scalable deamon and that replay cache mechanism > provides a huge contention in my multithreaded application. I first > searched for a way to use a different replay cache file per thread but > didn't find a way to do it either. The problem is, all threads really should be looking at the same data; sending replay attacks and having them pass undetected because they were processed by different threads would be poor. Of course, it's probably still better from a security perspective than completely disabling the replay cache.... > I also have an other question. Is it possible to get an addressless > TGT using a non addressless one. A kind of forward that give you back > an addressless ticket ? Yes, it should be, I think. We don't have any separate programs for just doing the forwarding and dumping the new TGT into a credentials cache or anything like that; it tends to be built into programs that actually send the new credentials. Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
