Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

["Jim Schaad" <[e-mail]>]

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Manger, James H
Sent: Tuesday, March 12, 2013 8:59 PM
To: Mike Jones; Peck, Michael A; John Bradley
Cc: Richard Barnes; [e-mail]
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

 

+1 for using the McGrew draft and RFC 5116 interface.

 

The JOSE-specific A128CBC+HS256 algorithm looks like a valiant attempt to hide some of the binary processing involved with crypto – which has always been defined on bytes, not text. But the result is a poor chimera.

 

For instance, JWE includes the IV as part of the additional authenticated data (AAD). No other AEAD system is defined like this. Everywhere else the IV/nonce and AAD are separate. I hope that doesn’t adversely affect the crypto properties, but it does raise questions about whether it is important for some crypto reason.

 

[JLS] For this algorithm it is absolutely vital that the IV be protected.  Since the authentication is computed on the post encrypted text not the pre-encyrpted text, a decryption could never be able to correctly determine that the IV passed in was correct if it is not validated!!!!!!

 

Every AEAD algorithm treats the AAD and ciphertext as bytes arrays with no restrictions on their content (only restrictions on their length). Hence they use some binary packing when processing both to calculate an integrity check. EXCEPT the JOSE-specific AEAD algorithms (A128CBC+HS256 and A256CBC+HS512). They force base64url-encoding *inside* the AEAD algorithm so they can use a text dot “.” as a separator.

 

While A128CBC+HS256 is implemented by hand in JOSE-specific code using AES and HMAC primitives the problems with this chimera are mainly hidden. However, I don’t believe any generic AEAD interface can ever handle this JOSE-specific algorithm efficiently.

 

The “extra work” of adopting the AEAD encoding/decoding conventions is: concatenating byte arrays; and taking a known-length prefix and suffix from a byte array. You cannot get much simpler. It can only be an annoyance for a language that is not byte-array-friendly, but even such a language will have to handle byte arrays at some point to interface with crypto.

 

Even using the McGrew draft then separating the output into IV/ciphertext/MAC to re-package as a JOSE message would be better than the JOSE-specific A128CBC+HS256 and A256CBC+HS512.

 

P.S. I think ECMAScript edition 6 is introducing support for byte arrays so even hassle handling bytes in JavaScript should fade.

 

--

James Manger

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Wednesday, 13 March 2013 8:06 AM
To: Peck, Michael A; John Bradley
Cc: Richard Barnes; [e-mail]
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

 

Possibly using the McGrew draft had been discussed before, but there was strong push-back on it.  It would change more than the CBC/HMAC representation – it would change all the JWE representations, as it would remove the Initialization Vector and Integrity Value fields, and instead require all implementations to implement and apply the AEAD binary encoding and decoding conventions.  Note that this would change AES-GCM too – not just AES-CBC/HMAC.

 

If commonly available crypto libraries implemented algorithms using the AEAD encoding conventions I would have no problem with this.  But in fact, they don’t.  I don’t know of a single library in the attached set of surveyed implementations that do.  Thus, adopting the AEAD encoding/decoding conventions would create extra work for all implementations in practice – not make things simpler.  It would only be simpler if the existing crypto libraries implemented this standard interface.

 

We should therefore steer clear of this.

 

                                                            Best wishes,

                                                            -- Mike

 

P.S.  Jim Schaad also points out that CMS doesn’t use the RFC 5116 interface either.

 

From: Peck, Michael A [mailto:[e-mail]] 
Sent: Tuesday, March 12, 2013 2:02 PM
To: John Bradley; Mike Jones
Cc: Richard Barnes; [e-mail]
Subject: RE: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

 

I think that #2 actually reduces complexity for implementers.

They can implement the RFC 5116 interface once (or eventually just invoke a crypto library that implements it for them) – then use that implementation for all protocols that use the RFC 5116 interface, not just JOSE, and know that the details of authenticated encryption have been taken care of. 

 

Mike

 

 

From: John Bradley [mailto:[e-mail]] 
Sent: Tuesday, March 12, 2013 4:49 PM
To: Mike Jones
Cc: Richard Barnes; Peck, Michael A; [e-mail]
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

 

