Projects/replay_cache_collision_avoidance and replay cache uses

[ghudson@MIT.EDU]

In the process of preparing to implement
Projects/replay_cache_collision_avoidance I noticed that we don't just
use the replay cache for received authenticators.  The full range of
uses are:

  * krb5_rd_req (the basic authenticator case)
  * krb5_mk_priv/krb5_rd_priv
  * krb5_mk_safe/krb5_rd_safe
  * verify_sam_response (KDC preauth)

(mk_priv and mk_safe store replay records presumably so that an
attacker cannot reflect messages back at the sender.)

First, mk_priv/rd_priv and mk_safe/rd_priv use an empty server name
for their replay records.  (KDC preauth uses a server name of
"SAM/rc".)  Therefore, using an empty server name to identify
extension records is not as robust as one might hope.  I will change
the proposal to use empty client names instead, with the extension
record value stored in the server name field instead of the client
name field.

Second, we have to decide what string to hash in each use case.  If
people would like to sanity check, my plan is:

  rd_req: Ciphertext of authenticator (as passed to krb5_c_decrypt)
  mk_priv/rd_priv: Ciphertext of message (as passed to krb5_c_decrypt)
  mk_safe/rd_safe: String against which checksum is computed (see below)
  verify_sam_response: sam_track_id field of response (as passed to
   krb5_c_decrypt)

For mk_safe/rd_safe, what our code does is encode the KRB_SAFE message
with a zeroed checksum, compute the checksum, and then re-encode the
message with the checksum set.  On the receiving end, the message is
decoded, re-encoded with a zeroed checksum, and the received checksum
is verified against the re-encoded message.  It's this
message-encoded-without-checksum string which should be hashed in the
replay record (even though that string never appears on the wire),
since that is what the attacker would have difficulty modifying
without invalidating the checksum.