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