Proposed modifications to replay cache to prevent false positives
raeburn at MIT.EDU
Thu Jun 2 14:52:08 EDT 2005
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
More information about the krbdev