rcache fsync() avoidance

[Greg Hudson]

On 09/01/2014 05:59 PM, Nico Williams wrote:
> One of the things that makes the traditional MIT rcache design painfully
> slow is the use of fsync() in each operation that doesn't detect a
> replay (the common case).

I think at this point we are prepared to just get rid of the fsync()
calls in the MIT krb5 rcache implementation, and call that an
implementation limitation.  My reasoning is:

* For most situations where replay caches help, they provide limited
protection against active attacks anyway.  (Basically: if the protocol
needs replay protection because it uses Kerberos for authentication
only, an active attacker could modify the data stream or suppress the
legitimate authentication to bypass the replay cache.  Replay caches
only provide complete protection when the data stream is protected by
the Kerberos authentication context, but without an acceptor subkey,
such that an attacker could replay a complete session to cause an action
to be executed twice.)

* The design you outline degrades into bad performance if either (1) the
server has negative clock drift beyond the boot time estimate, or (2) a
non-trivial fraction of clients have positive clock drift beyond the
boot time estimate.  It can also cause spurious authentication failures
shortly after boot, for clients with negative clock drift.

* The probability of bad performance behavior increases as the boot time
estimate approaches zero.  At some point in the future we might start to
see VMs with sub-second reboot times, at which point even a 1s positive
client clock drift would force an fsync() and even a 1s negative client
clock drift could cause a spurious authentication failure shortly after
a reboot.