## Summary For those playing along at home, the document in question is NIST SP800-56A: <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf>
That document calls for the following required inputs to the KDF: 1. AlgorithmID: an identifier for the algorithm that the derived keys will be used for 2. PartyUInfo: Not null, including at least ID_U 3. PartyVInfo: Not null, including at least ID_V The relevant text for JOSE is in JWA: < http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11#section-4.7.1 > ## Commentary Right now, the spec seems to me to be mostly compliant with the letter of SP800-56A. It seems like a few small tweaks would bring it to full compliance. AlgorithmID is almost right, but it needs to distinguish between the direct and wrapped cases. In the case of "ECDH-ES+A128KW", the AlgorithmID should be set to the "alg" value, as it is now. In the case of "ECDH-ES", the AlgorithmID should be value of the "enc" parameter. 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. PartyVInfo is clearly non-compliant, because SP800-56A requires it to be non-null. It seems like there are a few possible ways to resolve this: 1. Use a random string, as in PartyUInfo. Possibly split the 512 bits currently in PartyUInfo into two 256-bit halves, one for PartyUInfo and one in PartyVInfo. 2. Use another identifier, e.g., the value of the "kid" parameter ## Counterproposal Of course, this all seems pretty abusive and not in the spirit of SP800-56A. The fact that this question is still unresolved makes me wonder how existing implementations are populating these fields. There are three possible cases: 1. Current JOSE ECDH code populates the concat fields correctly according to SP800-56A 2. Current JOSE ECDH code popluates the concat fields incorrectly 3. No current JOSE code actually implements ECDH In case (1), the spec should just require what the code is doing. In case (2), the implementations are going to have to change anyway, to have correct behavior. I suspect the real situation is case (3), based on a cursory survey of implementations, or at best (2), based on the current state of the spec. In either of those cases, our work here need not be constrained by existing code (since it will have to change anyway), so we could do something crazy like use a KDF that we don't have to abuse. PBKDF2 would be one option. 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: """ 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. 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. """ 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". 2. The "-ES" is unnecessary, since the entropy added in entityUInfo is sufficient to address both ES and SS cases. --Richard On Tue, Jun 18, 2013 at 5:39 PM, Jim Schaad <[email protected]> wrote: > I have gone back a re-read the NIST document from the top, and there are > going to be some problems with trying to comply with them in some cases. > > Let's look at the fields from top to bottom > > AlgorithmID - I would agree that this should be alg in the case of doing a > key wrap key and enc in the case of doing a CEK. > > Identities of PartyU and PartyV - these are well known as PartyU is always > the initiator and PartyV is always the acceptor. In a store and forward > environment where we are doing static-ephemeral the ephemeral is always > associated with PartyU. I do not believe that this needs to be made > explicit in the document but that can be addressed later. > > IDs - there is a problem with what to use for identifiers in for the JOSE > work. In many cases there is just a key and not necessarily a well-defined > identifier that both parties are going to agree on. This is something that > we cannot really do at present because there is no name component of a JWK > and any other name is going to be based on the application and not on what > is known to the JOSE library. It is even harder because the sender can, > with an ephemeral key, want to remain anonymous and therefore the recipient > has no agreed upon identifier with the sender. > > In theory, the names used should not need to be transmitted as part of the > message as it is assumed that both parties will understand what the > identifiers are (or they will have exchanged them in an online protocol). > One possible course is to say that by default the names "Sender" and > "Receiver" will be used as the identifiers unless other names are provided > by the application protocol. In this case they would not need to be > transmitted as they are known to each entity. > > There is also a requirement for a nonce to be sent for a simple > static-static case, this is not a current requirement and would be defined > for the case of a static-static algorithm. I don't believe that we need to > define the 'nonce' field to carry this value at this time. > > Jim > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Manger, James H > > Sent: Sunday, June 16, 2013 6:20 PM > > To: [email protected] > > 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. 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"). > > > > 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? > > > > NIST says PartyVInfo is required and includes an identifier for party V. > JWA > > says PartyVInfo is empty, which obviously cannot meet the NIST > definition. > > > > 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. > > > > -- > > 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
