Ticket File Cached in Memory?
John W. M. Stevens
john at betelgeuse.us
Thu Aug 27 09:41:25 EDT 2009
On Thu, Aug 27, 2009 at 08:42:29AM -0400, Greg Hudson wrote:
> On Thu, 2009-08-27 at 04:51 -0400, FROHNER Akos wrote:
> > According to our experience the bottleneck is rather in
> > the replay cache.
> Not all protocols require a replay cache. You can turn ours off by
> setting KRB5RCACHETYPE=none in the environment.
Good pointer. Thanks!
> One way to protect the server from replays is to design the protocol so
> that the server sends a nonce to the client and requires the client to
> play it back (with stream protection, of course).
The core design, in a few sentences, is that of an event messaging
(as in: OO messaging) system (asynchronous, parameters allowed but
no returns) between "peers" where each peer has to be a kind of
server, in that it can accept connections, authenticate them, then
hand off the connection to a sub-process to process.
I initially started off with just authentication (no message encryption),
but decided that I would add encryption after some thought.
In a high load test, with a lot of short lived peer-to-peer connections,
the system is seeing a lot of disk thrash. This really didn't occur
until after I added message encryption, and in that process I did
attempt to turn on replay detection, so I might very well be
chasing down the wrong path.
> In an ideal world, even that much should be unnecessary if you are doing
> mutual authentication and stream protection,
And ideally this system would have a lower risk of replay due to the
short lived nature of the connections.
> and not protecting any
> application data with the authenticator checksum. This is because
> ideally, the server would pick a fresh subkey each time the client
> authenticates. Unfortunately, the server's use of subkeys is kind of
> spotty at this time (for instance, for GSSAPI, it won't do so if the
> client appears too old) and I believe was nonexistent prior to krb5 1.7.
I'm going to have to do some reading to understand this last
part. Thanks for the input, though.
> We're aware that our replay cache implementation is often a bottleneck,
> and I should have probably thought to mention it earlier.
Is the replay cache stored in a file that, in the default install, is
given a temporary name and put into a temporary directory?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090827/ff6ac13e/attachment.bin
More information about the krbdev