Peter,
I believe you have misunderstood the issue that Trevor raised.
His problem is:
1. I send you and him a single Authenticated Message.
2. He takes the common CEK in the original message, uses it to create a MAC
on an new message and then sends it on to you.
As is always true with Authenticated messages, there is no proof of origin.
He worries that you might be confused and believe the second messages was
from me rather than from him. Since they both use the same CEK that is not
a factor that could be used to distinguish them.
Jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Peter Gutmann
Sent: Monday, May 05, 2008 11:47 PM
To: ietf-smime(_at_)imc(_dot_)org;
trevorf(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com
Subject: Re: weak authentication issue with rfc5083
Trevor Freeman <trevorf(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com> writes:
However when the integrity of the message is validated via the message
HMAC,
the sender only demonstrates knowledge of the CEK to the recipient.
Any other recipient knows the CEK so can construct another message
using the
same CEK and compute the new HMAC and reuse the encrypted KEK data
from the
original message. For example:
Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC
if
required (the other use is with a combined MAC+encrypt mode), but in
the HMAC
usage the HMAC and CEK keys are derived from a single key using a PRF,
so
knowledge of the CEK doesn't give you the HMAC key, and vice versa. It
was
specifically designed that way to prevent rollbacks where you strip off
the
MAC and rewrite it as plain encrypted data. Or have I misunderstood
your
point?
Peter.