Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 02 Apr 2015 20:28:12 +0200

[[adding [email-masked]]]

On 04/02/2015 08:01 PM, Tim McLean wrote:
> However, I do think one way of gauging the success of JWS/JOSE is to
> measure how many implementers actually get the security details right. 

I agree with you.

If several people got this wrong then it is a good idea to write about
it. Of course, it was a bit difficult to foresee this issue at the time
of writing the specification.

At a minimum we should put a version of your article at oauth.net.

Since the JWT spec (which you reference in your article) is still in
Auth48 state we can still add a warning remark to Section 7.2 of
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Apr 2015 18:42:43 +0000

This warning is already in place in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2.  It says:

   Finally, note that it is an application decision which algorithms may
   be used in a given context.  Even if a JWT can be successfully
   validated, unless the algorithm(s) used in the JWT are acceptable to
   the application, it SHOULD reject the JWT.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 02, 2015 11:28 AM
To: Tim McLean
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations

I agree with you.

If several people got this wrong then it is a good idea to write about it. Of course, it was a bit difficult to foresee this issue at the time of writing the specification.

Since the JWT spec (which you reference in your article) is still in
Auth48 state we can still add a warning remark to Section 7.2 of https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32.

Ciao
Hannes

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 02 Apr 2015 18:53:10 +0000

I'm not sure what article you're referring to, but feel free to add the
article and send a pull request to oauth.net:

https://github.com/aaronpk/oauth.net

Here's an example of the PR for the Authentication article that Justin
added: https://github.com/aaronpk/oauth.net/pull/81

Aaron Parecki

On Thu, Apr 2, 2015 at 1:43 PM Mike Jones <[email-masked]>
wrote:

> This warning is already in place in https://tools.ietf.org/html/
> draft-ietf-oauth-json-web-token-32#section-7.2.  It says:
>
> If several people got this wrong then it is a good idea to write about it.
> Of course, it was a bit difficult to foresee this issue at the time of
> writing the specification.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Thu, 2 Apr 2015 17:39:13 -0300

Sec 10.6 and 10.7 of JWS also touch on algorithm substitution.

Allowing keys to be used with multiple algorithms is a general problem, and almost always turns out unhappily.

I think that using a RSA key for HMAC is the most extreme case of that principal.

I do think that outside of the JOSE and JWT specs we need more implementer guidance encouraging the use of "alg" and "use" in JWK 
as well as propagating that information into local key stores so that the wrong key is not selected.

The problem applications in question simply took the "iss" and or the "kid" and retuned a key without looking at the "alg".

A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5 and that would not be a problem until one of them is deprecated.  
Having libraries assume that there can only be one alg per issuer would not lead to useful crypto agility in my experience.

John B.

> On Apr 2, 2015, at 3:42 PM, Mike Jones <[email-masked]> wrote:
> 
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Tim McLean <[email-masked]>
Date: Thu, 2 Apr 2015 16:56:37 -0400

On Thu, Apr 2, 2015 at 2:42 PM, Mike Jones <[email-masked]>
wrote:

> This warning is already in place in
> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2.
> It says:
>
Thanks for highlighting this, Mike.

I think it's interesting to note that this doesn't entirely prevent the
HMAC/RSA (or HMAC/ECDSA) vulnerability, at least in the way this advice is
usually implemented.  Let's say an application legitimately wants to use
both HMAC and RSA but with different keys (obviously).  They would
whitelist both algorithms, and would likely give each key a different key
ID.  This could still be exploitable in implementations that use the alg
field, since alg would still determine how the key is used.

Tim

---

From: Tim McLean <[email-masked]>
Date: Thu, 2 Apr 2015 17:23:03 -0400

On Thu, Apr 2, 2015 at 4:39 PM, John Bradley <[email-masked]> wrote:

> A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5
> and that would not be a problem until one of them is deprecated.
> Having libraries assume that there can only be one alg per issuer would
> not lead to useful crypto agility in my experience.
>

Note that I'm proposing one alg per key ID, not one alg per issuer (sorry
in advance if I misunderstood what you meant here).

Tim

---

From: John Bradley <[email-masked]>
Date: Thu, 2 Apr 2015 20:00:14 -0300

I agree that the best thing is one alg per kid. 

However getting people especially those using x509 Certs to alg is a challenge. 

People still want to do pkcs1.5 pss sha256 sha512 off of one key. 

With composite keys you need the alg to know the hash using x509 Certs. 

I think more advice for applications using JOSE libs to help them understand key management and comparing the alg in the JWT with the specific alg in a JWK or with a known subset of algs based on the key type is the best path. 

John B. 

Sent from my iPhone

> On Apr 2, 2015, at 6:23 PM, Tim McLean <[email-masked]> wrote:
> 
> Note that I'm proposing one alg per key ID, not one alg per issuer (sorry in advance if I misunderstood what you meant here). 
> 
> Tim