RE: weak authentication issue with rfc5083

["Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxx [mailto:owner-ietf-
> smime@xxxxxxxxxxxx] On Behalf Of Peter Gutmann
> Sent: Monday, May 05, 2008 11:47 PM
> To: ietf-smime@xxxxxxx; trevorf@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: weak authentication issue with rfc5083
> 
> 
> Trevor Freeman <trevorf@xxxxxxxxxxxxxxxxxxxxxx> 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.