Replay cache extension design issue

Nicolas Williams Nicolas.Williams at sun.com
Tue Jan 13 13:29:27 EST 2009


On Tue, Jan 13, 2009 at 01:20:05PM -0500, Jeffrey Hutzelman wrote:
> --On Tuesday, January 13, 2009 12:20:38 PM -0500 Greg Hudson 
> <ghudson at MIT.EDU> wrote:
> 
> > On Tue, 2009-01-13 at 11:58 -0500, ghudson at MIT.EDU wrote:
> >> My first idea for a band-aid is to make the extension records include
> >> the client and server principle strings, so that they stand alone
> >> (superceding, rather than augmenting, the old-style records which are
> >> also written out).  Of course, that requires cramming the client
> >> principal string, server principal string, and hash string into the
> >> server principal field of a record.  Maybe someone else has a more
> >> elegant idea.
> >
> > Tom had the interesting idea of writing out triplets:
> >
> >   extension record containing hash
> >   old-style record
> >   extension record containing hash
> >
> > That's resistant to precise reversal (which is what our code does),
> > though not to arbitrary reordering.
> 
> Perhaps, but do you want to write _every_ extension record in duplicate?

Also, there's no guarantee that other implementations don't merely
reverse, but re-order the rcache in other ways on expunge.



More information about the krbdev mailing list