Subject: [jose] Security research on JWT implementations

From: Tim McLean <[email-masked]>
Date: Wed, 1 Apr 2015 15:01:49 -0400

Hello,

I have been reviewing implementations of the JSON Web Token spec
(draft-ietf-oauth-json-web-token), many of which are used in production
systems, and have found that many of them allow an attacker to bypass the
signature verification mechanism.

Most libraries implement verification logic similar to the following:

  boolean verify(string token, string key):
    decode the header and extract the `alg` parameter
    decide based on `alg` how to verify the token signature
    return the result of that verification

This is hugely problematic, as `alg` is an attacker-controlled parameter.
In some libraries, specifying "alg":"none" will cause the verification to
succeed and ignore the specified `key`.  In other cases, I can bypass
RSA/ECDSA verification by tricking the library into using the public key as
an HMAC secret.

I wrote up a full walk-through of these problems in this blog post:
https://www.timmclean.net/2015/03/31/jwt-algorithm-confusion.html

I would like to propose deprecating the `alg` field.  Nearly every
implementation that I've reviewed has trusted what algorithm was specified
in the token.  They should be basing their choice of algorithm on how the
key was *intended* to be used.  Without an `alg` field inside the token,
implementers would need to ask their API users to specify what algorithm
was expected -- perfectly mitigating these vulnerabilities.

I should point out that this proposal does not limit cryptographic
agility.  The key ID field (`kid`) is adequate for this purpose.  Since
keys should only ever be used with one algorithm (to avoid unexpected
cryptographic interactions), determining which key to use implicitly
determines which algorithm to use (since each key should be tied to its
intended algorithm).  This means that JWT users can easily support multiple
algorithms by supporting multiple keys, and transition between algorithms
by transitioning between keys.

Cheers,
Tim McLean

PS: My apologies if this message was not sent to the right place -- I am
new to IETF procedures.

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 2 Apr 2015 08:39:12 -0700

> was expected -- perfectly mitigating these vulnerabilities.

By that analysis we should also deprecate jku (the key URL) since it can be
used to point to an attacker-controlled resource.

Ins't the point here that libraries should _not_ work out of the box until
some kind of trust configuration is provided? alg:none can be perfectly
acceptable if the channel is trusted, for instance.

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

-- 
--Breno

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 02 Apr 2015 16:58:44 +0100

On 01/04/15 20:01, Tim McLean wrote:
> systems, and have found that many of them allow an attacker to bypass
> the signature verification mechanism.
>
> This is hugely problematic, as `alg` is an attacker-controlled
> parameter.  In some libraries, specifying "alg":"none" will cause the
> verification to succeed and ignore the specified `key`.  In other cases,
> I can bypass RSA/ECDSA verification by tricking the library into using
> the public key as an HMAC secret.
>
> implementation that I've reviewed has trusted what algorithm was
> specified in the token.  They should be basing their choice of algorithm
> on how the key was /intended/ to be used.  Without an `alg` field inside
> the token, implementers would need to ask their API users to specify
> what algorithm was expected -- perfectly mitigating these vulnerabilities.

Our library requires the verifiers initialized with the expected algo, 
as opposed to supporting the provided algo property out of the box. It 
is an obvious thing to have IMHO. It is not right to portrait it as a 
weakness of the JWS spec...

I also agree that 'none' can be a useful feature, not only in a trusted 
channel but also as a way to use a generic JWE-JWS function where JWE 
encryption only is important

Sergey

> intended algorithm).  This means that JWT users can easily support
> multiple algorithms by supporting multiple keys, and transition between
> algorithms by transitioning between keys.
>
> Cheers,
> Tim McLean
>

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 02 Apr 2015 09:06:41 -0700

This sounds like a basic misunderstanding about the role of a "security 
toolkit" vs. an end-to-end protocol that uses a toolkit (e.g., SAML or 
openID Connect).

For example, all of the crypto primitives available in java (jca/jce) 
could also be "misused" in these ways, so I am not sure this analysis is 
very helpful.

