Modify 3.5.5 - split key confusion part to a separate requirement #2360

TobiasAhnoff · 2024-11-09T09:33:42Z

Add access token requirement for strong alg and "None" to mitigating risk of using weak or "none" algorithms to protect tokens

Verify that, for integrity protected tokens, only strong algorithms from an allow list can be used to create and verify the token. For JWTs, e g use PS256 and assert that 'None' value is not allowed for the 'alg' claim.

This is part of "cleaning up 3.5" see #1917 (comment)

elarlang · 2024-11-09T13:29:32Z

For me it is duplicated by current V3.5.5:

V3.5.5 Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion.

It went through long journy already in #2204.

If it is covered already by 3.5.5, please close this issue.

If there is need to improve current 3.5.5 to cover some missing aspect, then please re-open #2204 as previous discussion is held there.

If there is need for a new requirement, please provide information, what makes this new proposed requirement different and unique from 3.5.5.

ryarmst · 2024-11-11T15:54:50Z

Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms

This has always felt like a V6 requirement to me.

should not include the 'None' algorithm

Does this apply to more than JWTs?

elarlang · 2024-11-11T18:16:58Z

We also have V3.5.3 requirement on the topic:

Verify that stateless tokens use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents.

Direction is to have abstract requirement (not an access-token specific). If there are no new aspects from proposed new requirement, we can re-open related issues for 3.5.3 (#2184) and/or 3.5.5 (#2204 ) if needed to finetune something there.

TobiasAhnoff · 2024-11-13T06:33:21Z

The suggested changed here is related to #2361 (comment). If not "split" as suggested there, V3.5.3 (and V6) covers this as it is and this can be closed. If "split", V3.5.5 could be changed as suggested here.

TobiasAhnoff · 2024-11-16T09:13:03Z

Given that we decide to split (see #2361 (comment)), should we then have V3.5.3 to only address the "strong alg" part, and rewrite it like this?

Verify that, for cryptographically secured tokens, only strong algorithms from an allow list can be used to create and verify the token. For JWTs use in example PS256 and assert that 'None' value is not allowed for the 'alg' claim.

or is just add "strong" and removing "key confusion" from V3.5.3 better?

Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only strong either symmetric or asymmetric algorithms, and should not include the 'None' algorithm.

elarlang · 2024-11-16T18:44:40Z

I try to get overview of the situation.

We have current requirements that are made long journey to have those wordings:

#	Description	L1	L2	L3	CWE
3.5.3	[MODIFIED, LEVEL L2 > L1] Verify that cryptographically secured tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.	✓	✓	✓	345
3.5.5	[ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion.	✓	✓	✓	757

Now we have 2 issues (#2360, #2361) with titles "add new requirements" that actually going to replace/duplicate/modify current requirements.

@TobiasAhnoff - can you provide reasoning, arguments, and goals for what we should achieve here? If in practice we are going to modify existing requirements, it makes sense to declare it that way and re-open previous issues for those requirements.

TobiasAhnoff · 2024-11-17T09:01:08Z

@elarlang yes, some om the "add new" are modifications of existing and it it would be better to re-open those, add comments from "add new" issues and close the "add new".

elarlang · 2024-11-18T11:57:51Z

can you provide reasoning, arguments, and goals for what we should achieve here?

It would be helpful to have a direction to follow. At the moment it is quite messy (at least for me). There is one split proposal involved in another issue, but list here or somewhere else the set of requirements you propose with clear differences and modifications to existing requirements.

TobiasAhnoff · 2024-11-19T07:07:01Z

Given #2361 (comment) "key confusion" is suggested to be slit to a new requirement and can be removed from 3.5.5.

And then this issue is only to suggests a simplification of 3.5.5, to make it more clear that strong algorithms should be used and for JWTs 'None' should not be allowed, perhaps it can be like this

Verify that only strong algorithms on an allowlist can be used to create and verify cryptographically secured token. For JWTs, use in example PS256 and assert that 'None' is not allowed for the 'alg' claim.

So the title of this issue could be changed to "modify 3.5.5" or close this and re-open a previous issue and add comment there for the suggested modification.

Does that make a good summary?

tghosth · 2024-11-22T09:20:29Z

Having read through this thread and through #2361, it feels like this got a little complicated. I think we can boil this down to:

Only use allow listed algorithms, not included None.
Only use specific trusted keys or key sources for specific algorithms.
Only have strong algorithms on the allow list.

I would therefore suggest that the following modifications to 3.5.5 and 3.5.7 would close both #2360 and #2361.

#	Description	L1	L2	L3	CWE
3.5.5	[ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should only include algorithms which are considered strong according to current recommendations (such as PS256 for JWTs) and should not include a "no encryption" setting (such as the 'None' algorithms for JWTs.	✓	✓	✓	757
3.5.7	[ADDED] Verify that key material that is used to validate cryptographically secured tokens is only usable for specifically specified algorithms, to avoid key confusion attacks, and comes from trusted pre-configured sources for the token issuer, to prevent attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.	✓	✓	✓

I took out the symmetric/asymmetric thing because "only usable for specifically specified algorithms" should cover that.

Comments @ryarmst @TobiasAhnoff @randomstuff?

randomstuff · 2024-11-22T17:19:37Z

Three small comments:

I suggest changing "no encryption" to "no authentication" (which is the main concern here). JWA/JWT "None" is actually described as "No digital signature or MAC performed".
I am wondering if we need to say that the allowlist for token verfiication should only contain signature/MAC algorithms. Are there libraries where the user might erroneously allow "RSA-OAEP" for JWT verification (:upside_down_face:)?
@tghosth, I am wondering if the public-key/private key confusion scenario is clear enough if you remove the "symmetric/asymmetric thing"

TobiasAhnoff · 2024-11-24T10:54:54Z

I think it works to address both "Only use allow listed algorithms, not included None." and "Only have strong algorithms on the allow list." in V3.5.5 and have V3.5.7 to address "Only use specific trusted keys or key sources for specific algorithms." (which includes key confusion). Perhaps modify proposals in #2360 (comment), like this?

3.5.5
Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens. The allowlist should only include algorithms which are considered strong according to current recommendations (such as PS256 for JWTs) and must not allow integrity validation to be ignored (such as accepting the 'None' algorithm for JWTs).

3.5.7
Verify that key material is from trusted pre-configured sources for the token issuer. Assert that keys used to validate cryptographically secured tokens are only usable for specifically specified algorithms, to avoid key confusion attacks, and
prevent attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.

tghosth · 2024-11-24T17:48:31Z

I suggest changing "no encryption" to "no authentication" (which is the main concern here). JWA/JWT "None" is actually described as "No digital signature or MAC performed".

Looks like Tobias's updated draft covers this.

I am wondering if we need to say that the allowlist for token verfiication should only contain signature/MAC algorithms. Are there libraries where the user might erroneously allow "RSA-OAEP" for JWT verification (:upside_down_face:)?

I think we could add "for this purpose" to make it clearer.

@tghosth, I am wondering if the public-key/private key confusion scenario is clear enough if you remove the "symmetric/asymmetric thing"

I think once we say that keys should only be usable for specific algorithms then it solves it regardless.

Updated suggestions:

3.5.5
"Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens. The allowlist should only include algorithms which are considered strong for this purpose according to current recommendations (such as PS256 for JWTs) and must not allow integrity validation to be ignored (such as accepting the 'None' algorithm for JWTs)."

3.5.7
"Verify that key material comes from trusted, pre-configured sources for the token issuer and ensure that keys used to validate cryptographically secured tokens are only usable for specifically specified algorithms. This should prevent attackers from specifying untrusted sources and keys and prevent key confusion attacks. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources."

final comments @randomstuff @TobiasAhnoff @elarlang ?

elarlang · 2024-11-27T08:06:52Z

3.5.5

a nice to have thing, 1st and 2nd sentence overlap maybe a bit too much. Not a critical problem but there is potential to shorten it a bit.

"The allowlist should"

Should vs must?

Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens.

Verify that allowlisted algorithms are used to create cryptographically secured tokens.

ping @randomstuff - if I remember correctly, you proposed "create and verify", is my proposal lacking something?

3.5.7

Verify that key material comes from trusted, pre-configured sources for the token issuer and ensure that keys used to validate cryptographically secured tokens are ~~only~~ usable for ~~specifically~~ specified algorithms. This should prevent attackers from specifying untrusted sources and keys and prevent key confusion attacks. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.

only - not needed?
specifically - not needed?
should vs must?
"from specifying untrusted sources and keys and prevent key confusion attacks" - too many ands or missing comma? "from specifying untrusted sources and keys, and prevent key confusion attacks"

Is the actual scope for these requirements wider ("cryptographically secured tokens") than "self-contained" tokens?

randomstuff · 2024-11-27T13:11:07Z

Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens.

Verify that allowlisted algorithms are used to create cryptographically secured tokens.

The "verify" part may be the most important part. Even if the token issuer carefully handles the uses algorithms, a malicious attacker could try to forge malicious tokens using weaker ones. the verifier should not allow unexpected algorithms.

randomstuff · 2024-11-27T13:18:55Z

Is the actual scope for these requirements wider ("cryptographically secured tokens") than "self-contained" tokens?

Yes, if we have separate sections for these.

should vs must?

This probably be "must".

For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.

For x5u, a valid validation mechanism would be to validate that the certificate is trusted through some PKI infrastructure (but then there might be additional considerations to consider). Would the current wording, cover this use case? If not, do we need to add some wording to accommodate that?

TobiasAhnoff · 2024-11-27T21:03:55Z

should vs must?

I think it is a must for L2 and L3, but might be should for L1?

For x5u

I think this is covered, the main point is to not blindly follow urls in jku, x5u or jwk

randomstuff · 2024-11-28T20:43:11Z

At first sight, I like having separate requirements.

On the other hand if find it difficult to separate clearly the things that must be checked:

cryptographic material can be trusted for this token issuer and for this application-level usage;
cryptographic material is of the correct key type (eg. JWK kty such as "RSA", "EC");
cryptographic material is of the correct cryptographic usage (eg. JWK use or key_ops)).

randomstuff · 2024-11-28T20:48:03Z

For the first requirement, maybe:

Verify that when the application validates the authenticity of a cryptographically secured token, it only uses key material after it has ensured that this key material can be trusted for the intended usage by the intended token issuer. For JWTs and other JWS structures, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or kid, this header can for example be validated using an allowlist.

Wow that's long …

Changes:

make more explicit that that the applications verifies it can trust the key
you only need to validate JWT header you are using to resolve the key material
allow for other options outside of allowlist
- For x5u, one option would be validate against an allowlist.
- As discussed previously, another option would be to validate the certificate chain at x5u using a trusted root anchor. In this case, it's not x5u which is in an allowlist but the trust anchor.

Question: Should it apply to decryption of the token as well?

Question: Is it specific to secured token or is it valid anytime MAC or signature are used? (Should such as requirement go in V6?)

randomstuff · 2024-11-28T20:55:30Z

For the second requirement, maybe:

Verify that keys used to validate cryptographically secured tokens are only used for the specified cryptographic algorithms and usages, to prevent key confusion attacks. For keys in JWK format, this can be done by validating the kty, use, key_ops, alg headers.

Changes:

add the notion of usage of the key usage;
example of validation of JWK keys.

Things I considered but did not include:

example of public key in X.509 certificate.

Question:

"specified" or "intended" or both?

TobiasAhnoff · 2024-11-29T08:24:49Z

I think the second requirement is good, maybe add "intended" and write in the same format as the first one, like this:

Verify that when the application validates a cryptographically secured token, it only uses key material for the specified cryptographic algorithms and intended usages, to prevent key confusion attacks. For keys in JWK format, this can be done by validating the kty, use, key_ops, alg headers.

Maybe the first one could be a little "simplified" (without losing important aspects), perhaps like this (it also seems good to mention the iss claim?)

Verify that when the application validates a cryptographically secured token, it only uses key material that can be trusted (for the intended usages). For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or kid, this header can be validated using an allowlist.

Perhaps remove "(for the intended usages)" and " (to be a preconfigured expected value)" to make it shorter?

Should it apply to decryption of the token as well?

I think maybe that could be part of V6, and requirements here are focused on the integrity of the token (even if encrypting a token is one way to assert that it can be trusted). @randomstuff do you have a requirement in mind?

Is it specific to secured token or is it valid anytime MAC or signature are used? (Should such as requirement go in V6?)

I think it is good to have this in a section specific for secured "self-contained" tokens, but maybe there should also be more generic requirements addressing MAC or signature in general in V6? (maybe open a separate V6 issue for this)

randomstuff · 2024-11-29T08:32:44Z

Note, some wording found in the JWT RFC which might be a source inspiration in the wording:

In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT.

TobiasAhnoff · 2024-11-30T19:04:05Z

I try to summarize this, we have 3 requirements (given that we split 3.5.7 and I updated to use the JWT RFC wording), is this good?

3.5.5

Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens. The allowlist should only include algorithms which are considered strong for this purpose according to current recommendations (such as PS256 for JWTs) and must not allow integrity validation to be ignored (such as accepting the 'None' algorithm for JWTs).

3.5.7 split to

Verify that when the application validates a cryptographically secured token, it only uses key material for the specified cryptographic algorithms and intended usages, to prevent key confusion attacks. For keys in JWK format, this can be done by validating the kty, use, key_ops, alg headers.

Verify that when the application validates a cryptographically secured token, it only uses key material that under the control of the party identified as the issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or kid, this header can be validated using an allowlist.

jmanico · 2024-11-30T20:19:45Z

Verify that when the application validates a cryptographically secured token, it only uses key material that under the control of the party identified as the issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or kid, this header can be validated using an allowlist.

When using digital signatures, the verifying key is typically the public key. Losing this key in this situation does not seem like a high impact event in some situations. Just a side note.

randomstuff · 2024-11-30T23:27:43Z

When using digital signatures, the verifying key is typically the public key. Losing this key in this situation does not seem like a high impact event in some situations. Just a side note.

I think the intent was to say that the corresponding private key was under the control of the party :)

TobiasAhnoff · 2024-12-01T08:12:23Z

When using digital signatures, the verifying key is typically the public key. Losing this key in this situation does not seem like a high impact event in some situations. Just a side note.

I think the intent was to say that the corresponding private key was under the control of the party :)

Yes, maybe make this clearer like this?

Verify that when the application validates a cryptographically secured token, it only uses signing key material that is under the control of the party identified as the issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or kid, this header can be validated using an allowlist.

or

Verify that when the application validates a cryptographically secured token, it only uses key material where the corresponding private signing key is under the control of the party identified as the issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or kid, this header can be validated using an allowlist.

jmanico · 2024-12-01T12:16:41Z

I think signing key is fine. But just to be a bit more pedantic, sometimes the integrity algorithm is a HMAC and in that case there is no signing, it’s a MAC/Hash. 👋🏽

TobiasAhnoff · 2024-12-01T12:25:05Z

True, wording is hard :) In 3.5.5 it is suggested to use the term "integrity validation", perhaps use something like that here as well?

Verify that when the application validates a cryptographically secured token, it only uses key material for integrity validation that is under the control of the party identified as the issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or kid, this header can be validated using an allowlist.

randomstuff · 2024-12-01T17:06:44Z

integrity validation

I think it should be "authenticity validation" instead (?).

[…] kid, this header can be validated using an allowlist.

Validating kid against an allowlist is quite vague and possibly not that useful depending on what we intend exactly. On a second thought, I think 'kid' maye not be that relevant in this requirement after all (in general).

tghosth · 2024-12-02T10:42:27Z

Ok, I think we have the current wording. Note the change to requirement numbers as we now have a new chapter and section V52.1:

52.1.2 (previously 3.5.5)
Verify that only algorithms on an allowlist are used to create and verify cryptographically secured tokens. The allowlist must only include algorithms which are considered strong for this purpose according to current recommendations (such as PS256 for JWTs) and must not allow integrity validation to be ignored (such as accepting the 'None' algorithm for JWTs).

52.1.3 (previously part of 3.5.7)
Verify that when the application validates a cryptographically secured token, it only uses key material for the specified cryptographic algorithms and intended usages, to prevent key confusion attacks. For keys provided in JWK format, this can be done by validating the 'kty', 'use', 'key_ops', or 'alg' headers.

52.1.4 (previously part of 3.5.7)
Verify that when the application validates a cryptographically secured token, it only uses key material that is under the control of the token issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained from a header such as 'jku', 'x5u', 'jwk' or 'kid', this header can be validated using an allowlist.

Comments on changes:

I made minor tweaks to 52.1.2 (bolded).
In 52.1.4:
- We say validates and I don't think we need to further specify what the key material is used for
- I think "token issuer" is sufficiently clear
- I left in kid as this seems like a very relevant header (@randomstuff could you expand on your objection?)
- I think saying allowlist is vague but clear and I prefer that wording.

randomstuff · 2024-12-02T15:31:18Z

I left in kid as this seems like a very relevant header (@randomstuff could you expand on your objection?)

Relevant snippet:

a header such as 'jku', 'x5u', 'jwk' or 'kid' [...] this header can be validated using an allowlist.

kid is usually used to reference one of the keys found in the jku. In this case, it's really jku that must be allowlisted and it does not make sense to allowlist kid (?).

Are there cases where allowlisting the kid really makes sense?

TobiasAhnoff · 2024-12-02T16:06:02Z

To me, 52.1.2 and 52.1.3 looks good, in 52.1.4 I think 'kid' could be removed.

Then one question remains: Should we use "integrity" or "authenticity"? I think both can be used, but it should/shall be the same terminology in 52.1.2 and 52.1.4, "authenticity" is good since it implies more than just integrity (that it can not be changed without validation failure), I agree with @randomstuff and vote for "authenticity" in both 52.1.2 and 52.1.4.

tghosth · 2024-12-02T17:02:40Z

Are there cases where allowlisting the kid really makes sense?

Is there not a possibility of using kid without using jku?

For example, this is a JWT produces by Google Identity:

Headers = {
  "alg": "RS256",
  "kid": "3fd072dfa3805679f16fe41738c2a3ad3f90b214",
  "typ": "JWT"
}

Payload = {
  "iss": "https://securetoken.google.com/blahblah-development",
  "aud": "blahblah-development",
  "auth_time": 1733158824,
  "user_id": "H5oiN2ROdfdsfdsfsdfsdfOgGrNttZYgF3",
  "sub": "H5oiN2RsdfdsfdsfdsfdsfrNttZYgF3",
  "iat": 1733158824,
  "exp": 1733162424,
  "email": "[email protected]",
  "email_verified": true,
  "firebase": {
    "identities": {
      "email": [
        "[email protected]"
      ]
    },
    "sign_in_provider": "password",
    "tenant": "blahblah-taaaak"
  }
}

Signature = "LKg9cVG5tx0BO5f3hEAwhrgymEOKefTmRJUiYnilA8n3EN2oBGIQpheyz4y-2OQcUmztaiiharwibxgVKg"

Then one question remains: Should we use "integrity" or "authenticity"? I think both can be used, but it should/shall be the same terminology in 52.1.2 and 52.1.4, "authenticity" is good since it implies more than just integrity (that it can not be changed without validation failure), I agree with @randomstuff and vote for "authenticity" in both 52.1.2 and 52.1.4.

So my suggestion was to side step the issue and just say validate, do we need to include "integrity" or "authenticity"?

TobiasAhnoff · 2024-12-02T17:54:07Z

So my suggestion was to side step the issue and just say validate, do we need to include "integrity" or "authenticity"?

that works as well, given that not adding "signing" (or anything else) is ok (see #2360 (comment)).

Is there not a possibility of using kid without using jku?

Yes, it is in my experience the most common case. But I think @randomstuff (and I) argue that validating kid is a bit different from validating 'jku' or 'x5u' and it might be confusing to say that 'kid' should be validated against an allowlist in the same way as 'jku' or 'x5u'. But 'kid' needs to be used to look up the matching key from the key set, so in a way it is a look up from a dynamic allowlist retrieved from the authorization server. Perhaps remove 'kid', keep as is or add something like this:

52.1.4 (previously part of 3.5.7)
Verify that when the application validates a cryptographically secured token, it only uses key material that is under the control of the token issuer. For JWTs and other JWS structures the 'iss' claim must be be validated (to be a preconfigured expected value), 'kid' must map to a valid key from the issuer key set and, if the key material is obtained from a header such as 'jku', 'x5u' or 'jwk' , this header must be validated using an allowlist.

Or is this too long? Must or should/can?

tghosth · 2024-12-02T18:16:26Z

It feels more complicated than necessary, I can accept that maybe there is a minor conceptual difference but I don't think it is worth overcomplicating the requirement for.

So I say stick with this, with some minor tweaks (in bold):

52.1.4 (previously part of 3.5.7)
Verify that when the application validates a cryptographically secured token, it only uses key material that is under the control of the token issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained based on a header such as 'jku', 'x5u', 'jwk' or 'kid', this header must be validated using an allowlist.

randomstuff · 2024-12-02T19:26:51Z

Then one question remains: Should we use "integrity" or "authenticity"? I think both can be used, but it should/shall be the same terminology in 52.1.2 and 52.1.4, "authenticity" is good since it implies more than just integrity (that it can not be changed without validation failure)

I think what we want here is authenticity i.e. than the message was created by some identified issuer (and was not modified). This is why we must validate the key based on the issuer.

Integrity would only mean that the message was not altered bot not that it was generated by the intended issuer.

randomstuff · 2024-12-02T19:34:32Z

Verify that when the application validates a cryptographically secured token, it only uses key material that is under the control of the token issuer. For JWTs and other JWS structures the 'iss' claim must be be validated (to be a preconfigured expected value), 'kid' must map to a valid key from the issuer key set and, if the key material is obtained from a header such as 'jku', 'x5u' or 'jwk' , this header must be validated using an allowlist.

I think what we want here is authenticity i.e. than the message was created by some identified issuer (and was not modified). This is why we must validate the key based on the issuer.

… then there is the case a proof of possession tokens.

For example, in OAuth DPoP Pushed Authorization Token Request, the DPoP token is only used to prove ownership of a private key. We do not verify the binding of this private key to any owner. We do not need to validate the jwk header against an allowlist at all at this point.

The requirement as currently worded arguably does not apply in this case (in particular "must be validated using an allowlist").

The "that is under the control of the token issuer" id discutable as well. (Though we might argue that it actually works in the sens that the issuer is whoever issues the authorization request …).

TobiasAhnoff · 2024-12-04T06:27:22Z

… then there is the case a proof of possession tokens.

Yes, allowlist validation applies to 'jku' and 'x5u'. Since we have "such as", a suggestion (to keep it easy to read, we can´t fit "all" JWT use cases etc in one clear actionable requirement), is to simply remove 'jwk' from the list of claims and if needed add a separate requirement for validating 'jwk'.

Verify that when the application validates a cryptographically secured token, it only uses key material that is under the control of the token issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained based on a header such as 'jku', 'x5u' or 'kid', this header must be validated using an allowlist.

or, also remove 'kid' ("such as" implies that the list of claims in not complete)

Verify that when the application validates a cryptographically secured token, it only uses key material that is under the control of the token issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained based on a header such as 'jku' or 'x5u', this header must be validated using an allowlist.

The "that is under the control of the token issuer" id discutable as well

This is from the RFC, I think it works, @randomstuff do you have a suggestion on how to improve this or can elaborate some more on why it needs to change?

tghosth · 2024-12-04T07:07:58Z

@randomstuff can I request that if you have a query on a proposed wording, you provide an updated wording.

For my perspective, this has gotten a quite niche and complicated and I think we need to make sure we are not losing clarity in order to cover every niche case.

@TobiasAhnoff I really think that jwk and kid are useful in the vast majority of cases and I don't see why we would remove them and I don't want a separate requirement on jwk.

I would suggest the following which excludes DPoP and then if necessary talk about DPoP in v51:

Verify that when the application validates a cryptographically secured token (except for a DPoP proof JWT), it only uses key material that is under the control of the token issuer. For JWTs and other JWS structures the iss claim must be be validated (to be a preconfigured expected value) and, if the key material is obtained based on a header such as 'jku', 'x5u', 'jwk' or 'kid', this header must be validated using an allowlist.

randomstuff · 2024-12-04T14:48:41Z

can I request that if you have a query on a proposed wording, you provide an updated wording.

Yes sorry, I wanted to raise the issue but I'm not sure whether this is clear enough already as it was and whether there is a need to have a wording with is actually accurate for this corner case. I'll try to propose something.

For my perspective, this has gotten a quite niche and complicated and I think we need to make sure we are not losing clarity in order to cover every niche case.

Yes, I agree.

except for a DPoP proof JWT

I'm not so fan of adding this explicit exception ("for DPoP") though, I'd better have a general wording but I'm not yet sure how to formulate it. We can probably say it's good enough as it is.

randomstuff · 2024-12-04T20:55:26Z

Some comments:

"validate a token" is quite vague
- For example to a validate an tokenwhich has been public-key-encrypted, we might need to decrypt it which means that we have to use cryptographic material in our contro, not on the issuer's control.
- Can we say "validate the authenticity of a token" instead?
The iss claim is defined for JWT but I'm not sure whether it is defined for for JWS in general (but JWE allows replicating claims in the header when they are needed to decrypt the JWE) so our wording does not really completely makes sense for JWS.

Proposition:

Verify the application validates the authenticity of a cryptographically secured token based on key material that is bound to the token issuer. For JWTs and other JWS structures, if the application resolves the key material based on the 'jku', 'x5u' or 'kid' headers, it must interpret and validate (for example using an allowlist) these values depending on the token issuer.

elarlang · 2024-12-05T05:59:20Z

This is the 50th comment in this issue, it's a bit of a sign that the direction is not clear.

If we are not close to the proposal, I would like to recommend that first there is a clear written "problem to solve" for the requirement and then we can find out how to achieve this.

If there are too many different edge cases or technologies to take into account, it is worth writing separate requirements first and then merging, if those are clearly overlapping.

tghosth · 2024-12-05T09:25:19Z

I think the most recent proposal is good enough.

Key points:

I think authenticity is good.
We lost jwk in the most recent proposal but I think we should have it.

Opened #2431

TobiasAhnoff mentioned this issue Nov 9, 2024

cleanup V3.5 Token-based Session Management #1917

Closed

elarlang added V3 V51 Group issues related to OAuth labels Nov 9, 2024

elarlang removed the V51 Group issues related to OAuth label Nov 9, 2024

elarlang assigned TobiasAhnoff Nov 9, 2024

elarlang added 2) Awaiting response Awaiting a response from the original poster _5.0 - prep This needs to be addressed to prepare 5.0 labels Nov 9, 2024

This was referenced Nov 19, 2024

review V51.4.2 - OAuth and OIDC audience restrictions for tokens #2182

Closed

Where to move or what to do with V3.5 section (tokens section in session management chapter) #2384

Closed

elarlang changed the title ~~Add access token requirement for strong alg and "None"~~ Modify 3.5.5 - split key confusion part to a separate requirement Nov 19, 2024

elarlang added 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet and removed 2) Awaiting response Awaiting a response from the original poster labels Nov 19, 2024

tghosth mentioned this issue Nov 22, 2024

Add access token requirement for preventing "key confusion" #2361

Closed

tghosth added a commit that referenced this issue Dec 5, 2024

Clarify token validation to resolve #2360

69ab331

tghosth mentioned this issue Dec 5, 2024

Clarify token validation to resolve #2360 #2431

Merged

tghosth closed this as completed in fb17168 Dec 5, 2024

Modify 3.5.5 - split key confusion part to a separate requirement #2360

Modify 3.5.5 - split key confusion part to a separate requirement #2360

Comments

TobiasAhnoff commented Nov 9, 2024

elarlang commented Nov 9, 2024

ryarmst commented Nov 11, 2024 • edited Loading

elarlang commented Nov 11, 2024

TobiasAhnoff commented Nov 13, 2024

TobiasAhnoff commented Nov 16, 2024

elarlang commented Nov 16, 2024

TobiasAhnoff commented Nov 17, 2024

elarlang commented Nov 18, 2024

TobiasAhnoff commented Nov 19, 2024

tghosth commented Nov 22, 2024

randomstuff commented Nov 22, 2024

TobiasAhnoff commented Nov 24, 2024

tghosth commented Nov 24, 2024 • edited Loading

elarlang commented Nov 27, 2024

randomstuff commented Nov 27, 2024

randomstuff commented Nov 27, 2024 • edited Loading

TobiasAhnoff commented Nov 27, 2024

randomstuff commented Nov 28, 2024

randomstuff commented Nov 28, 2024 • edited Loading

randomstuff commented Nov 28, 2024

TobiasAhnoff commented Nov 29, 2024

randomstuff commented Nov 29, 2024 • edited Loading

TobiasAhnoff commented Nov 30, 2024

jmanico commented Nov 30, 2024 via email

randomstuff commented Nov 30, 2024 • edited Loading

TobiasAhnoff commented Dec 1, 2024

jmanico commented Dec 1, 2024 via email

TobiasAhnoff commented Dec 1, 2024

randomstuff commented Dec 1, 2024

tghosth commented Dec 2, 2024

randomstuff commented Dec 2, 2024

TobiasAhnoff commented Dec 2, 2024 • edited Loading

tghosth commented Dec 2, 2024 • edited Loading

TobiasAhnoff commented Dec 2, 2024 • edited Loading

tghosth commented Dec 2, 2024

randomstuff commented Dec 2, 2024

randomstuff commented Dec 2, 2024 • edited Loading

TobiasAhnoff commented Dec 4, 2024

tghosth commented Dec 4, 2024

randomstuff commented Dec 4, 2024

randomstuff commented Dec 4, 2024 • edited Loading

elarlang commented Dec 5, 2024

tghosth commented Dec 5, 2024

ryarmst commented Nov 11, 2024 •

edited

Loading

tghosth commented Nov 24, 2024 •

edited

Loading

randomstuff commented Nov 27, 2024 •

edited

Loading

randomstuff commented Nov 28, 2024 •

edited

Loading

randomstuff commented Nov 29, 2024 •

edited

Loading

randomstuff commented Nov 30, 2024 •

edited

Loading

TobiasAhnoff commented Dec 2, 2024 •

edited

Loading

tghosth commented Dec 2, 2024 •

edited

Loading

TobiasAhnoff commented Dec 2, 2024 •

edited

Loading

randomstuff commented Dec 2, 2024 •

edited

Loading

randomstuff commented Dec 4, 2024 •

edited

Loading