review of Projects/replay_cache_collision_avoidance, ending Jan. 12
ghudson at MIT.EDU
Mon Dec 29 11:45:39 EST 2008
On Mon, 2008-12-29 at 08:02 -0500, Tom Yu wrote:
> What proportion of false positives is acceptable in a mixed-code
I think mixed-code deployments are going to be rare. It's good that
we're going to effort to prevent things from breaking in such
deployments, but I don't think we need to bend over backwards to ensure
that we still get a reduction in false positives in such environments.
> One interesting possibility is to store a truncated copy of the hash
> in the microseconds field, which an old implementation would likely
> preserve when performing an expunge.
Speaking of which, the project proposal says:
For new servers reading entries written by old servers, the
string fields will be valid principal names and the time stamp
value will not be a small integer. As a result, the server will
know it is dealing with an old style entry and perform an old
style check. This might lead to false positives but there is
nothing we can do without additional information that is not
but the earlier part of the proposal doesn't mention anything about
putting a small integer in the time stamp value of hash records. Is
there a missing bit of the proposal?
> I'd still like to know what benefit hashing the decrypted
> authenticator has above hashing the ciphertext. As Roland pointed out
> elsewhere in that thread, the mandatory parts of the cleartext
> authenticator contain nothing that is guaranteed to be different for
> multiple rapidly consecutive legitimate requests. Hashing the
> ciphertext makes it less likely that false positives will occur.
I think Sam has reversed his position on that point based on discussion
with Ken, and we can safely hash the authenticator ciphertext.
More information about the krbdev