How to disable replay cache in a kerberized client-server app ?
matthieu
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.
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.
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 ?
Thank you for your help.
Regards,
Matthieu
Ken Raeburn
> 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
Matthieu Hautreux
> 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