Modify 3.5.5 - split key confusion part to a separate requirement

[TobiasAhnoff]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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 ?