KDC lookaside cache and DB age

[ghudson@MIT.EDU]

Our KDC keeps a lookaside cache of recent requests and responses.  If
a request arrives whose encoded representation matches an entry in the
lookaside cache, the KDC just replays the response.  Lookaside entries
are treated as stale and purged if (1) they are more than two minutes
old, or (2) the DB has been modified since the time of the request
(according to krb5_db_get_age()).

I'd like to eliminate the second criterion, for two reasons.  First,
the LDAP back end has no good answer for krb5_db_get_age(), so
lookaside entries only remain valid for one second, which is short
enough to be mostly useless (clients will wait that long to retransmit
queries).  Second, account lockout support means the KDC frequently
updates the DB when processing a request, causing the lookaside cache
to be mostly usless.

The commit introducing the concept of DB age (in 1995) has this
message:

  replay.c: The KDC replay cache needs to store the database
        modification time, so that if the database is modified in
        between when it receives a request and when it receives a
        replay of the same request, it knows to throw away the
        replay cache entry and generate a new response (since the
        record in the database on which the response is based may
        have been modified).

I think this reasoning is flawed.  A truly new request will have a new
nonce, so any request matching a lookaside entry can be assumed to be
a retransmit.  Under that assumption, there should be no harm in
retransmitting a slightly stale reply; after all, the same would occur
if the request came in over TCP and the response took a while to make
it back to the client due to dropped packets.