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

[Matthieu Hautreux]

On 3 fév, 22:16, Ken Raeburn <raeb... at MIT.EDU> wrote:
> 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.
>

Tank you, that could be a good solution. The only drawback is that I
wrote an API that encapsulate kerberos stuff on TCP stream and that
doing it this way it would disable replay cache for all an
application, not just scalability concerned parts.

> 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. :-)

I will be much better interested, on a short term basis, in a way to
do replay cache configuration using the kerberos API.
I would rather help you writing this part and let you do the config
file one ;)

>
> > 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....

You are right, I came to the same conclusion. Furthermore, as I plan
to launch several hundred threads, using numerous replay caches or no
replay cache at all would roughly be the same. I saw in the source
code that there is a "memory" replay cache type. Is it working ? do
you have examples of how to use it ? perhaps the scalability would be
better this way without impacting security.

>
> > 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.
>

Thank you, I will take a closer look ASAP and let you know about the
results if you are interested in.

Matthieu

> Ken