How to disable replay cache in a kerberized client-server app ?

[Ken Raeburn]

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