Proposed modifications to replay cache to prevent false positives

[Nicolas Williams]

On Sat, May 10, 2008 at 01:59:23AM -0400, Jeffrey Altman wrote:
> Please review
>   http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance

B-trees won't help that much, and may possibly hurt.  Unless...

Will F. greatly improved the performance of the replay cache on Solaris.
The improvement was phenomenal, but fsync() is still the gating factor,
so you get even more perf by putting the rcache in a tmpfs filesystem.

Putting the rcache on tmpfs is technically a problem: any vulnerability
that can allow an attacker to panic your system will allow the attacker
to replay AP-REQs.  One solution to that is to not use protocols that
are susceptible to replay attacks (e.g., use SSHv2 instead or r-cmds).
Another is to reduce the skew time on the server to something related to
its time to boot.

I propose that in addition to whatever you do for rcache perf, we do the
following:

 - provide an option to set the server-side skew to some number of
   seconds, which in general should be estimated time to boot * 2

 - provide an option to put the rcache on tmpfs or tmpfs-like
   filesystems

With such an option then a B-tree may be useful.

An rcache implementation as a daemon reached via IPC would be even
better.

Nico
--