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