Re: [jose] Concat KDF

["Manger, James H" <[e-mail]>]

A few more observations on ConcatKDF…

Revision 2 of NIST 800-56A has just been published. JOSE should probably reference this update. The text about identifiers for parties is slightly better (section 4.1 “Key establishment Preparations”), but it still isn’t explicit about whether senders and/or receivers are responsible for validating AlgorithmID/PartyUInfo/PartyVInfo/SuppPubInfo/SuppPrivInfo.

Including a key owner’s name in a KDF calculation is going to be awkward for JOSE given it really leaves those details to higher layers, but it is necessary for interoperability if we use ConcatKDF.

Jim’s scheme might work. The recipient’s static ECDH key is assumed to come from a JWK that has an “ID” field.
Example: {"kty":"EC","crv":"P-521","kid":"537352","ID":"alice","x":"…","y":"…"}

If the “ID” field is absent but a “x5c” field is present, it might be easier to use the whole certificate (instead of the DER-encoded subject name) as PartyVInfo. It means the code doing the ConcatKDF calculation doesn’t need to decode DER. It does mean that a recipient’s key MUST be associated with an “ID” or “x5c” field to use ConcatKDF.

“ID” might not be such a good name as it is too easy to confuse with “kid”. Perhaps “owner”?

The originator of a JOSE ECDH message contributes an ephemeral key and is not authenticated so giving them a name feels unnecessary (or actively misleading). How about fixing PartyUInfo to be “anonymous” for the ECDH Ephemeral-Static algorithms?

[It’s a pity we don’t have a canonical form of JSON so we could describe the ConcatKDF OtherInput field as a JSON object — instead of needing to make up an ad hoc binary format.]


ConcatKDF in the XML encryption standard [http://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF] has separate XML attributes for AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo. Unfortunately the fields are concatenated together without preserving their boundaries. Hence it looks broken to me. There were some recent interop test cases from Microsoft and IBM for ConcatKDF in XML encryption. The KDF parts work, but the associated CBC encryption looks wrong as it is missing some padding. It doesn’t give much confidence that ConcatKDF is used much. [http://lists.w3.org/Archives/Public/public-xmlsec/2013Jun/0005.html]

--
James Manger

From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Monday, 24 June 2013 9:11 AM
To: 'Mike Jones'; 'Russ Housley'
Cc: [e-mail]
Subject: Re: [jose] Concat KDF

I have been thinking about this and I am going to make a different proposal.


The proposal is as follows:


1.        We eliminate the two partyX fields from the specification

2.       We define a new “ID” field which MUST be present for ECDH keys.

3.       We say that you take the ID field from the sender/recipient respectively and use them in the PartyX fields when doing the KDC.

The only down side of this, is that if one has a certificate then we should use the DER encoded subject name of the certificate but I am not sure how this would be encoded in the case you have a JWK which contains an x5c member.  It might be that we will need to defined an ID and an IDb64 field to allow for a binary ID to be used.

There would still need to be a requirement that the ID field be length prefixed in the discussion.

Jim


From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Sunday, June 23, 2013 2:57 PM
To: Russ Housley
Cc: [e-mail]
Subject: Re: [jose] Concat KDF

Good idea, Russ.  How about this?

“In the general case, the specific identifiers used to tie the key derivation to the sender (Party U) and the receiver (Party V) are application specific and beyond the scope of this specification.  As an illustration of one possible usage, when the JWE is a JSON Web Token (JWT) [JWT], applications might specify that the “iss” (issuer) value be used as the “apu” value and the primary “aud” (audience) value be used as the “apv’ value.”

                                                            -- Mike

From: Russ Housley [mailto:[e-mail]]
Sent: Sunday, June 23, 2013 7:43 AM
To: Mike Jones
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] Concat KDF

Mike:

I can add a sentence along the lines of the following to make Jim’s points below clearer to non-expert readers:

“The specific identifiers used to tie the key derivation to the sender (Party U) and the receiver (Party V) are application specific and beyond the scope of this specification.”

I see the attraction of this approach, but I wonder if it would be possible to also include some advice to applications that make use of JOSE.

If the parties that are trying to form a pairwise key make different assumptions, then we do not get interoperability.  I am just trying to improve the likelihood of interoperability.

Russ