Proposed modifications to replay cache to prevent false positives
hartmans at MIT.EDU
Thu Jun 2 15:37:13 EDT 2005
>>>>> "Ken" == Ken Raeburn <raeburn at MIT.EDU> writes:
Ken> 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.
Ken> I would assume we would only get to the replay cache code for
Ken> authenticators that were successfully decrypted. If two
Ken> authenticators had different ciphertext but identical
Ken> semantics in the ASN.1-encoded plaintext, do we care?
Ken> Presumably a legitimate client (defined as, "any party with
Ken> knowledge of the session key") generated both.
Here's an example of what I'm talking about. Change the encoding of
the enctype in the EncryptedData sequence to be non-minimal length.
AN attacker can do this to perform a replay.
More information about the krbdev