Proposed modifications to replay cache to prevent false positives

[Ken Raeburn]

On Jun 2, 2005, at 11:21, Roland Dowdeswell wrote:
> 	2.  the hash should be performed on the authenticator prior
> 	    to decryption so that the ticket used is implicitly
> 	    part of the hashed data (since it's session key should
> 	    be different than any other session key) and the
> 	    authenticator's IV should eliminate the chance of
> 	    false positives using the same ticket.

The session key is stored in the ticket, and is set by the KDC; it and 
the rest of the ticket cannot be altered by the client.  But the 
authenticator should vary in timestamp (usually), subkey (if provided 
at all), and initial sequence number (if used).  Currently we only 
check the timestamp, and client and server names, as specified by the 
RFC/draft.  (Actually, the current draft says we must use and store 
these fields, so storing only a hash would technically in violation of 
the spec, but the spec obviously needs work in this area anyways.)

> Since we're only trying to stop replays, I do not think that the
> hash needs to have any serious cryptographic properties at all.
> The same authenticator only needs to always hash to the same value.
> Collision resistance is meaningless, unless you are trying to create
> false replays (for some... reason...) I'd be willing to guess that
> a simple CRC would have the properties that you want.

For paranoia's sake, I think I'd want something with more than 32 bits 
of output, and introducing yet another hash/checksum type function into 
the code for this seems like overkill.  I'd be happy with MD5 or SHA-1, 
or truncated (64- or 96-bit?) SHA-1, for example.  And that gives us 
one less chunk of code we want to optimize, if performance does become 
a problem.

Ken