> (draft-ietf-oauth-json-web-token), many of which are used in 
> production systems, and have found that many of them allow an attacker 
> to bypass the signature verification mechanism.
>
> verification to succeed and ignore the specified `key`.  In other 
> cases, I can bypass RSA/ECDSA verification by tricking the library 
> into using the public key as an HMAC secret.
>
> specified in the token.  They should be basing their choice of 
> algorithm on how the key was /intended/ to be used.  Without an `alg` 
> field inside the token, implementers would need to ask their API users 
> to specify what algorithm was expected -- perfectly mitigating these 
> vulnerabilities.
>
> agility.  The key ID field (`kid`) is adequate for this purpose.  
> Since keys should only ever be used with one algorithm (to avoid 
> unexpected cryptographic interactions), determining which key to use 
> implicitly determines which algorithm to use (since each key should be 
> tied to its intended algorithm).  This means that JWT users can easily 
> support multiple algorithms by supporting multiple keys, and 
> transition between algorithms by transitioning between keys.
>
> Cheers,
> Tim McLean
>
> PS: My apologies if this message was not sent to the right place -- I 
> am new to IETF procedures.
>
>

---

From: Tim McLean <[email-masked]>
Date: Thu, 2 Apr 2015 13:49:28 -0400

> acceptable if the channel is trusted, for instance.

I agree.  Basically, what I'm saying is:
- that trust configuration should include which algorithm meant to be used.
- if there is a complete trust configuration, then the `alg` field is not
needed (since it is already known).

In many libraries, the implementer did not realize that the choice of
algorithm should be part of the trust configuration, causing them to use
and trust the `alg` field.  Since it's not needed, why lead implementers
astray?

Cheers,
Tim

---

From: Tim McLean <[email-masked]>
Date: Thu, 2 Apr 2015 14:01:28 -0400

On Thu, Apr 2, 2015 at 11:58 AM, Sergey Beryozkin <[email-masked]>
wrote:

> Our library requires the verifiers initialized with the expected algo, as
> opposed to supporting the provided algo property out of the box. It is an
> obvious thing to have IMHO. It is not right to portrait it as a weakness of
> the JWS spec...
>

That's the right way to do it!  Unfortunately, it wasn't obvious to the
majority of implementers.

My point here isn't really that the spec is "wrong" -- it's a great piece
of work, and I'd like to see it succeed.  Technically, the libraries were
vulnerable not because of a deficiency in JWS, but because they broke from
spec.  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
think the change I'm proposing could significantly improve this metric.

Cheers,
Tim

---

From: Tim McLean <[email-masked]>
Date: Thu, 2 Apr 2015 14:04:29 -0400

> could also be "misused" in these ways, so I am not sure this analysis is

I'm not sure what you mean here.  This isn't a case of implementers
misusing primitives -- this is a case of attackers forcing misuse of
primitives.  Maybe you can clarify?

Tim

---

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: John Bradley <[email-masked]>
Date: Thu, 2 Apr 2015 16:46:05 -0300

Without alg we would have a problem with crypto agility.

At some point algorithms are deprecated and you need a window to move from one to another.  They may both use the same key, such as HMACSHA1 and HMACSHA256.

The receiver of a signed object may need to determine from the object:
1.  Who it is from “iss”
2.  The algorithm to use 
3.  What key they used “kid”,  “jku” or implicit if there is only one key for a alg.

It is the application that needs to determine the trust relationship.

Removing “alg” from the wire level protocol would not be a good idea.  

It however might be better to have lower level crypto libs that don’t have a view into the trust model only accept keys and algs that are explicitly passed in rather than splitting the logic into two places.

What keys, algorithms, and issuers are permissible on given channels is something that needs to happen outside the low level crypto lib.

It is also possible that a relying party might receive a token with a kid alg and sig that all verify perfectly, but if Issuer A is signing the token and inserting Issuer B in the “iss” and the RP is not checking that the 
key retrieved via the kid belongs to issuer B then we also have a problem. 

In looking at the libraries that were able to be tricked into using a RSA (and probably EC) public key as a HMAC key they seam to be in weakly typed languages.
The attack worked because the keys were coerced into the needed type.   

I give you full credit for finding this, and am grateful that you are looking at implementations.

John B.

> On Apr 2, 2015, at 2:49 PM, Tim McLean <[email-masked]> wrote:
> 
> On Thu, Apr 2, 2015 at 11:39 AM, Breno de Medeiros <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Ins't the point here that libraries should _not_ work out of the box until some kind of trust configuration is provided? alg:none can be perfectly acceptable if the channel is trusted, for instance.
> 
> - if there is a complete trust configuration, then the `alg` field is not needed (since it is already known).
> 
> In many libraries, the implementer did not realize that the choice of algorithm should be part of the trust configuration, causing them to use and trust the `alg` field.  Since it's not needed, why lead implementers astray?
> 
> Cheers,
> Tim
>

