Subject: [AAA-WG]: CMS Security Encryption

From: Don Zick <[email-masked]>
Date: Wed, 14 Nov 2001 12:11:50 -0500

Hi Stephen or Pat,

The CMS Security draft states that 3DES is used for symmetric
encryption.  Is it the same type of 3DES that is used with TLS? TLS uses
3DES_EDE_CBC (3DES, Encrypt-Decrypt-Encrypt mode with cipher block
chaining).

Thanks,
Don Z.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2001 10:40:29 +0000

Hi Don,

I guess we probably should be more specific about this bit of text. How 
about changing 3.3 to:

"3.3  Algorithms

   For all uses of CMS in this specification the mandatory to implement
   algorithms are as follows:

      - Hashing: 
              sha-1 (see [3] section 12.1.1)
      - Signature (the hash algorithm is specified separately):
              rsaEncryption (see [3] section 12.2.2)
      - Content Encryption: 
              des-ede3-cbc (see [3] section 12.4.1)
      - Asymmetric key transport: 
              rsaEncryption (see [3] 12.3.2.1)
      - Symmetric key encryption (only needed in conjunction with [15]):
              id-alg-CMS3DESwrap (see [3] section 12.3.3.1)

   At some point in future, AES will replace 3DES."

Where [3] references cms (rfc2630) and [15] references rcek (rfc3185).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Don Zick <[email-masked]>
Date: Thu, 15 Nov 2001 12:06:40 -0500

Hi Stephen,

I like your proposed clarifications, but now I have another question.

Is support for id-alg-CMS3DESwrap optional?

Is reuse of CMS content encryption keys mandatory?  In section 3.4 of the
CMS Security Application draft it says that Diameter nodes MUST be able to
support a  maxDecrypts setting of 1000.  In an earlier email thread I thought
it was stated that CMS content encryption key usage was not mandatory as some
toolkits don't support it.

Thanks,
Don Z.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2001 17:41:25 +0000

Don,

Content key re-use is definitely a MAY. If you do implement it then 
those MUST's apply, but if you don't they don't. I thought this was 
clear from the document, but on 2nd glance its not really so how about 
changing:

"3.4 Reuse of CMS Content Encryption Keys

   Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter
   peers, ..."

to 

"3.4 Reuse of CMS Content Encryption Keys

   This section describes an efficiency improvement which MAY be supported
   by Diameter nodes. If a node doesn't support this feature, then it MUST 
   (and naturally will), treat all packets with re-used content encryption 
   keys as a cryptographic failure. The originating node MAY then attempt 
   to re-send the packets using asymmetric key transport. If a node does 
   support this feature, then the MUST/SHOULD statements in this section 
   apply, otherwise not. 

   Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter
   peers, ..."

Stephen.

---

From: Don Zick <[email-masked]>
Date: Thu, 15 Nov 2001 12:58:47 -0500

Hi Stephen,

That clears it up for me.

Thanks,
Don