review of Projects/replay_cache_collision_avoidance, ending Jan. 12
hartmans at MIT.EDU
Mon Dec 29 07:33:10 EST 2008
>>>>> "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> These posts from Sam are particularly relevant:
Greg> The conversation picks up again in 2008:
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.
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
So, I believe storing a hash of the encrypted text is appropriate and
More information about the krbdev