Subject: [jose] Platform Support for JWA Crypto Algorithms

From: Mike Jones <[email-masked]>
Date: Mon, 29 Oct 2012 06:28:16 +0000

FYI, I posted the table describing support for the JWA algorithms in common Web development platforms that we discussed at IETF 84.  See http://self-issued.info/?p=884.

                                                            -- Mike

---

From: <[email-masked]>
Date: Mon, 29 Oct 2012 14:03:08 +0100

As one can see from this table the KDF is unsupported on all platforms (except one).
http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx

JWE

kdf

CS256

Concat Key Derivation Function (KDF)

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS384

Concat Key Derivation Function (KDF)

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS512

Concat Key Derivation Function (KDF)

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

Isn't this an indication that we should look at alternatives?

e.g.: we could generate the integrity protection key randomly instead of deriving it from the content encryption key.
This would add some more bytes (e.g. about 32) to the jwt but is very easy to implement on all platforms.

One way to do it would be to generate enough bytes "Bytes" in "JWE Encrypted Key" for encryption and integrity.
The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength .. cekLength+cikLength-1]"

Axel

[On some platforms (Firefox/NSS) it might even be nearly impossible to implement (without extending the platform's functions) because the build-in digest function is always reset when finalize (doFinal) is called. The spec of the Concat-KDF says that bytes are generated in a loop but the digest is NOT reset in the loop.]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, October 29, 2012 7:28 AM
To: [email-masked]
Subject: [jose] Platform Support for JWA Crypto Algorithms

                                                            -- Mike

---

From: Mike Jones <[email-masked]>
Date: Mon, 29 Oct 2012 16:25:12 +0000

No, Concat often isn't natively supported, but it's very easy to implement given implementations of SHA-256 and SHA-512, as shown in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5.

When the table was discussed at the WebCrypto F2F, it was pointed out that a shortcoming of the current table is that it doesn't indicate which of the "NO" values are effectively show-stoppers and which are easy to build implementations of, and so not a problem in practice.  As shown in the appendices, I believe that Concat is in the latter category.  Given the ease of implementation, it's certainly not worth adding space to the JWEs to work around.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, October 29, 2012 6:03 AM
To: Mike Jones; [email-masked]
Cc: [email-masked]
Subject: RE: Platform Support for JWA Crypto Algorithms

JWE

kdf

CS256

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS384

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS512

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

Axel

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, October 29, 2012 7:28 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Platform Support for JWA Crypto Algorithms

                                                            -- Mike

---

From: <[email-masked]>
Date: Mon, 29 Oct 2012 21:46:26 +0100

Ease of implementation is relative. Maybe tomorrow I will discover that the needed concat-KDF is supported "natively" by Mozilla's NSS library. Then it is very easy.
Currently it looks difficult on that platform because the documentation says that the digest function "finish" resets the digest, which would probably lead to different results than in the examples in the appendices A4 and A5.
" http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e
NOTE: This method may be called any time after |init| is called. This call resets the object to its pre-init state.
"
I still think that some thirty bytes is not much and that generating the CIK randomly is much easier. I implemented the concat-kdf in java
https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/crypto/KDFConcatGenerator.java and I know that implementing my proposal below is easier.
Anyway: One could ask why the concat-KDF is not implemented in Bouncycastle while three other KDFs are implemented there.
Mozilla implements KDFs too:
https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11skey.c#1437
Although there is no indication in the code which KDF this implements. Maybe a Mozillian on these lists can clarify.
If it is a KDF that is implemented in Bouncycastle too then I suggest to change the default KDF in JWE to that one.

The implementation of KDF can lead to buffer overflows is no secret:
https://bugzilla.mozilla.org/show_bug.cgi?id=617565
Which means that KeyDerivationFunction implementation is not as easy as it could be.

Why do you think that the list of NIST's crypto implementations lists all algs except KDF?
http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.html

NIST defines other KDFs too. Why is JWE using one that is implemented nowhere? Any other choice that is implemented on two platforms is a better choice than concat-kdf I think.

Axel

http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e
NOTE: This method may be called any time after |init| is called. This call resets the object to its pre-init state.

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, October 29, 2012 5:25 PM
To: Nennker, Axel; [email-masked]
Cc: [email-masked]
Subject: RE: Platform Support for JWA Crypto Algorithms

                                                            -- Mike

JWE

kdf

CS256

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS384

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS512

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

Axel

                                                            -- Mike

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 29 Oct 2012 22:16:10 +0000

> NIST defines other KDFs too. Why is JWE using one that is implemented nowhere? Any other choice that is implemented on two platforms is a better choice than concat-kdf I think.

To add more fuel to the fire: I've seen PBKDF2 is implemented in a few places, and I think it's only slightly harder to implement as concatKDF.

However, I still think just requiring a larger key is the easiest, least error-prone approach.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 29 Oct 2012 22:24:25 +0000

The "PB" in PBKDF2 is "Password Based".  This and related KDFs generate keys from passwords rather than other keys, and so are not applicable for this use case.

For lack of a commonly implemented key-based KDF, we chose a very simple one that only requires support for SHA-256 and SHA-512 to build for our use cases.  (Heck, for our use cases, implementations don't even require a loop - just a single hash calculation over the input.)  I already know of 5 interoperable implementations at this point.  It's just not that hard.

See the example calculations in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5 to see how simple it actually is.

				-- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]] 
Sent: Monday, October 29, 2012 3:16 PM
To: <[email-masked]> 
Cc: Mike Jones; <[email-masked]>; <[email-masked]>
Subject: Re: [jose] Platform Support for JWA Crypto Algorithms

- m&m

---

From: Axel Nennker <[email-masked]>
Date: Tue, 30 Oct 2012 00:41:12 +0100

Maybe that is the way to go then:

In
  http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms
simply state there that the CIK is

  CIK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43,
72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255]
  CEK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43,
