Replaying and server side caching.

[Darren Reed (OSE)]

> From: Sam Hartman [mailto:hartmans at mit.edu]
> >>>>> "Darren" == Darren Reed (OSE) <darrenr at optimation.com.au> writes:
> 
>     Darren> Whilst testing the KDC with replaying TGT requests, it
>     Darren> became apparent that if the cache was enabled then a
>     Darren> replayed TGT request would be answered.  This seemed
>     Darren> dubious in terms of security, but is it deliberate ?
> 
> 
> Yes.  Kerberos supports UDP.  IT will replay the exact same response,
> giving no cryptographic advantage.

Is the Kerberos development team interested in a patch that would
support an error being returned after a configurable number of
identical queries has been received ?  If so, is this a krb5.conf
thing rather than kdc.conf so that clients know how many times they
can reasonably expect to try sending any given TGT request and get
a good response ?

Rejection of duplicate, identical, queries was found in the Cybersafe
KDC that we're upgrading from and from a strict security perspective,
we found this very attractive.  To match this behaviour, I've changed
our KDC to reject any TGT request if it can be found in the cache.
In our environment, the application that generates the TGT request
never generates two identical ones - the timestamps (at least) will
always be updated for the new one.  Is this sort of behaviour worth
investigating for the standard MIT Kerberos distribution ?

I understand why you would allow this for UDP, but in our experience,
we found that if the TGT request got to the KDC, it was extremely
unlikely for the TGT response to not find its way back to the client
in a normal operational environment.

Darren