Replay cache extension design issue

[ghudson@MIT.EDU]

Having just yesterday finished implementing the replay cache proposal,
I realized a design issue this morning.  Our expunge code neatly
reverses the orders of entries in the file; I've included some output
of a test utility at the end showing this.

When new code does an expunge, this is not a problem, since the
<extension record, regular record> pairs are read into a single
in-memory data structure.  But when old code does an expunge, the
extension records will be written out after the regular records they
apply to, instead of before.  When new code reads the expunged replay
cache, it will apply hash values to the wrong records, which has the
effect of allowing most replay attacks to succeed.  Obviously, this
needs to be fixed (or the implementation reverted) before 1.7 ships,
since it's a reduction in security.

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.

  equal-rites$ ./t_replay dump /var/tmp/test
  Lifespan: 300
  ---
  Client: firstclient
  Server: firstserver
  Microseconds: 0
  Timestamp: 1000
  ---
  Client: secondclient
  Server: secondserver
  Microseconds: 0
  Timestamp: 1001
  ---

  equal-rites$ ./t_replay expunge dfl:test 1002 0
  Cache successfully expunged

  equal-rites$ ./t_replay dump /var/tmp/test
  Lifespan: 300
  ---
  Client: secondclient
  Server: secondserver
  Microseconds: 0
  Timestamp: 1001
  ---
  Client: firstclient
  Server: firstserver
  Microseconds: 0
  Timestamp: 1000
  ---