72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255]
Similar for SHA512. General rule: use a digest that produces enough or more
bits as needed for the cik or cek.

NOTE (non normative) that this happens to be the same as the concat KDF as
defined in NIST.800-56A for the given bit lengths

Axel

2012/10/29 Mike Jones <[email-masked]>
>
> The "PB" in PBKDF2 is "Password Based".  This and related KDFs generate
keys from passwords rather than other keys, and so are not applicable for
this use case.
>
> For lack of a commonly implemented key-based KDF, we chose a very simple
one that only requires support for SHA-256 and SHA-512 to build for our use
cases.  (Heck, for our use cases, implementations don't even require a loop
- just a single hash calculation over the input.)  I already know of 5
interoperable implementations at this point.  It's just not that hard.
>
> See the example calculations in
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4and
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5to
see how simple it actually is.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 31 Oct 2012 00:13:16 +1100

JOSE still doesn’t use the NIST 800-56A Concat Key DF as that specification requires.

JWA allows PartyUInfo and/or PartyVInfo to be empty (if apu/apv/epu/epv are absent). That doesn’t comply with 800-56A that says “at a minimum, PartyUInfo shall include IDu, the identity of party U”. 800-56A also says “it is required that identifier for both parties to a key agreement transaction be included in the OtherInfo that is input to the key derivation function”.

800-56A requires that the concatenation AlgorithmID || PartyUInfo || PartyVInfo be unambiguous. It allows two ways to achieve this: pre-define fixed sizes for components; or prefix each component with its length. JWA does neither of these.

Consider two JOSE messages (ignoring some irrelevant base64url encoding):
  { ..., "apu":"JoBeth", "apv":"Anne" } and
  { ..., "apu":"Jo", "apv":"BethAnne" }
JWA implies both use the string "JoBethAnne" in the KDF despite the messages being between different parties, which defeats this part of the Concat KDF design.

JWA explicitly puts the key length and "alg" value into the AlgorithmID field that the KDF uses. However, the "alg" value alone must imply one specific key length for the rest of the JOSE processing to work so including the key length explicitly is redundant.

800-56A is designed to derive integrity and encryption keys together. For instance, it says “AlgorithmID might indicate that bits 1-80 are to be used as an 80-bit HMAC key and that bits 81-208 are to be used as a 128-bit AES key”. JWA does not do this. JWA runs the KDF twice to derive integrity and encryption keys separately.

