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

["Peck, Michael A" <[e-mail]>]

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]<mailto:[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]> [mailto:[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]<mailto:[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 <[e-mail]<mailto:[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 ofhttp://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 )  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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jose



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