Ticket File Cached in Memory?

[John W. M. Stevens]

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?

Thanks,
John S.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090827/ff6ac13e/attachment.bin