Yes I have the recommendation to change from using a KDF to generate the CEK and CIK from the CMK to concatenating the CEK and CIK together as in the McGrew draft.

 

I don't yet have a slide on the new/old issue of concatenating the tag to the message body vs sending it in a separate field.   

 

If people want me to I can add it as well.  Though I thought that was a closed issue.  

 

John B.

 

On 2013-03-12, at 4:19 PM, Mike Jones <[e-mail]> wrote:

 

As previously extensively discussed, the McGrew draft does two things – one helpful and one not:

 

1.  It specifies using a key that is actually the concatenation of an AES-CBC key and an HMAC SHA-2 key, rather than use of a KDF.  That’s good, as it’s simple for implementers.

 

2.  It specifies that the initialization vector and integrity value be concatenated with other values in particular ways, and conversely, how to extract them when decrypting.  That’s not good, as it adds complexity for implementers – especially when JWEs already utilize a straightforward representation for these values, which doesn’t require the binary concatenation and extraction conventions specified by McGrew.

 

I know that John Bradley is going to ask the question tomorrow whether we should change to doing the first for our composite CBC+HMAC algorithms.  I believe that doing the second would be counterproductive.

 

                                                            -- Mike

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 1:00 PM
To: Peck, Michael A
Cc: [e-mail]
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

 

Actually, for everything but key agreement, we can just use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys.  We should not be specifying key expansion here when we can avoid it.

 

--Richard

 

 

On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A < <mailto:[e-mail]> [e-mail]> wrote:

draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use of Concat KDF on the shared secret Z established by ECDH-ES.

 

The draft allows for an empty PartyUInfo and PartyVInfo but that may not be allowed by NIST SP 800-56A (where the Concat KDF is defined).

The current (March 2007) version of NIST SP 800-56A requires “At a minimum, PartyUInfo shall include IDU, the identifier of party U.” and an equivalent requirement for PartyVInfo. (Page 46 of <http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf> http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf )

The August 2012 draft update to NIST SP 800-56A requires “At a minimum, PartyUInfo shall include IDu, an identifier for party U, as a distinct item of information.” and an equivalent requirement for PartyVInfo. (Page 59 of  <http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf> http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf )  My interpretation of this text (others may interpret it differently) is that PartyUInfo and PartyVInfo can’t be empty.

 

Instead of using the Concat KDF, a more appropriate choice may be the KDF described in NIST SP 800-56C and RFC 5869.

Its requirements are not as strict.  (SP 800-56C Page 13: “If the information is available, Context should include the identifiers of the parties who are deriving and/or using the derived keying material”)

 

It would look something like this:

 

Step 1 - Randomness Extraction:

Key Derivation Key := HMAC(salt, Z)         (HMAC-SHA256 should suffice for all of the current algorithms)

 

Step 2 - Expansion Step:

Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 with the same HMAC algorithm used in step 1 to produce needed keys from the Key Derivation Key produced in step 1.

The needed keys would depend on the values of alg and enc.

If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit key is needed (used to decrypt the CMK, which may then need to be split into CEK/CIK).

If alg is ECDH-ES, then the needed keys depend on “enc”:

If enc is AES-GCM, a 128 bit key or 256 bit key is needed.

If enc is one of the AEAD AES-CBC algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN is needed as it’s then split into two by the AEAD algorithm.

If enc is one of the current CBC+HMAC options in draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK and a CIK.  Counter Mode KDF could be invoked twice, with different labels each time, or Counter Mode KDF could be invoked once to generate a big key which would then be split into the CEK and CIK.

 

Richard has already pointed out the issues with using the Concat KDF to derive the CEK/CIK from the CMK.  Instead, one option would be to use the Expansion Step above:  use the Counter Mode KDF with an HMAC to derive necessary keys from the CMK. 

Even if we use encryption algorithms that combine the encryption and integrity key such as the CBC+HMAC algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to take a smaller master key and create the combined encryption + integrity key from it.

 

 

Mike

 


_______________________________________________
jose mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/jose> https://www.ietf.org/mailman/listinfo/jose

 

_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose