review of Projects/replay_cache_collision_avoidance, ending Jan. 12
tlyu at MIT.EDU
Mon Dec 29 00:13:38 EST 2008
Jeffrey Altman <jaltman at secure-endpoints.com> writes:
> Tom Yu wrote:
>> Greg Hudson <ghudson at MIT.EDU> writes:
>>> I have two comments:
>>> 1. I don't see why it is necessary to store and compare the full
>>> authenticator text. The consequences of a false hash collision are a
>>> false replay denial; but the odds of this happening by accident are
>>> vanishingly low, even if the hash function is insecure. (And if it
>>> happens on purpose, we don't care.)
>> This is a good point.
> The reason the full authenticator is being stored is not so that it can
> be compared today but so that it is available for alternate comparisons
> in the future.
> If you go back through the history of the replay cache discussions
> there were concerns that it might be possible to alter the binary
> authenticator by adjusting the asn.1 representation of the components.
I will try to dig up records of those discussions, but a pointer would
be helpful. Can this alteration be done by an attacker lacking
knowledge of the session key? I thought we made sure that any modern
Kerberos cryptosystem (not one of the single-DES ones...) would not be
vulnerable to such cryptographic attacks.
More information about the krbdev