[1361] in Kerberos_V5_Development
Re: kdc performance and rcache
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Jun 29 12:10:00 1996
To: Ken Raeburn <raeburn@cygnus.com>
Cc: krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 29 Jun 1996 12:09:41 -0400
In-Reply-To: Ken Raeburn's message of Thu, 27 Jun 1996 04:35:02 -0400
>>>>> "Ken" == Ken Raeburn <raeburn@cygnus.com> writes:
Ken> Rewriting the algorithm to something O(log(n)) might be an
Ken> improvement too, and could make it worth keeping, but then
Ken> again, maybe not. (After fsync, the linked-list scan got to
Ken> be high on the cpu-wastage list when I was whacking on the
Ken> KDC with my rather abusive test program.)
Ken> Unless anyone's got a reason why these caches should be
Ken> considered useful, I'll check in the changes to disable them
Ken> in the KDC (but keep the implementations intact) next time we
Ken> merge Cygnus changes into the MIT tree.
I am not sure what cache deals with resending duplicate
requests (is that part of the replay cache or does that just detect
duplicates), but there is some concern about a potential for a known
plaintext attack by having the kdc respond multiple times to a
particular TGS request. I suspect it's slow enough that this isn't an
issue, but it is important to at least realize that clients do assume
that the KDC will look up their requests in the replay cache and
resend the same response if packets are lost, etc.
