Proposed modifications to replay cache to prevent false positives

[Sam Hartman]

>>>>> "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.