summary of feedback on replay cache collision avoidance proposal
Tom Yu
tlyu at MIT.EDU
Tue Dec 30 18:23:00 EST 2008
I have revised the project proposal page
http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance
to reflect some feedback.
Items that we appear to agree on:
* Hashing authenticator ciphertext is not a problem and is possibly
even desirable.
* Retaining the entire authenticator (either clear or ciphertext)
provides no security advantages.
* Binary data in extension is subject to truncation at null bytes by
old implementations, so we should avoid that.
Remaining questions:
* Whether to use a hash algorithm identifier: Greg has some convincing
arguments that we should not use one and should not incur the
additional complexity of implementing hash agility.
* General form of the extension encoding. We don't have to exactly
specify how future extensions will work as long as we don't paint
ourselves into a corner. I have suggested one (non-binary)
alternative on the project proposal page. The extension for the
hash currently includes a hash algorithm identifier, but I am not
strongly attached to the idea.
--
Tom Yu
Development Manager
MIT Kerberos Consortium
More information about the krbdev
mailing list