If we want to use NIST 800-56A Concat KDF then JWA/JWE needs lots of fixes.
If we want a simpler KDF then JWA shouldn’t pretend it is the NIST 800-56A Concat KDF.

--
James Manger

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 30 Oct 2012 13:46:44 +0000

> The "PB" in PBKDF2 is "Password Based".  This and related KDFs generate keys from passwords rather than other keys, and so are not applicable for this use case.

Maybe this is too hacky for people, but: PBKDF2(H, base64url(key), salt, iters)

> See the example calculations in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5 to…

If we're going for least difficulty, then why not just use key that's (cipher-len + hash-len) in the first place?

- m&m

---

From: Axel Nennker <[email-masked]>
Date: Wed, 31 Oct 2012 09:32:17 +0100

I think that https://tools.ietf.org/html/rfc2898 (
https://en.wikipedia.org/wiki/PBKDF2) is a better choice than the
concat-kdf from NIST.
PBKDF2 does not care whether the password consists of printable characters
or whether it is a randomly generated byte strink like our CMK.
There is no need to base64url the key/cmk.

In the wikipedia article is a list of implementations which sounds much
better than our current rows in our crypto-algs compat-table.

I suggest we use PBKDF2(HMACSHA1, cmk, iv||"Integrity", 1000) to generate
cik and PBKDF2(SHA256, cmk, iv||"Encryption", 1000) to generate the cek.
"||" is concatenation. HMACSHA1 as default (MTI) and HMACSHA256 as
recommended?!

Or we could use my earlier proposal to define the first interation of the
concat-kdf as the default for our currently defined encryption algorithms.
  CIK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43,
72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255]
  CEK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43,
72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255]
or something along those lines...

Axel

2012/10/30 Matt Miller (mamille2) <[email-masked]>

> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5to see how simple it actually is.
> >
>
> If we're going for least difficulty, then why not just use key that's
> (cipher-len + hash-len) in the first place?
>
>
> - m&m
>
> >> Ease of implementation is relative. Maybe tomorrow I will discover that
> the needed concat-KDF is supported "natively" by Mozilla's NSS library.
> Then it is very easy.
> >> Currently it looks difficult on that platform because the documentation
> says that the digest function "finish" resets the digest, which would
> probably lead to different results than in the examples in the appendices
> A4 and A5.
> >> "
> >> NOTE: This method may be called any time after |init| is called. This
> call resets the object to its pre-init state.
> >> "
> >> I still think that some thirty bytes is not much and that generating
> the CIK randomly is much easier. I implemented the concat-kdf in java
> >>
> https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/crypto/KDFConcatGenerator.javaand I know that implementing my proposal below is easier.
> >> Anyway: One could ask why the concat-KDF is not implemented in
> Bouncycastle while three other KDFs are implemented there.
> >> Although there is no indication in the code which KDF this implements.
> Maybe a Mozillian on these lists can clarify.
> >> If it is a KDF that is implemented in Bouncycastle too then I suggest
> to change the default KDF in JWE to that one.
> >>
> >> NIST defines other KDFs too. Why is JWE using one that is implemented
> nowhere? Any other choice that is implemented on two platforms is a better
> choice than concat-kdf I think.
> >>
> >
> > To add more fuel to the fire: I've seen PBKDF2 is implemented in a few
> places, and I think it's only slightly harder to implement as concatKDF.
> >
> >> NOTE: This method may be called any time after |init| is called. This
> call resets the object to its pre-init state.
> >>
> >> No, Concat often isn't natively supported, but it's very easy to
> implement given implementations of SHA-256 and SHA-512, as shown in
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5
> .
> >>
> >> When the table was discussed at the WebCrypto F2F, it was pointed out
> that a shortcoming of the current table is that it doesn't indicate which
> of the "NO" values are effectively show-stoppers and which are easy to
> build implementations of, and so not a problem in practice.  As shown in
> the appendices, I believe that Concat is in the latter category.  Given the
> ease of implementation, it's certainly not worth adding space to the JWEs
> to work around.
> >>
> >>                                                           -- Mike
> >>
> >> e.g.: we could generate the integrity protection key randomly instead
> of deriving it from the content encryption key.
> >> One way to do it would be to generate enough bytes "Bytes" in "JWE
> Encrypted Key" for encryption and integrity.
> >> [On some platforms (Firefox/NSS) it might even be nearly impossible to
> implement (without extending the platform's functions) because the build-in
> digest function is always reset when finalize (doFinal) is called. The spec
> of the Concat-KDF says that bytes are generated in a loop but the digest is
> NOT reset in the loop.]
> >>
> >>
> >> From: [email-masked]<mailto:[email-masked]> [mailto:
> [email-masked]] On Behalf Of Mike Jones
> >> FYI, I posted the table describing support for the JWA algorithms in
> common Web development platforms that we discussed at IETF 84.  See
> http://self-issued.info/?p=884.
> >>
> >>                                                           -- Mike
> >>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 31 Oct 2012 14:41:31 +0000

> better than our current rows in our crypto-algs compat-table.

I only suggested base64 encoding the key as a way to get past the perceptions around the word "password".  While RFC 2898 does say:

   Throughout this document, a password is considered to be an octet
   string of arbitrary length whose interpretation as a text string is
   unspecified. In the interest of interoperability, however, it is
   recommended that applications follow some common text encoding rules.
   ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of
   UTF-8.)

