context negotiation performance problem

[Nicolas Williams]

On Wed, Nov 02, 2005 at 04:10:34PM -0700, Eric Mei wrote:
> Ken Raeburn wrote:
> 
> >That's almost certainly the replay cache file, meant to prevent the  
> >re-use of a transmitted authenticator by an attacker.  The fsync is  
> >there to handle the problem of the machine crashing or losing power  
> >after an authenticator has been accepted and a data exchange  
> >performed, but the on-disk cache not yet updated.
> >
> >If your protocol or threat model is such that replay attacks are not  
> >a problem, then under later versions of the code (I'd check whether  
> >it's in the 1.4 series, but the machine where I keep my source trees  
> >checked out ate its root file system over the weekend) you could set  
> >the environment variable KRB5RCACHETYPE to "none" before starting the  
> >program.  (Look for src/lib/krb5/rcache/rc_none.c to see if you've  
> >got the support.)
> >
> >Is this a single-process server, or multiple processes?  Multiple  
> >processes would probably deal better with the fsync calls.
> 
> Thanks a lot Ken. 1.4.2 indeed support KRB5RCACHETYPE=none. I enable it 
> and rewrite the test as multi-processes. Now the server could handle at 
> least 600/s now.

Be sure this is safe...

What service name are you using?  If you're using 'host' then make sure
you're not also running telnet/rlogin/ftp services.  If it's something
else, and/or used only by your application then make sure that the
application protocol is such that replay protection by the mechanism is
not necessary.

One way an app protocol does that is by having an extra round-trip where
the acceptor sends a random cookie/nonce to the initiator and the
initiator parrots it back -- all with integrity protection, at least.

Nico
--