ietf-smime
[Top] [All Lists]

RE: weak authentication issue with rfc5083

2008-05-05 15:30:59
Trevor,

Essentially the same problem was commented upon in RFC 3278:

http://tools.ietf.org/html/rfc3278#section-4.1.2

but no solution was provided other than to use separate AuthenticatedData per 
recipient. There are some other possible solutions, however.

For example, in the case of Diffie-Hellman, the input into the KDF used to 
compute the KEK from the raw DH secret can be include the MAC tag, which 
prevents message substitution.  See Section 5 of 
http://eprint.iacr.org/2005/056 for more discussion.

Best regards,

                Dan

From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Trevor 
Freeman
Sent: Monday, May 05, 2008 3:52 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: weak authentication issue with rfc5083

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.