Hi James, I appreciate that you are reading and providing detailed feedback on the text of the drafts. As I’m sure you saw, many of the changes made between the -06 and -07 drafts were to address comments that you had made. I’ll try to address the details of your comments below in this note. By adding the length prefix to the PartyUInfo and PartyVInfo values, I fail to see how the JoBethAnne ambiguity could remain possible. I addressed that per your earlier note in the -07 drafts by adding the length prefix. You wrote that the AlgorithmID doesn’t have a length prefix. That’s true. The Concat definition allows fields to not contain a length prefix when they are fixed length, as AlgorithmID is in this case. Likewise, there’s no need for a length prefix for SuppPubInfo or SuppPrivInfo, as they are also fixed length (0) in our use for key agreement. Similarly, the use of SuppPrivInfo by A128CBC+HS256 and A256CBC+HS512 effectively makes them fixed length strings, as only two values are possible, “Encryption” and “Integrity”, with no confusion possible between them. What’s more, they occur at the end of the concatenation. You wrote “Can’t the spec just do what NIST 800-56A says if it really wants to use it?”. I suspect that underlying this comment is the actual difference you have with the specs’ use of Concat. It’s not a goal of JWA to make it possible to use every feature of Concat. (Concat isn’t an end unto itself.) Hence the spec not needing to use SuppPrivInfo, etc. The actual goal is generating two high-quality keys from the CMK. I believe that this goal has already been attained. As for whether we use Concat twice to generate two keys with different inputs and then discard the random value or whether we use Concat once to generate a long enough output to chop it into two keys, that seems like a distinction without a difference. I reviewed this decision with Jim Schaad a while back, among others, and they concurred. The precedent for this is the TLS PRF KDF [RFC5246], which generates keys in this manner. Unless there’s an actual security argument that this (widely used) practice is demonstrably unsafe, there doesn’t seem to be a reason to change. As for requiring PartyUInfo and PartyVInfo values for key agreement, the actual need for these parameters is context-dependent. I’m perfectly fine putting a statement in our specs that NIST’s specification for the KDF requires these values to be present and checked, if that would make you happier. That way, per my earlier conversation with Jim about this topic, applications of JWE can choose to use the KDF in a fully NIST-compliant fashion, if appropriate. But for the same reasons that the TLS PRF KDF doesn’t need these parameters, in practice they’re not needed in some JWA contexts either. I’m trying to have us not lose sight of the fact that a core goal of the JOSE specs is to create specs that are simple enough that they will actually be implemented and used. And yes, of course they need to be secure. I believe we’re already there with the current specs. Whereas, for instance, adding optional SuppPrivInfo parameters just because NIST says that you *can* use them would seem to be adding implementation complexity with no actual security benefit. Best wishes, -- Mike From: [email protected] To: [email protected] Date: Thu, 8 Nov 2012 12:18:58 +1100 Subject: Re: [jose] NIST Concat KDF
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
