Proposed modifications to replay cache to prevent false positives

[Ken Raeburn]

(Sorry, I guess I didn't actually *finish* this email and sent it  
off...)

> variable - authenticator-hash == base64-encoded hash string with NUL  
> terminator
Plaintext or encrypted version?

> krb5_uint32 - length == 1 or (strlen(base64-encoded cleartext  
> authenticator) + 1)
> variable - NUL or base64-encoded cleartext authenticator with NUL  
> terminator

Is the authenticator optional, or are there specific reasons why it  
should be present or absent?

Storing the full authenticator concerns me.  We're talking about much  
more than doubling the size of the replay cache data.  (The base64  
encoding will expand the principal name strings by a factor of 4/3 in  
the additional copy, and that's without the overhead of all the other  
stuff in the authenticator.  And really, do we need to cache the  
number 5, the application tag, etc?)  Without the authenticator, we're  
still doubling the number of records, but at least the new records are  
likely to be around the same size or smaller.

If we've got a good hash function or HMAC, the hash value should be  
enough.

I think we could improve the performance if we eventually transition  
to a state where usually (except in cases of mixed versions or  
configurations) the records in the file all have the same fairly small  
size.  Having a small set of values in the "server" field, like only  
server principal names and hash-type numbers, could also be a way to  
reduce memory use, if that turns out to be an issue.  But without  
numbers indicating that there are real problems, actually doing that  
may be premature...

> krb5_int32 - hash-type
> krb5_timestamp - 0

Won't an old server reading this decide that this entry has expired  
and can be purged if/when the replay cache gets rewritten?

Do the hash type number assignments match number assignments we use  
anywhere else, or is this a new list?

If the authenticator isn't stored, how does the code know when the  
entry can be discarded?

> This record would be followed by the existing record consisting of  
> the client and server principal names, the time stamp and the  
> microseconds value. A complete entry therefore takes up two existing  
> records.

How is the code expected to determine from the first record that it's  
the new style, and the second record follows?  By the 0 timestamp?

Will old servers preserve the ordering (and pairing) of records in the  
rcache file?  Are the two entries actually required to be paired up?

If you put the normal timestamp back and store the hash type some  
other way, can the two records be stored (and potentially moved around  
during file rewriting) independently?

Ken