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

[Mike Jones <[e-mail]>]

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]<mailto:[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