[1377] in Kerberos_V5_Development
Re: "benchmark" numbers not so bad after all
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Jul 3 14:57:19 1996
Date: Wed, 3 Jul 1996 14:51:17 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Raeburn <raeburn@cygnus.com>
Cc: krbdev@MIT.EDU, kerberos-dev@cygnus.com
In-Reply-To: Ken Raeburn's message of 03 Jul 1996 11:42:34 -0400,
<tx1ohlxs5qt.fsf@cygnus.com>
A couple of comments on the speed up issues. First of all, it's really
obvious the replay cache should be elimiated ---- as long as we have the
lookaside cache, the replay cache is guaranteed _not_ to provide any
benefit whatsoever. And, the replay cache is taking up 50% of the raw
processing time of the ticket.
As far as the lookaside cache is concerned, the only real value-added
for the lookaside cache is that it eliminates the possibility of more
known-plaintext attacks. Of course, if you don't have
preauthentication, you can always ask for lots of AS_REQ's, but in the
case of AS_REQ's with preauthentication and TGS_REQ's, the lookaside
cache prevents the KDC from emitting up to 300 (one per second, assuming
a 5 minute time skew) additional tickets, all encrypted with the same
key.
This is somewhat of a concern, but practically speaking, known plaintext
attacks require pairs in the order of 2^40 or so, so I believe this is
more of a certificational weakness more than a practical one. In any
case, for the TGS key the attacker can probably get plenty of
known-plaintext pairs for the TGT key just simply by watching the wire
near the KDC anyway.
On the other hand, just to see how the KDC would work out at MIT's
environment, I worked on gathering some statistics: Over a 30 minute
period, we had 1150 AS requests, and 3,789 TGS requests on our master
server. That works out to 0.64 AS requests per second, and 2.11 TGS
requests per second, or 2.75 KDC requests per second.
Even when (as we did earlier this morning) we had a bone-headed shell
script running of control on Athena consultant machine, the additional
load that presented us with was just a bit over 2 requests per second
(140 AS requests/minute).
So even without the replay cache removal, the capability of handling 23
requests per second is about an order of magnitude more capacity than a
site the size of MIT would need. Even if a company was doing something
that used kerberos and WWW, it wouldn't significantly increase the load
on the KDC since tickets are cached.
Hence, keeping the lookaside cache would cost us an extra 6 ms/request
(and I think that number could be brought down, since it's coded in an
extremely inefficient fashion), and it's not clear that the cost to us
in requests per second is really going to impact the KDC in a real
production setting. What do we get from keeping the lookaside cache? A
small increase in cryptographic security, but that seems to be about
it.
I'd consider it a toss-up. I'd lean towards keeping it, since I don't
think anyone will really miss the additional processing time, but I
suspect it really doesn't matter one way or the other.
Comments?
- Ted
