Replaying and server side caching.

[Marcus Watts]

"Darren Reed \(OSE\)" <darrenr at optimation.com.au> writes:
> From: "Darren Reed \(OSE\)" <darrenr at optimation.com.au>
> To: "Sam Hartman" <hartmans at mit.edu>
> Date: Thu, 10 Apr 2003 14:04:58 +1000
> Message-Id: <IPEIKBHGOCCFLKLJFFOEIEGJCDAA.darrenr at optimation.com.au>
> 
> > 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

I'm not sure I understand what security advantage there is to not
replying to a duplicated request with the same response.  It's just the
same packet over again -- what new thing does an attacker learn he
didn't know the first time?  If it is a problem, then having the KDC
refuse to send duplicated responses doesn't fix anything, since the
attacker could still duplicate and return extra responses.

The more complicated one's network path is, the more likely weird
behavior becomes.  On a properly configured LAN, or within a well
designed enterprise setup, weird behavior is unlikely.  In a
multi-vendor WAN environment, weird behavior is much more likely.
Weird behavior includes:
	randomly dropped packets
	assymetric routing -- your packets to there take a different
		path than the packets that come back.
	one-way connectivity -- your packets get there.  The reply doesn't
		come back to you.
	out of order delivery.  
	duplicated packets -- your packets get there twice.
	mutated packets -- your packets get chewed up somewhere.
	data sensitivity -- *some* of your packets don't get, or back.
Anytime you cross an administrative boundary, all of these increase in
likelyhood.  NATs and Firewalls, which both imply crossing such a
boundary, greatly increase the chance of something weird happening.
Confused network administrators also greatly increase the odds;
so weirdnesses aren't even distributed, but tend to clump up.

I've seen and used plenty of networking setups where weirdness was rare
or non-existant.  I've also had to live with networking where problems
were both common and not easily solved.  Kinda like potholes in roads.

					-Marcus Watts