All of the implementations I've used or looked at have interpreted "password" to simply be an octet string (as per the rest of RFC 2898).

- m&m

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 31 Oct 2012 10:00:45 -0700

On Mon, Oct 29, 2012 at 4:23 PM, Ryan Sleevi <[email-masked]> wrote:
>
> However, as an NSS developer, I do not see your presented argument as a
> reason not to use Concat-KDF, and Concat-KDF would be more preferable, as a
> NIST-blessed KDF, since NSS cares especially for NIST-blessed algorithms.

I think HKDF (hash-based key derivation function) is also worth considering.
It is specified in RFC 5869 and is also blessed by NIST in SP 800-56C.

Wan-Teh

---

From: Axel Nennker <[email-masked]>
Date: Wed, 31 Oct 2012 22:15:51 +0100

I think we need a table with the same platform as in Mike's table that
started this discussion with KDFs that actually have implementations.
Specification in RFCs or blessing by NIST does not count. Implementations
rule.

Usage Param Name Param Val Description .NET Windows native OS X iOS Java JCA
BouncyCastle Android PHP PHPSecLib Python M2Crypto PyCrypto Ruby OpenSSL
node.js NSS            JWE kdf CS256 Concat Key Derivation Function (KDF) NO
Win7     NO NO NO NO NO NO NO NO   NO NO NO  JWE kdf CS384 Concat Key
Derivation Function (KDF) NO Win7     NO NO NO NO NO NO NO NO   NO NO NO
JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7     NO NO NO NO
NO NO NO NO   NO NO NO

Axel

2012/10/31 Wan-Teh Chang <[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Wed, 31 Oct 2012 21:22:07 +0000

I agree that this would be useful, but the other factor that's critical is ability to implement when your developer platform doesn't have native support.  As demonstrated in the appendices, it's trivial to implement Concat with only SHA-256 and SHA-512.  So direct platform support for Concat is actually a non-issue for interoperability, as anyone can build it themselves with a few string concat operations and a single hash.

If other KDFs aren't built-in to all platforms, the key criteria for considering them is that the primitives needed to build them must be (just as they already are for Concat).

                                                                           -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Axel Nennker
Sent: Wednesday, October 31, 2012 2:16 PM
To: Wan-Teh Chang
Cc: Mike Jones; [email-masked]; Ryan Sleevi; [email-masked]; [email-masked]
Subject: Re: [jose] Platform Support for JWA Crypto Algorithms

I think we need a table with the same platform as in Mike's table that started this discussion with KDFs that actually have implementations.
Specification in RFCs or blessing by NIST does not count. Implementations rule.
Usage

Param Name

Param Val

Description

.NET

Windows native

OS X

iOS

Java JCA

BouncyCastle

Android

PHP

PHPSecLib

Python

M2Crypto

PyCrypto

Ruby

OpenSSL

node.js

NSS

JWE

kdf

CS256

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS384

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

JWE

kdf

CS512

NO

Win7

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

Axel

2012/10/31 Wan-Teh Chang <[email-masked]<mailto:[email-masked]>>

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