review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> On Mon, 2008-12-29 at 00:13 -0500, Tom Yu wrote:
    >> I will try to dig up records of those discussions, but a
    >> pointer would be helpful.

    Greg> I found:

    Greg> http://mailman.mit.edu/pipermail/krbdev/2005-May/003444.html
    Greg> http://mailman.mit.edu/pipermail/krbdev/2005-June/003455.html

    Greg> These posts from Sam are particularly relevant:

    Greg> http://mailman.mit.edu/pipermail/krbdev/2005-June/003457.html
    Greg> http://mailman.mit.edu/pipermail/krbdev/2005-June/003464.html

    Greg> The conversation picks up again in 2008:

    Greg> http://mailman.mit.edu/pipermail/krbdev/2008-May/006601.html

    Greg> I'm not finding any piece of discussion specifically
    Greg> connecting the dots between "maybe an attacker can perturb
    Greg> the authenticator a little bit and change its hash without
    Greg> invalidating it" and "we should store the authenticator".
    Greg> In fact, Sam seemed to be arguing simply for hashing the
    Greg> decrypted authenticator rather than its encrypted form.


I think it is sufficient from a security standpoint.  I'm not sure
that two authenticators will differ in their decrypted form if they
are produced by the same client at the same time using the same
session key and no subsession key.

However please see the thread from July 2008 on ietf-krb-wg titled
"Replays and ciphertext Comparison."  In that thread Ken and I discuss
whether RFC 3961 gives you strong enough guarantees that changes to
the ciphertext will be detected.

Quoting Ken:

    Ken> On Jul 10, 2008, at 13:59, Sam Hartman wrote:
    >> However, I don't think that this is guaranteed to be safe.
    >> Consider for example an encryption system based on CBC that
    >> stores length information about the message so that the
    >> application does not need to do so.  Also, assume that the
    >> encryption system MACs the plaintext not the ciphertext.
    >> 
    >> An attacker could change final padding with this encryption
    >> system, changing the ciphertext, but not the plaintext.

    Ken> The specification of the decrypt function in 3961 says,
    Ken> "verifies the integrity of the supplied ciphertext".  That
    Ken> suggests that changing the ciphertext, even if the only
    Ken> effect in decrypting is to alter some padding bytes added on
    Ken> the end of the encoded ASN.1 message or other blob, should be
    Ken> detected and treated as an error.


While I didn't read RFC 3961 that way originally, I find Ken's reading
compelling.  I believe that current Kerberos crypto systems meet that
invarient.


So, I believe storing a hash of the encrypted text is appropriate and
sufficient.