review of Projects/replay_cache_collision_avoidance, ending Jan. 12
tlyu at MIT.EDU
Mon Dec 29 11:57:18 EST 2008
Greg Hudson <ghudson at MIT.EDU> writes:
> 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.
I think that looking for pairs of entries as an indication of a record
written by a new implementation will reduce the number of false
positives for authenticators received by new implementations. I'm
fairly sure this gives us at least a somewhat improved false-positive
rate in a mixed-code deployment.
>> 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 think I forgot to update part of the proposal after I removed the
part of the prior version of the proposal that would put identifying
information in the timestamp field. I think it turns out that using
the timestamp that way would cause an old implementation to
prematurely expunge new-style cache records.
>> 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.
Ok, it looks like we have consensus on this part.
More information about the krbdev