Subject: RE: Comments on smime-cms-07

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Tue, 10 Nov 1998 12:58:28 -0800

I remove those items with which I had no more problems.

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, November 10, 1998 12:41 PM
> To: Jim Schaad (Exchange)
> Cc: [email-masked]
> Subject: Re: Comments on smime-cms-07
> 
> 
> Jim:
>  
> 
> >3.  Section 9 - Authenticated-data Content Type:  I think I 
> have identified
> >what I consider to be a security weakness.  Specifically if 
> you create an
> >authenticated data object with authenticated attributes, I 
> can remove the
> >authenticated attributes and come up with a stil legal 
> authenticated data
> >object.  To fix this I propose that we change authenticated 
> data in the
> >following ways:
> >  a)  In AuthencatedData macAlgorithm be changed to hashAlgorithm.
> >  b) autenticatedAttributes becomes a REQUIRED field (remove 
> the OPTIONAL)
> >  c) a digest-value becomes a required attribute in the
> >autenticatedAttributes (replacing mac-value)
> >  d) in processing, you hash the encapContentInfo, put the has in the
> >authenticated attributes and MAC this value.
> 
> I understand your proposed change, but I do not understand 
> the "security
> weakness."  In CMS-07, two MAC values are computed.  The 
> first MAC value is
> computed from the content, then this MAC value is encoded in 
> an authenticated
> attribute.  The second MAC value is computed from the DER 
> encoded attributes. 
> The two MAC values should not be the same.  So, if the 
> attributes are removed
> by an attacker, the MAC value check should fail.
> 
> If you are concerned about an attacker who is a recipient, 
> and thus has the
> symmetic key needed to compute the MAC, then I do not think 
> that anything can
> be done to make authenticated-data secure.

What I am looking at is more of a man in the middle attack.  If I intercept
the message, I can modify it and then send on to the receiptient after
having removed all of the attributes.  Since I have removed all of the
attributes only one MAC computation would be computed and that is the same
MAC computation as was in the attributes as the macValue.

> 
> 
> >5.  Section 12.5.2.  DES MAC should be struck and replace 
> with 3DES MAC.
> 
> My notes from Chicago indicate that HMAC with SHA-1 and DES 
> MAC are the two
> algorithms that will be included.  As 12.5 says: "CMS 
> implementations that
> support authenticatedData must include HMAC with SHA-1.  CMS 
> implementations
> may also include DES MAC."

I'll believe your notes over my memory.  I had thought that DES MAC was
struck and replaced with 3DES MAC.

> Enjoy,
>   Russ

---

From: Francois Rousseau <[email-masked]>
Date: Wed, 11 Nov 1998 08:10:32 -0500

Russ,

Further to Jim's EMail and although I did not attend the meeting in
Chicago, the minutes of the meeting on this issue states that:

"Slide #9: Message Authentication Code (MAC) Algorithms:  The group decided
by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement
algorithm.  The wording in CMS will be: "If authenticatedData is
implemented, then HMAC-with-SHA1 must be implemented."  The group also
decided that DES MAC will not be included in CMS as an optional algorithm." 

As suggested by Jim, I would for myself prefer 3DES MAC as a "may" instead
of DES MAC. 

Francois Rousseau
AEPOS Technologies

<snip>

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Nov 1998 15:49:16 -0500

Francois:

I guess that I should remove DES MAC.

I do not know of any reference fro 3DES MAC.

Russ

---

From: Francois Rousseau <[email-masked]>
Date: Fri, 13 Nov 1998 12:02:34 -0500

Russ,

The only reference I know for 3DES MAC is from Section 8.5 of PKCS#11 on
"Data Types for Mechanisms" where it is included in the list of mechanism
types that could be supported by a token as follow:

 For Cryptoki Version 2.01, the following mechanism types are defined:

 #define CKM_DES3_MAC                   0x00000134
 #define CKM_DES3_MAC_GENERAL           0x00000135

Francois Rousseau
AEPOS Technologies

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Nov 1998 17:43:46 -0500

>MAC computation as was in the attributes as the macValue.

Are yo saying that the attacker can take the value from the attribute and
place it in the authenticated-data macValue?  The value in the attribute is
exactly the one needed if there were no attributes present.  You are
correct, this is a problem.

Rick Ankney, are you out there?  Would your customers accept a hash of the
content in the attributes?

Russ