Subject: [Ietf-krb-wg] Replays and ciphertext comparison

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Jul 2008 13:59:09 -0400

We've often discussed the desire to do replay detection that is better
than just looking at the timestamp and storing that in the replay
cache.  One attractive option is to store a hash of the ciphertext of
an authenticator in the replay cache.

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.

I believe this type of encryption system is consistent with the
requirements of RFC 3961 provided that an attacker cannot modify the
plaintext.

--Sam
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jul 2008 13:05:37 -0500

On Thu, Jul 10, 2008 at 01:59:09PM -0400, Sam Hartman wrote:
> However, I don't think that this is guaranteed to be safe.  [...]

An alternative then is to use a hash of the plaintext of the
Authenticator.  If there's a randomly-generated sub-session key then
you're set.  But if there's not a sub-session key then the confounder
used in the ciphertext would have helped, but not using the ciphertext
precludes the ability to use the confounder (which, in any case, need
not be available as future enctypes might not use confounders).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Jul 2008 14:18:45 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Jul 10, 2008 at 01:59:09PM -0400, Sam Hartman
    Nicolas> wrote:
    >> We've often discussed the desire to do replay detection that is
    >> better than just looking at the timestamp and storing that in
    >> the replay cache.  One attractive option is to store a hash of
    >> the ciphertext of an authenticator in the replay cache.
    >> 

    Nicolas> An alternative then is to use a hash of the plaintext of
    Nicolas> the Authenticator.  If there's a randomly-generated
    Nicolas> sub-session key then you're set.  But if there's not a
    Nicolas> sub-session key then the confounder used in the
    Nicolas> ciphertext would have helped, but not using the
    Nicolas> ciphertext precludes the ability to use the confounder
    Nicolas> (which, in any case, need not be available as future
    Nicolas> enctypes might not use confounders).

Unfortunately, a server cannot guarantee that a client will use a
sub-session key.  If I were implementing this today I'd probably use
ciphertext and stick a big note about the assumption in a comment near
my enctype table.
If I ever added an enctype where this was an issue, I'd do something.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jul 2008 13:22:59 -0500

> If I ever added an enctype where this was an issue, I'd do something.

That seems reasonable enough.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 10 Jul 2008 16:18:00 -0400

> changing the ciphertext, but not the plaintext.

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

Whether the real-world algorithms deployed currently actually work  
that way may be another matter...

Ken

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Jul 2008 16:20:59 -0400

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    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.

Hmm.
I didn't interpret it that way, although I think I like the interpretation:-)