---

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

---

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:19:05 -0400

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

> At some point algorithms are deprecated and you need a window to move from
> one to another.  They may both use the same key, such as HMACSHA1 and
> HMACSHA256.
>
> It however might be better to have lower level crypto libs that don’t have
> a view into the trust model only accept keys and algs that are explicitly
> passed in rather than splitting the logic into two places.
>
> What keys, algorithms, and issuers are permissible on given channels is
> something that needs to happen outside the low level crypto lib.
>
> It is also possible that a relying party might receive a token with a kid
> alg and sig that all verify perfectly, but if Issuer A is signing the token
> and inserting Issuer B in the “iss” and the RP is not checking that the
> In looking at the libraries that were able to be tricked into using a RSA
> (and probably EC) public key as a HMAC key they seam to be in weakly typed
> languages.

Good point about crypto agility, John.  I think that's worth investigating
further.

I think algorithm updates/changes can be achieved via key rotation.  Given
a "key1" that is defined to use algorithm A:
- Create a "key2" that uses algorithm B.
- Publish "key2" to all parties planning to receive JWSs.
- Switch all relevant devices from signing with "key1" to signing with
"key2".
- (optional) Publish the fact that "key1" should no longer be accepted.

If needed, the only difference between "key1" and "key2" could be that they
are defined to use different algorithms -- the underlying key material
could be identical.  I don't think that would be advisable though; reusing
keys between algorithms might give up any benefit of the upgrade (or could
completely destroy security if the algorithms have unexpected interactions).

Cheers,
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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 03 Apr 2015 11:33:02 +0300

The evidence is that the alg / alg+enc parameters are not critical and
required in all cases, and therefore redundant, and could be declared
optional.

Could they be scrapped altogether? To me that's a different question,
which requires investigation to be confident that no valid case is
missed where their presence is actually needed.

That the alg / alg+enc parameters are currently specified as mandatory
apparently confuses people into thinking "alg" should be the prime
determinant when processing received JWS / JWE objects. Applications
should actually specify this prime determinant, i.e. the header
parameters to include to enable the recipient to verify / decrypt the
object. For OpenID Connect that is "kid" for example.

I agree with John that "kid" goes not guarantee correct implementations.
But to me that's a different concern, and I don't think we can use that
as an argument for / against the mandatory use of alg.

I'm grateful Tim brought this up, to illustrate the importance of
letting the application determine the actual required JOSE parameters,
and how this may translate to better and safer implementations.

I'm a bit sad that we haven't fully realised this, at some earlier
stage, now that JOSE is almost final and is widely deployed.

But I hope this could still flow into the new binary encodings and are
being developed now.

Cheers,

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 03 Apr 2015 11:39:08 +0200

On 2015-04-03 10:33, Vladimir Dzhuvinov wrote:
> The evidence is that the alg / alg+enc parameters are not critical and required in all cases, and therefore redundant, and could be declared optional.
>
> Could they be scrapped altogether? To me that's a different question, which requires investigation to be confident that no valid case is missed where their presence is actually needed.

Hi Vladimir,
They are probably quite needed.

If everything is based on OOB-arrangements you can probably drop a bunch of parameters. If not don't you need alg to for example deal with RS256 and RS512 in a reasonable way?

By making a things optional you effectively introduce additional complexity.

Anders

>
> That the alg / alg+enc parameters are currently specified as mandatory apparently confuses people into thinking "alg" should be the prime determinant when processing received JWS / JWE objects. Applications should actually specify this prime determinant, i.e. the header parameters to include to enable the recipient to verify / decrypt the object. For OpenID Connect that is "kid" for example.
>
> I agree with John that "kid" goes not guarantee correct implementations. But to me that's a different concern, and I don't think we can use that as an argument for / against the mandatory use of alg.
>
> I'm grateful Tim brought this up, to illustrate the importance of letting the application determine the actual required JOSE parameters, and how this may translate to better and safer implementations.
>
> I'm a bit sad that we haven't fully realised this, at some earlier stage, now that JOSE is almost final and is widely deployed.
>
> But I hope this could still flow into the new binary encodings and are being developed now.
>
>
> Cheers,
>
> Vladimir
>
>
>> On Thu, Apr 2, 2015 at 3:46 PM, John Bradley<[email-masked]>  wrote:
>>
> Vladimir Dzhuvinov ::[email-masked]
>
>

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 3 Apr 2015 20:57:37 +0000

nice stuff Tim
said that,

