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.
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
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
the sender only demonstrates knowledge of the CEK to the recipient.
Any other recipient knows the CEK so can construct another message
same CEK and compute the new HMAC and reuse the encrypted KEK data
original message. For example:
Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC
required (the other use is with a combined MAC+encrypt mode), but in
usage the HMAC and CEK keys are derived from a single key using a PRF,
knowledge of the CEK doesn't give you the HMAC key, and vice versa. It
specifically designed that way to prevent rollbacks where you strip off
MAC and rewrite it as plain encrypted data. Or have I misunderstood