[1363] in Kerberos_V5_Development
Re: kdc performance and rcache
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Sat Jun 29 17:55:21 1996
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 29 Jun 1996 17:55:05 -0400
In-Reply-To: Sam Hartman's message of 29 Jun 1996 12:09:41 -0400
Sam Hartman <hartmans@mit.edu> writes:
> I am not sure what cache deals with resending duplicate
> requests (is that part of the replay cache or does that just detect
> duplicates),
That's the lookaside cache -- the singly-linked list that becomes
abysmally slow under heavy load. I'm not sure what use the library's
replay cache is. Maybe for rejecting packets that are different
bitwise but decoded have pretty much the same request as a previous
one? Why would we want to do that?
> 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'd be interested in hearing more details on this. If it really is a
problem, we can just use a better cache structure.
> 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.
Um, I really hope not. Why should the client require that all
responses be identical, as long as one gets through that works?
