Re: KDC replay cache unnecessary?

[Ken Raeburn <raeburn@MIT.EDU>]

Frank Cusack <fcusack@fcusack.com> writes:
> Applications that use encryption with the shared session key do not need
> a replay cache.

Not always true -- an attacker could replay the client-side messages
from a previous exchange.  If the effect is not idempotent, or
processing the request consumes significant resources (CPU time for
encryption, disk space, etc), then bad things can happen.  If the
server were providing a subkey for the client to use, this wouldn't be
a problem, but that's often not the case.

In the AS case, I thought we had discussed some time back that some
preauth mechanisms might become confused if a client's request is
repeated?

In the TGS case, we probably don't care.

> Therefore isn't the KDC replay cache unnecessary?

For the TGS, yes, it is unnecessary, unless CPU speed becomes an
issue.  (And even then the work needed to maintain the cache needs to
be examined.)

> This is an important question, because, AFAIK, multiple KDCs do not keep
> their replay caches in sync (referring to unix implementations only).
> If the replay cache is actually necessary, this is a major problem.

My guess is that the reason for having implemented it in the MIT code
is one or both of:

 - save CPU time
 - reduce the amount of data one can get encrypted in a single key

In both cases, assuming the cache actually has the desired effect, it
is not necessary for the KDCs to coordinate just to save some small
factor of N.  The case where a KDC is saturated with requests is more
important.

I doubt the replay cache is effective at saving CPU time, and the
amount of additional encrypted data one can acquire probably isn't a
big deal; I suspect most of our replays result from network problems
anyways.  So aside from the preauthentication issue, I don't think
it's very useful.  (And in the MIT code, I think part of it is
implemented at a point before AS and TGS requests are distinguished;
I'm not sure how difficult it would be to switch it off for just the
TGS.)

Ken