Proposed modifications to replay cache to prevent false positives
Ken Raeburn
raeburn at MIT.EDU
Thu Jun 2 14:57:42 EDT 2005
On Jun 2, 2005, at 13:33, Sam Hartman wrote:
> Roland> 2. the hash should be performed on the authenticator
> Roland> prior to decryption so that the ticket used is implicitly
> Roland> part of the hashed data (since it's session key should be
> Roland> different than any other session key) and the
> Roland> authenticator's IV should eliminate the chance of false
> Roland> positives using the same ticket.
>
> I'm not at all sure about this. You need to make sure that there
> aren't changes to the ciphertext (for example padding, changing ASN.1
> wrappers) that can cause the hash to change but not change the
> underlying semantic content.
I would assume we would only get to the replay cache code for
authenticators that were successfully decrypted. If two authenticators
had different ciphertext but identical semantics in the ASN.1-encoded
plaintext, do we care? Presumably a legitimate client (defined as,
"any party with knowledge of the session key") generated both.
More information about the krbdev
mailing list