Subject: [jose] Concat KDF

From: "Manger, James H" <[email-masked]>
Date: Mon, 17 Jun 2013 11:20:25 +1000

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Jun 2013 11:57:31 -0400

Agree.  These things have origins in ANSI X9.42 and RFC 2631.

Russ

On Jun 16, 2013, at 9:20 PM, Manger, James H wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Tue, 18 Jun 2013 18:09:56 +0000

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

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

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.

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.)

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?

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]>

                                                                -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 18 Jun 2013 14:39:17 -0700

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

> 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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 17:52:11 -0400

## 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

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 21 Jun 2013 11:49:43 +1000

> 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).

> [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:
> 
>     keyInfo, // The algorithm with which the key will be used,
> currently in AlgorithmID
> 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.

> 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:
> 
> 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.

> endian integer.  If the "apu" parameter is not present, then this field
> is set to all zeros (0x00000000).
> 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.

> 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"?	

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Fri, 21 Jun 2013 23:21:58 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, June 20, 2013 6:50 PM
To: Richard Barnes; Jim Schaad
Cc: [email-masked]
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.

>     suppPubInfo // The derived key length, currently in SuppPubInfo }
> 

> endian integer.  If the "apu" parameter is not present, then this 
> field is set to all zeros (0x00000000).

> """
> 
> 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".

---

From: Mike Jones <[email-masked]>
Date: Sat, 22 Jun 2013 00:45:55 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, June 21, 2013 4:22 PM
To: Manger, James H; Richard Barnes; Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] Concat KDF

                KM = Hash ( Z || Counter || ECC-CMS-SharedInfo ) whereas Concat computes this hash:

                                                                -- Mike

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Manger, James H

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

> doesn't place any constraints on the form or duration of the

>     entityUInfo, // The entropy source we're currently putting in

> PartyUInfo

> KDF defined in [SEC1].  The inputs to the key derivation process are

> as

--

James Manger

jose mailing list

jose mailing list

---

From: Richard Barnes <[email-masked]>
Date: Sat, 22 Jun 2013 15:26:52 -0400

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-masked]>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***
> *
>
> ** **
>
> ** **
> 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-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Manger, James H****
>
> Sent: Thursday, June 20, 2013 6:50 PM****
>
> To: Richard Barnes; Jim Schaad****
>
> Cc: [email-masked]****
>
> 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-masked]****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/jose****
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 22 Jun 2013 14:28:45 -0700

This does not also answer the question of how entities are going to be named
in JOSE.  It is easy to do in TLS and for PKIX because there are always
names for them.  This is not a feature of JOSE, we don't name people that is
left for applications.  Also if one looks at it, then we should not need to
send this information in the message because each party would know the names
of both entities.

Having read the rational for using identifiers, it is not clear that there
is anything in the rational that applies to JOSE in any case.  Given that we
are doing ephemeral-static dh, there is no way for a shared key attack to
occur in the case of a store and forward message.  

There is a possibility that it could occur for the case of XMPP where one is
separating the key management from the key usage, but it is not a general
case problem.

If we are going to be in a situation where we don't know the names of the
entities - unless the application somehow finds them out, makes them common
and then tells the application what they are there is no reason not to use
fixed constants.  I don't know what the benefit is going to be for saying,
in the message, that for the purposes of this message "Your name is Fred".

Jim

From: Richard Barnes [mailto:[email-masked]] 
Sent: Saturday, June 22, 2013 12:27 PM
To: Mike Jones
Cc: Jim Schaad; Russ Housley; Manger, James H; [email-masked]
Subject: Re: [jose] Concat KDF

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. 

<http://stackoverflow.com/questions/10879658/existing-implementations-for-ni
st-sp-800-56a-concatenation-key-derivation-functi>

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-masked]>
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.

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. 

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-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Friday, June 21, 2013 4:22 PM
To: Manger, James H; Richard Barnes; Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] Concat KDF

this hash:

                KM = Hash ( Z || Counter || ECC-CMS-SharedInfo ) whereas
Concat computes this hash:

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.

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).a
spx>
http://msdn.microsoft.com/en-us/library/windows/desktop/aa375393(v=vs.85).as
px, 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>
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:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
Manger, James H

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

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).

> 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.

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.

> 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.

 

--

James Manger

jose mailing list

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

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

jose mailing list

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

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

---

From: Mike Jones <[email-masked]>
Date: Sat, 22 Jun 2013 22:17:15 +0000

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."

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Saturday, June 22, 2013 2:29 PM
To: 'Richard Barnes'; Mike Jones
Cc: 'Russ Housley'; 'Manger, James H'; [email-masked]
Subject: RE: [jose] Concat KDF

This does not also answer the question of how entities are going to be named in JOSE.  It is easy to do in TLS and for PKIX because there are always names for them.  This is not a feature of JOSE, we don't name people that is left for applications.  Also if one looks at it, then we should not need to send this information in the message because each party would know the names of both entities.

Having read the rational for using identifiers, it is not clear that there is anything in the rational that applies to JOSE in any case.  Given that we are doing ephemeral-static dh, there is no way for a shared key attack to occur in the case of a store and forward message.

There is a possibility that it could occur for the case of XMPP where one is separating the key management from the key usage, but it is not a general case problem.

If we are going to be in a situation where we don't know the names of the entities - unless the application somehow finds them out, makes them common  and then tells the application what they are there is no reason not to use fixed constants.  I don't know what the benefit is going to be for saying, in the message, that for the purposes of this message "Your name is Fred".

Jim

From: Richard Barnes [mailto:[email-masked]]
Sent: Saturday, June 22, 2013 12:27 PM
To: Mike Jones
Cc: Jim Schaad; Russ Housley; Manger, James H; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Concat KDF

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-masked]<mailto:[email-masked]>> wrote:

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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Friday, June 21, 2013 4:22 PM
To: Manger, James H; Richard Barnes; Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Concat KDF

                                                                -- Mike

-----Original Message-----

--

James Manger

jose mailing list

jose mailing list

---

From: Russ Housley <[email-masked]>
Date: Sun, 23 Jun 2013 10:43:18 -0400

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

---

From: Mike Jones <[email-masked]>
Date: Sun, 23 Jun 2013 21:56:43 +0000

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:[email-masked]]
Sent: Sunday, June 23, 2013 7:43 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Concat KDF

Mike:

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 23 Jun 2013 16:10:40 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Sunday, June 23, 2013 2:57 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: [jose] Concat KDF

"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

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 24 Jun 2013 00:24:45 +0000

The problem with that is that we're inventing our own KDF at that point.  The upsides of Concat are that it is known to work, is known to be implemented, and is known to meet NIST and other existing security criteria.  At least as I see it, we shouldn't give up those advantages without a compelling reason to do so.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, June 23, 2013 4:11 PM
To: Mike Jones; 'Russ Housley'
Cc: [email-masked]
Subject: RE: [jose] Concat KDF

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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Sunday, June 23, 2013 2:57 PM
To: Russ Housley
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Concat KDF

                                                            -- Mike

Mike:

Russ

---

From: Mike Jones <[email-masked]>
Date: Mon, 24 Jun 2013 01:18:19 +0000

Jim - permit me to ask a pair of follow-up questions.  First, what goal are you trying to accomplish in your suggestion below?  I'm wondering if there's a way to meet the needs of the use case you have in mind with particular parameter choices with the Concat KDF.

Second, does the proposed text below meet the needs of the use case you have in mind?

                                                            Thanks,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Sunday, June 23, 2013 5:25 PM
To: Jim Schaad; 'Russ Housley'
Cc: [email-masked]
Subject: Re: [jose] Concat KDF

                                                            -- Mike

Jim

                                                            -- Mike

Mike:

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 23 Jun 2013 21:07:43 -0700

The goal is simple - meet the requirements of the NIST document.

No the text below does not meet the requirements stated above.

The text does not contain sufficient information to fully document what is
required to define the KDF function needed.  However, I will be happy using
the 2531 KDF function rather than a NIST one since, as I have previously
stated, the reasons in the NIST document for having the party identifiers is
not one that is required for the store and forward use cases.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Sunday, June 23, 2013 6:18 PM
To: Jim Schaad; 'Russ Housley'
Cc: [email-masked]
Subject: RE: [jose] Concat KDF

Jim - permit me to ask a pair of follow-up questions.  First, what goal are
you trying to accomplish in your suggestion below?  I'm wondering if there's
a way to meet the needs of the use case you have in mind with particular
parameter choices with the Concat KDF.

Second, does the proposed text below meet the needs of the use case you have
in mind?

                                                            Thanks,

                                                            -- Mike

The problem with that is that we're inventing our own KDF at that point.
The upsides of Concat are that it is known to work, is known to be
implemented, and is known to meet NIST and other existing security criteria.
At least as I see it, we shouldn't give up those advantages without a
compelling reason to do so.

                                                            -- Mike

 

Jim

                                                            -- Mike

Mike:

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 23 Jun 2013 21:10:40 -0700

This is not implementing a new KDF in any way shape or form.  This is
defining a way to know what the IDs that are to be included in the NIST KDF
function are supposed to be.

Jim

                                                            -- Mike

 

Jim

                                                            -- Mike

Mike:

Russ

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 25 Jun 2013 14:21:30 +1000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, 24 June 2013 9:11 AM
To: 'Mike Jones'; 'Russ Housley'
Cc: [email-masked]
Subject: Re: [jose] Concat KDF

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

Jim

“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

Mike:

Russ