Subject: Re: [jose] #28: AES-GCM should not be allowed for content encryption in combination with Direct Encryption key management mode

From: "jose issue tracker" <[email-masked]>
Date: Thu, 25 Jul 2013 10:25:24 -0000

#28: AES-GCM should not be allowed for content encryption in combination with
Direct Encryption key management mode

Comment (by [email-masked]):

 The security consideration also needs to address the AES-GCM key wrap
 algorithm as well as direct keying of the content encryption algorithm.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  [email-masked]        |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  algorithms             |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/jose/trac/ticket/28#comment:2>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Tue, 30 Jul 2013 10:23:13 -0000

Comment (by [email-masked]):

 The NIST security considerations were added in draft -13 in a manner that
 applies to both content encryption with GCM and key encryption with GCM.
 Therefore, I believe that this issue should be closed as Fixed.

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/28#comment:3>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Thu, 01 Aug 2013 01:22:46 -0000

Comment (by [email-masked]):

 Thank you for adding the security considerations text.  However, I don't
 believe it is sufficient, as I don't think it is practical to expect
 implementations to be able to keep track of how many times the pre-shared
 key has been used.  When possible, cryptographic standards should be
 designed in a way that resists easy misuse / misimplementation.  For GCM
 key wrap, the potential consequences seem especially bad since it is keys
 that are being encrypted.

 BCP 107 / RFC 4107 Section 2.1 states that "Automated key management MUST
 be used" when "Any stream cipher...is used."  Section 2.2 states that "The
 burden of demonstrating that manual key management is appropriate falls to
 the proponents -- and it is a fairly high hurdle."

 Existing RFCs that specify use of GCM in Internet protocols require
 automated key management.
 GCM in CMS (RFC 5084) uses a fresh content encryption key for each CMS
 message.
 GCM in IPsec ESP (RFC 4106) states (Section 2) that "implementations MUST
 use an automated key management system, such as the Internet Key Exchange"
 rather than allowing use of statically configured keys.

 I suggest the following changes:

 Prohibit use of GCM content encryption algorithms in combination with the
 Direct Encryption key management mode (when the value of "alg" is "dir").
 There are other content encryption algorithms that are less risky in this
 case.

 As there appears to be a use case for AES-GCM Key Wrapping, we should
 explore options to ensure that a new key is used for each AES-GCM Key Wrap
 operation.  For example, run the pre-shared key through the Counter Mode
 KDF (NIST SP 800-108 Section 5.1) to get the AES-GCM Key Wrap Key -- the
 KDF could mix in information like algorithm identifiers (might help
 prevent the issue James Manger pointed out of mixing up AES-GCM Content
 Encryption with AES-GCM Key Wrap, though I still think direct encryption
 should be prohibited with AES-GCM Content Encryption) and a sender-
 provided random value (to make sure a new key is used each time).  Section
 2 of SP 800-108 says its KDFs can be used for this use case (to derive
 keys from a pre-shared key).

Ticket URL: <https://trac.tools.ietf.org/wg/jose/trac/ticket/28#comment:4>
jose <http://tools.ietf.org/jose/>