review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Tom Yu]

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.