On Apr 1, 2015, at 9:01 PM, Tim McLean <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

I have been reviewing implementations of the JSON Web Token spec (draft-ietf-oauth-json-web-token), many of which are used in production systems, and have found that many of them allow an attacker to bypass the signature verification mechanism.

this is true. But is the string key also controlled my an attacker? In my experience not…

regards

antonio

In some libraries, specifying "alg":"none" will cause the verification to succeed and ignore the specified `key`.  In other cases, I can bypass RSA/ECDSA verification by tricking the library into using the public key as an HMAC secret.

I would like to propose deprecating the `alg` field.  Nearly every implementation that I've reviewed has trusted what algorithm was specified in the token.  They should be basing their choice of algorithm on how the key was intended to be used.  Without an `alg` field inside the token, implementers would need to ask their API users to specify what algorithm was expected -- perfectly mitigating these vulnerabilities.

I should point out that this proposal does not limit cryptographic agility.  The key ID field (`kid`) is adequate for this purpose.  Since keys should only ever be used with one algorithm (to avoid unexpected cryptographic interactions), determining which key to use implicitly determines which algorithm to use (since each key should be tied to its intended algorithm).  This means that JWT users can easily support multiple algorithms by supporting multiple keys, and transition between algorithms by transitioning between keys.

Cheers,
Tim McLean

PS: My apologies if this message was not sent to the right place -- I am new to IETF procedures.
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 04 Apr 2015 11:28:12 +0300

On 3.04.2015 12:39, Anders Rundgren wrote:
>> The evidence is that the alg / alg+enc parameters are not critical
>> and required in all cases, and therefore redundant, and could be
>> declared optional.
>>
> If everything is based on OOB-arrangements you can probably drop a
> bunch of parameters. If not don't you need alg to for example deal
> with RS256 and RS512 in a reasonable way?

One would need the "alg" for RSA signatures if we have the public RSA
key communicated OOB, but the algorithm is omitted. The JWK spec however
gives us the optional "alg" parameter to communicate precisely this. So
when a JWS is received, the "alg" can be obtained when one looks up the
public RSA JWK.

The argument is that including "alg" in the JWS header turns out to be
redundant in common real-world cases. And if this is true, then we can
regard it as optional :)

Consider OpenID Connect for example:

1. The provider publishes the public JWK set at a URL, and each key must
be given a "kid".
2. The ID token JWS "alg" is set by the "id_token_signed_response_alg"
parameter at client registration. For ID token JWE there is
"id_token_encrypted_response_alg" and "id_token_encrypted_response_enc".
3. The ID token JWS "kid" header parameter is required to select the JWK
for verification.

Which "alg" is actually used to validate the ID token - the one from the
JWS header or the one obtained at registration?

http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation :

"The alg value SHOULD be the default of RS256 or the algorithm sent by
the Client in the id_token_signed_response_alg parameter during
Registration."

"If the ID Token is encrypted, decrypt it using the keys and algorithms
that the Client specified during Registration that the OP was to use to
encrypt the ID Token. If encryption was negotiated with the OP at
Registration time and the ID Token is not encrypted, the RP SHOULD
reject it."

The JWS "alg" is not really required by OIDC, but it's there because
JOSE says it's mandatory.

> By making a things optional you effectively introduce additional

This is a matter of perspective I believe.

Image we looked at things this way:

1. Each application defines a trust model and corresponding process for
signing / verification (encryption / decryption).
2. JOSE provides a set of available parameters to pick from.
3. The application defines which ones are required and which not.

Let's consider OIDC again: There the "kid" is a required parameter to
allow the JWK to be looked up, even though JOSE says it's an optional
parameter.

The JWT claims spec provides a good analogy: A set of standard claims to
pick from, the application then defines which ones are must (e.g. iss,
sub, aud, exp in OIDC) and which optional.

Vladimir

> Anders
>
>>
>> That the alg / alg+enc parameters are currently specified as
>> mandatory apparently confuses people into thinking "alg" should be
>> the prime determinant when processing received JWS / JWE objects.
>> Applications should actually specify this prime determinant, i.e. the
>> header parameters to include to enable the recipient to verify /
>> decrypt the object. For OpenID Connect that is "kid" for example.
>>
>> I agree with John that "kid" goes not guarantee correct
>> implementations. But to me that's a different concern, and I don't
>> think we can use that as an argument for / against the mandatory use
>> of alg.
>>
>> letting the application determine the actual required JOSE
>> parameters, and how this may translate to better and safer
>> implementations.
>>
>>>> 3.  What key they used “kid”,  “jku” or implicit if there is only
>>>> one key
>>>> for a alg.
>>>>

