ietf-smime
[Top] [All Lists]

RE: weak authentication issue with rfc5083

2008-05-05 15:53:16
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(_at_)exchange(_dot_)microsoft(_dot_)com] 
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; ietf-smime(_at_)imc(_dot_)org
Subject: RE: weak authentication issue with rfc5083

 

Another suggestion is to use the kek to wrap the hmac just like you wrapped
the CEK.

 

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 1:40 PM
To: Jim Schaad; ietf-smime(_at_)imc(_dot_)org
Subject: RE: weak authentication issue with rfc5083

 

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(_at_)augustcellars(_dot_)com] 
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; ietf-smime(_at_)imc(_dot_)org
Subject: RE: weak authentication issue with rfc5083

 

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(_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 12: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.