Subject: Re: [jose] Concat KDF

From: Mike Jones <[email-masked]>
Date: Fri, 12 Jul 2013 15:30:17 +0000

These changes have been applied in the -12 specs.

                                             -- Mike

From: Mike Jones
Sent: Tuesday, June 18, 2013 11:10 AM
To: Manger, James H; Russ Housley; Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: RE: Concat KDF

Thanks for the careful read, James.  Replies inline marked "Mike>"...

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Sunday, June 16, 2013 6:20 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Concat KDF

The use of the Concat KDF still does not look right.

JWA [draft-ietf-jose-json-web-algorithms-11] section 4.7 says "ECDH-ES" uses Concat KDF from NIST 800-56A section 5.8.1. NIST defines 5 fields that go into the key derivation: AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo.

NIST says AlgorithmID indicates the algorithm that will use the derived key. JWA says to use the "alg" value (eg "ECDH-ES") as the AlgorithmID. AlgorithmID should actually be the "enc" value when the derived key is used directly as a CEK.

Mike> I can change the draft to use the "enc" value in the direct agreement case, unless people object.

When the derived key unwraps the CEK, AlgorithmID should be the name of the key wrap algorithm (eg "A128KW"). Perhaps the "alg" value can be used in this case as it identifies the key wrap algorithm along with the key establishment algorithm (eg "ECDH-ES+A128KW").

Mike> Agreed - so there is no change needed to the AlgorithmID for the agreement with key wrapping case.

NIST says PartyUInfo includes an identifier for party U. The first problem is that JWA does not indicate if the sender or receiver is party U (nor does JWE). The second problem is that JWA says PartyUInfo is random -- which seems to totally defeat the purpose of being an identifier for a party. JWA says PartyUInfo should vary for each recipient, which suggests PartyUInfo cannot be an id of the sender. Does that suggest the receiver is party U?

Mike> The sender is Party U.  I'll say so in the draft.  (This is parallel to RFC 2631's partyAInfo, which is also supplied by the sender.)

NIST says PartyVInfo is required and includes an identifier for party V. JWA says PartyVInfo is empty, which obviously cannot meet the NIST definition.

Mike> This was discussed at the in-person working group meeting in Denver and Jim Schaad stated that I should modify the Key Agreement parameters to mirror their use in RFC 2631, which I therefore did.  Jim, Russ, and James, can the three of you (and other interested working group members) please make a decision among the three of you about text to include about PartyUInfo and PartyVInfo?  If you don't reach an agreement, one option is for me to add a note to the spec that PartyUInfo is used in the same manner as PartyAInfo of RFC 2631 and that since RFC 2631 doesn't have an equivalent of PartyVInfo, none is used here either.  The other option is to go back to the "apu" and "apv" language of http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10 - adding that the sender is Party U and the receiver is Party V.  Comments?

The JWA values for SuppPubInfo (length of derived key in bits) and SuppPrivInfo (empty) are in line with the NIST definitions.

It appears the Concat KDF text in JWA has been rewritten based on RFC2631 "Diffie-Hellman Key Agreement Method". RFC2631 is not referenced by JWA, but it is mentioned in the "document history" section (which will eventually be deleted). RFC2631 has items such as partyAInfo and suppPubInfo whose names are similar to NIST items. However, RFC2631 was published 7 years before NIST 800-56A (and 13 years before the current version of NIST 800-56A) so RFC2631 cannot be used as a example of how to use Concat KDF.

As I stated above, if we keep the current PartyUInfo/PartyVInfo usage, I will explicitly add text saying that the usage of these fields is taken from RFC 2631.

--

James Manger

_______________________________________________

jose mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose

                                                                -- Mike