Proposed modifications to replay cache to prevent false positives
raeburn at MIT.EDU
Tue May 20 15:30:53 EDT 2008
(Sorry, I guess I didn't actually *finish* this email and sent it
> variable - authenticator-hash == base64-encoded hash string with NUL
Plaintext or encrypted version?
> krb5_uint32 - length == 1 or (strlen(base64-encoded cleartext
> authenticator) + 1)
> variable - NUL or base64-encoded cleartext authenticator with NUL
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
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
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?
More information about the krbdev