|
The downside of this would be
that you could no longer do one pass encoding. You would need to compute the HMAC
prior to computing the recipient infos. Jim From: Trevor Freeman
[mailto:trevorf@xxxxxxxxxxxxxxxxxxxxxx] Another suggestion is to use the
kek to wrap the hmac just like you wrapped the CEK. From:
owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx] On
Behalf Of Trevor Freeman Hi Jim, You can demonstrate knowledge of
both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK
with the message HMAC and hashing the result. Since Mallet does not know the
KEK they cannot compute the new hash. This fix works for both 3852 and 5083. Trevor From: Jim Schaad
[mailto:ietf@xxxxxxxxxxxxxxxxx] Trevor, The same issue also occurs for
AuthenticatedData in RFC 3852. This has been known for a long time. I am not sure how a
demonstration of the KEK would solve this issue however. The only way
that I know to actually deal with this problem is to place the computed MAC
under encryption for each recipient. Jim From:
owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx] On
Behalf Of Trevor Freeman We have identified a potential for spoofing when using
rfc5083. Rfc5083 computes a message HMAC over the content using the
authenticated encryption algorithms. The message HMAC is calculated based on
the content and the content encryption key (CEK). A number of allowed key management techniques derive a key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. The KEK
is used to encrypt the CEK per recipient. 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: Alice
sends a message to Bob and Mallet. Alice uses different KEK’s for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using his
KEK. The message decrypts and the HMAC checks out so Bob think the message is
from Alice because only Bob and Alice know the KEK. Mallet
is the recipient of the original message so he can use his KEK to learn the
message CEK. Mallet then constructs a new message and encrypts it using the
same CEK as the original message. Mallet copies Bobs KEK recipient Info
from Alice's message which contains the same encrypted CEK. Because Mallet
knows the CEK he can also compute the correct HMAC for the new message. Mallet
sends the new message to Bob. Bob again uses his KEK to discover the CEK and
successfully decrypts the message and the HMAC check out so Bob thinks this new
message is also from Alice. This
issue only applies when there are multiple recipients. The motivation to use
the new authenticated encryption is to improve performance so solutions like
bifurcating messages to use different CEK or signing the message are
counterproductive. We need an additional structure to allow the sender to
demonstrate knowledge of both the KEK and CEK per recipient when sending to
multiple recipients. What is the consensus to resolve this? We can version 5083 to document the new structure or we can
do document the new structure via a standalone document. |