Re: [jose] NIST Concat KDF

If implementing Concat is this much work, why not just use longer keys?

On Nov 7, 2012, at 8:18 PM, "Manger, James H" <James.H.Manger@team.telstra.com> wrote:

> JOSE is inching closer to properly using NIST 800-56A Concat key derivation function (KDF), but there is still a sizeable gap.
>  
> The latest changes (draft-ietf-jose-json-web-algorithms-07) add length prefixes to PartyUInfo and PartyVInfo.
> However, the AlgorithmID field doesn’t have a length prefix; nor does SuppPubInfo or SuppPrivInfo.
> The remaining ambiguity in the KDF input is less practical to exploit than the “JoBethAnne” example that was previously possible, but theoretical ambiguity remains. Can’t the spec just do what NIST 800-56A says if it really wants to use it?
>  
> Defining “apu” and “apv” to hold PartyUInfo and PartyVInfo values is only pretending to support NIST 800-56A. NIST 800-56A says they need to be mandatory (non-null) and they need to be explicitly checked by the recipient — not optional and blindly copied from apu/apv fields to the KDF input.
>  
> The AlgorithmID field is specified as indicating “how the derived keying material will be parsed and for which algorithm(s) the derived secret keying material will be used”. JOSE violates this. The same AlgorithmID value (eg “<00000100>A128CBC+HS256”) is sometimes used to derive a 128-bit AES key, and at other times used to derive a 256-bit HMAC key. The JOSE method is almost certainly “safe” as it uses different SuppPubInfo values (“Encryption” and “Integrity”) in these cases — but it is not NIST 800-56A Concat. A NIST 800-56A Concat approach would run the KDF once and get out a 384-bit secret that is split into the required 128-bit and 256-bit keys.
>  
> --
> James Manger
>  
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H
> Sent: Wednesday, 31 October 2012 12:13 AM
> To: jose@ietf.org
> Subject: [jose] NIST Concat KDF
>  
> JOSE still doesn’t use the NIST 800-56A Concat Key DF as that specification requires.
>  
> JWA allows PartyUInfo and/or PartyVInfo to be empty (if apu/apv/epu/epv are absent). That doesn’t comply with 800-56A that says “at a minimum, PartyUInfo shall include IDu, the identity of party U”. 800-56A also says “it is required that identifier for both parties to a key agreement transaction be included in the OtherInfo that is input to the key derivation function”.
>  
> 800-56A requires that the concatenation AlgorithmID || PartyUInfo || PartyVInfo be unambiguous. It allows two ways to achieve this: pre-define fixed sizes for components; or prefix each component with its length. JWA does neither of these.
>  
> Consider two JOSE messages (ignoring some irrelevant base64url encoding):
>   { ..., "apu":"JoBeth", "apv":"Anne" } and
>   { ..., "apu":"Jo", "apv":"BethAnne" }
> JWA implies both use the string "JoBethAnne" in the KDF despite the messages being between different parties, which defeats this part of the Concat KDF design.
>  
> JWA explicitly puts the key length and "alg" value into the AlgorithmID field that the KDF uses. However, the "alg" value alone must imply one specific key length for the rest of the JOSE processing to work so including the key length explicitly is redundant.
>  
> 800-56A is designed to derive integrity and encryption keys together. For instance, it says “AlgorithmID might indicate that bits 1-80 are to be used as an 80-bit HMAC key and that bits 81-208 are to be used as a 128-bit AES key”. JWA does not do this. JWA runs the KDF twice to derive integrity and encryption keys separately.
>  
> If we want to use NIST 800-56A Concat KDF then JWA/JWE needs lots of fixes.
> If we want a simpler KDF then JWA shouldn’t pretend it is the NIST 800-56A Concat KDF.
>  
> --
> James Manger
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose