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 <mpeck@mitre.org> 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 *ID**U*, 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)
> ****
>
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>