RE: weak authentication issue with rfc5083

[Trevor Freeman <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

I should have use MAC to be more accurate.

5083 generates a MAC using the message contents and the CEK.

If there are multiple recipients - all know the CEK so any can generate new messages with the same CEK. So you only can presume the message is from one of the group who know the CEK but you don't know which one.

You could have used a pair wise shared secret to protect the CEK but 5083 does not define how to use the pair wise shared secret to also authenticate the sender. If the sender encrypted the MAC using the KEK and attached that to the message as an unauthenticated attribute the receiver can authenticate the sender.

-----Original Message-----
From: pgut001 [mailto:pgut001@xxxxxxxxxxxxxxxxx]
Sent: Monday, May 05, 2008 11:47 PM
To: ietf-smime@xxxxxxx; Trevor Freeman
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.