---

From: John Bradley <[email-masked]>
Date: Sat, 4 Apr 2015 10:12:00 -0300

JOSE has wider applications than just connect. 

Even in connect alg is not required in JWK published by the AS.   

In other use cases people may be using x.509 Certs .   Those do need alg in the JWS to differentiate between the signing options available with a RSA key. 

Yes if Connect had required that alg be part of the key material in all cases then the alg in the JWS would be redundant. 

The thing is that if JOSE has alg in it at all an attacker can insert it. 

The recipient is always going to have to check if the alg and key are appropriate for the issuer. 

If the alg in the JWK and the JWS are different for a given keyID then that  is an error when processing a security token in my opinion. 

Something other than the low level JOSE library needs to validate the trust.  Always validating that you have the correct key for the issuer is an important part of that. 

Evaluating use in the JWK is also part of that.   If the RSA key is marked as encrypt then you need to throw an error and not return the key to verify a signature etc. 

JOSE itself doesn't impose a trust model. 

It may be that things we considered obvious like not using an encryption key to verify a signature, or don't return a key if the alg doesn't match any possible algs for that key type may need more explaining in a BCP of some sort. 

Perhaps we need to say that you should be passing in the key type, use and alg from the JWK if present to the JOSE lib so that it can do the check along with the acceptable algs for the issuer.  

There are other things like not accepting weak RSA keys as well. 

John B. 

Sent from my iPhone

> On Apr 4, 2015, at 5:28 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> 
> 
> One would need the "alg" for RSA signatures if we have the public RSA key communicated OOB, but the algorithm is omitted. The JWK spec however gives us the optional "alg" parameter to communicate precisely this. So when a JWS is received, the "alg" can be obtained when one looks up the public RSA JWK.
> 
> The argument is that including "alg" in the JWS header turns out to be redundant in common real-world cases. And if this is true, then we can regard it as optional :)
> 
> 1. The provider publishes the public JWK set at a URL, and each key must be given a "kid".
> 2. The ID token JWS "alg" is set by the "id_token_signed_response_alg" parameter at client registration. For ID token JWE there is "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc".
> 3. The ID token JWS "kid" header parameter is required to select the JWK for verification.
> 
> Which "alg" is actually used to validate the ID token - the one from the JWS header or the one obtained at registration?
> 
> "The alg value SHOULD be the default of RS256 or the algorithm sent by the Client in the id_token_signed_response_alg parameter during Registration."
> 
> "If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt the ID Token. If encryption was negotiated with the OP at Registration time and the ID Token is not encrypted, the RP SHOULD reject it."
> 
> The JWS "alg" is not really required by OIDC, but it's there because JOSE says it's mandatory.
> 
> 1. Each application defines a trust model and corresponding process for signing / verification (encryption / decryption). 
> Let's consider OIDC again: There the "kid" is a required parameter to allow the JWK to be looked up, even though JOSE says it's an optional parameter.
> 
> The JWT claims spec provides a good analogy: A set of standard claims to pick from, the application then defines which ones are must (e.g. iss, sub, aud, exp in OIDC) and which optional.
> 
> 
> 
> Vladimir
> 
> 
> 
> 
>> Anders 
>> 
>>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 04 Apr 2015 23:59:41 +0300

Hi John,

I agree with your points, there is way to have a tight and secure system
with JOSE at is it now. I have no doubts about this. It's just the
realisation that if "alg" was properly recognised as optional, it would
come as more obvious that JOSE doesn't impose a trust model and that
this is the application's job. And many security considerations, up the
security stack, would not have been necessary. But I guess we have to
live with this for now.

> Yes if Connect had required that alg be part of the key material in all cases then the alg in the JWS would be redundant. \
The ID token must be verified with the alg set at client registration
time, else RS256 is assumed. This is what the OIDC ID token verification
spec currently says.

There is no mention what to do if the RSA JWK alg clashes with that, but
the logical thing to do is also signal an error I suppose.

> Perhaps we need to say that you should be passing in the key type, use and alg from the JWK if present to the JOSE lib so that it can do the check along with the acceptable algs for the issuer.  

This is a good idea. I just re-read JWS / JWA -40 and I don't see this
explicitly mentioned.

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-40#section-5.2

Where would it be a good place to put this?

Vladimir