Don't think that quite answers the mail. The algorithm text is correct. However, SP800-56A still says that both PartyUInfo and PartyVInfo MUST NOT be empty. So setting them to zero-length octet strings is non-compliant. There needs to be something there in any case. And this still seems abusive of SP800-56A.
I also think your assertion that Concat is a "widely supported KDF" is rather thinly supported. IIRC, your algorithm support spreadsheet from earlier showed that BCryptDeriveKey was the *only* known implementation of Concat. StackOverflow seems to agree, and NIST has a special "800-56A EXCEPT KDF" category because that's apparently what everything does. < http://stackoverflow.com/questions/10879658/existing-implementations-for-nist-sp-800-56a-concatenation-key-derivation-functi > <http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.html > So I don't think support is really a reason to prefer Concat. Pretty much everyone is going to have to implement either KDF from scratch anyway (using concatenation and a hash function), so we might as well choose one that (1) has some history in the IETF (so there's at least some code in CMS libraries), and (2) doesn't have to be used with inappropriate semantics. --Richard On Fri, Jun 21, 2013 at 8:45 PM, Mike Jones <[email protected]>wrote: > I agree with James' conclusion that the -11 use of the Concat KDF > doesn't conform to SP 800-56A because it doesn't support the PartyVInfo > parameter. I believe that DISCUSS comments will result if we don't enable > conforming uses of Concat. Therefore, I propose to make these specific > changes relative to -11.**** > > ** ** > > 1. Revert the PartyUInfo and PartyVInfo language to the -10 text, which > was:**** > > PartyUInfo**** > > The PartyUInfo value is of the form Datalen || Data, where Data is a > variable-length string of zero or more octets, and Datalen is a > fixed-length, big endian 32 bit counter that indicates the length (in > octets) of Data, with || being concatenation. If an apu (agreement > PartyUInfo) header parameter is present, Data is set to the result of > base64url decoding the apu value and Datalen is set to the number of > octets in Data. Otherwise, Datalen is set to 0 and Data is set to the empty > octet sequence. **** > > PartyVInfo**** > > The PartyVInfo value is of the form Datalen || Data, where Data is a > variable-length string of zero or more octets, and Datalen is a > fixed-length, big endian 32 bit counter that indicates the length (in > octets) of Data, with || being concatenation. If an apv (agreement > PartyVInfo) header parameter is present, Data is set to the result of > base64url decoding the apv value and Datalen is set to the number of > octets in Data. Otherwise, Datalen is set to 0 and Data is set to the empty > octet sequence. **** > > ** ** > > 2. Change the AlgorithmID language to:**** > > AlgorithmID**** > > This is set to the octets of the UTF-8 representation of the alg header > parameter value when in the Key Agreement with Key Wrapping mode and to > the octets of the UTF-8 representation of the enc header parameter value > when in the Direct Key Agreement mode.**** > > ** ** > > 3. Attempting to accommodate what I believe are Jim’s and Richard’s > desire to align with CMS’s key derivation practices, I would add the > following paragraph:**** > > ** ** > > The Diffie-Hellman Key Agreement Method [RFC 2631] uses a key derivation > function similar to the Concat KDF, but with fewer parameters. Rather than > having separate PartyUInfo and PartyVInfo parameters, it uses a single > PartyAInfo parameter, which is a random string provided by the sender, that > contains 512 bits of information, when provided. It has no suppPrivInfo > parameter. Key agreement can be performed in a manner akin to RFC 2631 by > using the PartyAInfo value as the “apu” (Agreement PartyUInfo) header > parameter value, when provided, and by using no “apv” (Agreement > PartyVInfo) header parameter.**** > > ** ** > > Will those changes, collectively, satisfy all those who have been > commenting on this thread? If they will not, please supply specific > alternative text. Jim, Russ, James, and Richard – what say ye?**** > > ** ** > > -- Mike*** > * > > ** ** > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Mike Jones > Sent: Friday, June 21, 2013 4:22 PM > To: Manger, James H; Richard Barnes; Jim Schaad > Cc: [email protected] > Subject: Re: [jose] Concat KDF > > ** ** > > Thanks for the suggestion of using the RFC 5008 KDF. I did some research > into this, hoping to find that it was equivalent to the Concat KDF with a > suitable OtherInfo value, and unfortunately, found that the two are > incompatible. The reason they're incompatible is that RFC 5008 computes > this hash:**** > > KM = Hash ( Z || Counter || ECC-CMS-SharedInfo ) whereas > Concat computes this hash:**** > > K(i) = H(counter || Z || OtherInfo)**** > > ** ** > > If the order of "counter" and "Z" were this same, an implementation of > Concat could be used to do the RFC 5008 computation, but because the order > is different, unfortunately it can't.**** > > ** ** > > The reason that this matters is we need to use a widely-supported KDF to > achieve the JOSE deployability and interoperability goals. When the > original choice was made to use Concat, it was based upon looking into what > KDFs were already widely supported in libraries, and Concat looked like the > best choice.**** > > ** ** > > Using Windows as an example, if you look at the BCryptDeriveKey function > at > http://msdn.microsoft.com/en-us/library/windows/desktop/aa375393(v=vs.85).aspx, > you'll see that BCRYPT_KDF_SP80056A_CONCAT is one of the supported KDF > functions but that the RFC 5008 function isn't. (Yes, for key lengths only > requiring a single has computation, you could probably fake it with > BCRYPT_KDF_HASH, but this wouldn't work for key lengths requiring multiple > hash computations.) The same problem is likely to appear on other > platforms.**** > > ** ** > > Using XML Encryption as a litmus test for what KDF algorithms are likely > to be widely supported gives the same conclusion - > http://www.w3.org/TR/xmlenc-core1/#sec-Alg-KeyDerivation describes > support only for Concat and PBKDF2.**** > > ** ** > > Thus, while I appreciate the suggestion, and I did seriously investigate > it, I don't think it's practical to move away from using the SP 800-56A > Concat KDF. That then established, I think that the task then before us is > to decide exactly how to use it. That will be the subject of a subsequent > message.**** > > ** ** > > -- Mike*** > * > > ** ** > > -----Original Message-----**** > > From: [email protected] > [mailto:[email protected]<[email protected]>] > On Behalf Of Manger, James H**** > > Sent: Thursday, June 20, 2013 6:50 PM**** > > To: Richard Barnes; Jim Schaad**** > > Cc: [email protected]**** > > Subject: Re: [jose] Concat KDF**** > > ** ** > > > PartyUInfo seems compliant with the letter of the SP800-56A. SP800-56A * > *** > > > doesn't place any constraints on the form or duration of the **** > > > identifier ID_U, so the 512-bit value provided seems sufficient if you * > *** > > > regard that as ID_U.**** > > ** ** > > One aspect that has been confusing me is whether the recipient is expected > to recognize ID_U as a known identifier for the originator, and ID_V as its > own name?**** > > ** ** > > Alternatively, do requirements on these items only apply to the > originator? Is it completely safe for a recipient to treat ID_U and ID_V as > opaque bytes to be hashed as part of the KDF, but with no other processing? > Is it, in fact, safe for a recipient to treat OtherInfo (AlgorithmID + > PartyUInfo +...) as an opaque blob, or even OtherInput (keydatalen + > OtherInfo) as an opaque blob? In which case, we could simply include > B64(OtherInput) in a JOSE message, perhaps with a suggested way an > originator could construct OtherInput (eg from alg, enc, kid/jku, nonce).* > *** > > ** ** > > ** ** > > > The better option would be to use the same KDF that CMS uses **** > > > [RFC3278][SEC1]. It's simpler, and also complies with USG mandates **** > > > (Suite B [RFC5008]). If we use the RFC 5008 variant, it also takes as * > *** > > > input exactly what the current JWS spec provides:**** > > > **** > > > KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )**** > > > **** > > > ECC-CMS-SharedInfo = {**** > > > keyInfo, // The algorithm with which the key will be used, **** > > > currently in AlgorithmID**** > > > entityUInfo, // The entropy source we're currently putting in **** > > > PartyUInfo**** > > > suppPubInfo // The derived key length, currently in SuppPubInfo }*** > * > > > **** > > > In other words, CMS does exactly what JWS wants to do now. Let's just * > *** > > > do it for real. Proposed text for Section 4.7.1 of JWA:**** > > ** ** > > Your proposal is "logically" the same as CMS (so same security > properties), but the precise calculation is incompatible as you don't use a > DER-encoding of ECC-CMS-SharedInfo. Just wanted to clarify this intention. > **** > > ** ** > > > """**** > > > The key derivation process derives the agreed upon key from the shared * > *** > > > secret Z established through the ECDH algorithm using the single-pass ** > ** > > > KDF defined in [SEC1]. The inputs to the key derivation process are *** > * > > > as**** > > > follows:**** > > > **** > > > Z This is set to the representation of the shared secret Z as an octet * > *** > > > sequence.**** > > > **** > > > SharedInfo This is set to the concatenation of the following octet **** > > > strings, in order:**** > > > 1. The algorithm with which the derived key is to be used. If the ** > ** > > > "alg" value is "ECDH", then this field contains the value of the "alg"** > ** > > > parameter. Otherwise, it contains the value of the "enc" parameter.**** > > ** ** > > Wrong way around. If "alg" is "ECDH" use "enc" value, otherwise use "alg" > value.**** > > ** ** > > You also need to separate this field from the next: with a length prefix, > or separator char/byte.**** > > With 2 variable-sized fields (algorithm and apu) you only theoretically > need 1 length field to be unambiguous, but it needs to be at the start or > end, not in between the 2 fields.**** > > ** ** > > > 2. The length of the value of the "apu" parameter, as a 32-bit big ** > ** > > > endian integer. If the "apu" parameter is not present, then this **** > > > field is set to all zeros (0x00000000).**** > > > 3. The value of the "apu" parameter, if present. If provided, this * > *** > > > value MUST contain at least 512 bits and a unique value SHOULD be used * > *** > > > for each recipient. The "apu" parameter MAY be omitted only if a **** > > > different ephemeral key is used for each key agreement transaction.**** > > > 4. The length of the derived key, as a 32-bit big endian integer.**** > > > For "ECDH-ES", this is length of the key used by the "enc" algorithm.** > ** > > > For "ECDH-ES+A128KW" or "ECDH-ES+A256KW", it is 128 (0x00000080) or**** > > > 256 (0x00000100), respectively.**** > > ** ** > > Symmetric key lengths are hardwired into "alg" and "enc" values in JOSE > (eg "A256KW", "A128CGM") so we don't actually need a separate field.**** > > ** ** > > > """**** > > > **** > > > Two side notes:**** > > > 1. We need hash agility here (as in RFC 5008) to be able to meet **** > > > higher levels of security for which SHA-256 is unacceptable. Suggest ** > ** > > > adding hash algorithms to the ECDH algorithm identifiers, e.g., **** > > > "ECDH256", "ECDH284+KW".**** > > ** ** > > "ECDH256", "ECDH256+A128KW", "ECDH384", "ECH384+A192KW"? **** > > ** ** > > > 2. The "-ES" is unnecessary, since the entropy added in entityUInfo is * > *** > > > sufficient to address both ES and SS cases.**** > > ** ** > > ** ** > > --**** > > 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**** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
