If implementing Concat is this much work, why not just use longer keys? On Nov 7, 2012, at 8:18 PM, "Manger, James H" <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of > Manger, James H > Sent: Wednesday, 31 October 2012 12:13 AM > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
