On Mon, Oct 15, 2007 at 09:16:47PM +0100, Darren J Moffat wrote:
> Wyllys Ingersoll wrote:
> > Customers are asking for the functionality that currently exists in the MIT 
> > kerberos code that allows for one to run kerberos and have the replay cache 
> > functionality disabled.  Currently that is not possible, the only two 
> > choices 
> 
> Why do they want that functionality ?
> 
> What is wrong with the reply cache that means they desire to disable it 
> and take the security risks associated with doing so ?

Latency.

We already have a MEMORY rcache, and a way to put the normal FILE rcache
on tmpfs (/var/run/...).  So latency already is, or _should be_ quite
low.  Have we got any profile data showing what is the latency of each
of the various rcache options we have now?

Note that Kerberos V security depends on replays being detected (either
because they are outside the allowed time skew window or because they
are detected by the replay cache).  A a null rcache option would have to
be used with great care.  I would hate for an insecure configuration to
become very common if we could instead squeeze the rcache latency down
further.

Note:  The Solaris krb5 team already has squeezed quite a bit out of the
       MIT FILE rcache turning various functions into macros and
       factoring expensive system calls out of the main loop, but the
       limiting factor on anything other than tmpfs is fsync(), and
       therefore, I/O latencies.

       But the MEMORY rcache and the FILE rcache on tmpfs ought to
       perform well enough already for any and all customers.

That MIT supports a NONE rcache should be no excuse for Solaris
supporting it too if any of the other options performs sufficiently
well.  Solaris Kerberos can be better than MIT krb5, and that can be a
differentiator for us, even if we'll eventually contribute our changes
back to MIT (technically MIT could pick them up now, if they weren't
CDDL-averse...).

> I want to work out if disabling this is actually fixing the real problem 
>   or just masking some other issue.

Profile data (obtainable with dtrace, no doubt) would help.

Nico
-- 

Reply via email to