Add access token requirement for preventing "key confusion"

[TobiasAhnoff]

Add access token requirement for preventing "key confusion".

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

Verify that the cryptographic keys for tokens belong to the token issuer. If both symmetric (MAC) and asymmetric (digital signatures) algorithms needs to be supported, additional controls must prevent key confusion. For JWTs the 'iss' claim must be validated to be a preconfigured expected value.

[elarlang]

I don't think it is JWT or token specific requirement - those who have worked with V6 maybe can hint is this covered there already.

Also it is on the limit with the scope. You need to have access to issuer setup that is a bit out of scope from application point of view. And if you have access, then I think it is more a question of handling keys in general? (ping @randomstuff @danielcuthbert )

For tokens we additionally have or will have requirement for validating the 'iss' claim.

[elarlang]

"key confusion" is mentioned at the moment in current version of 3.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.

The requirement itself is discussed in the issue #2204 . Is this a recommendation to split the current 3.5.5, is it a duplicate of current 3.5.5 and should be closed or it provides some new aspect that is not covered yet?

[TobiasAhnoff]

The suggestion was to split split the current 3.5.5 and have "key confusion" together with "Verify that the cryptographic keys for tokens belong to the token issuer" and to provide an example for JWTs with "For JWTs the 'iss' claim must be validated to be a preconfigured expected value".

I think is is good to split, since "using strong alg" and "key confusion" are different things, you could use strong algs and still confuse keys.

[TobiasAhnoff]

Given that we decide to split, is this good as a requirement for the "key confusion" part?

Verify that the cryptographic keys for tokens belong to the token issuer. If both symmetric (MAC) and asymmetric (digital signatures) algorithms needs to be supported, additional controls must prevent key confusion. For JWTs the 'iss' claim must be validated to be a preconfigured expected value.

[randomstuff]

Would it be "needs to be supported" or "are supported"?

Maybe we need to say that this is for token verification (not generation)?

Verify that the cryptographic keys used for for token validation belong to the token issuer.

Nitpick, there is a missing comma:

Verify that the cryptographic keys for tokens belong to the token issuer. If both symmetric (MAC) and asymmetric (digital signatures) algorithms needs to be supported, additional controls must prevent key confusion. For JWTs, the 'iss' claim must be validated to be a preconfigured expected value.

[TobiasAhnoff]

Perhaps this?

Verify that the cryptographic keys used for token validation belong to the token issuer. If both symmetric (MAC) and asymmetric (digital signatures) algorithms are supported, additional controls must prevent key confusion. For JWTs, the 'iss' claim must be validated to be a preconfigured expected value.

[elarlang]

Some more clarifications to document:

1. how do you test/verify it?
2. how it is different from 3.5.7?

• V3.5.7 Verify that key material that is used to validate cryptographically secured tokens is from trusted pre-configured sources for the token issuer, preventing 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.

[randomstuff]

how it is different from 3.5.7?

3.5.7 is about using the correct cryptographic material for validating the token.

The one we are discussing here is supposed to be about key confusion but actually covers:

1. key confusion
2. correct cryptographic material

We should probably better focus on (1) and remove (2) from this requirement.

Alternatively or in addition, this might be part of a more general cryptography requirement about verifying that each key is used with its intended cryptographic usage:

• honoring key type and key usage
• for JWK, this would mean enforcing "kty", "use", "key_ops", "alg"
• for X.509, this would mean honoring key type, key usage, extended key usage

[TobiasAhnoff]

how it is different from 3.5.7?

Maybe 3.5.7 could include issuer claim, like this?

V3.5.7 Verify that key material that is used to validate cryptographically secured tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, the 'iss' claim and headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.

I think this would address the "key confusion" scenario as well.

It is also probably good to open a new issue for a "more general cryptography requirement about verifying that each key is used with its intended cryptographic usage" in V6

[ryarmst]

Just focusing on key confusion, if we look at the key confusion example from the WSTG, there are potentially two issues:

1. The JWT library permits verification without explicitly specifying an algorithm.
2. The application does not validate against an allow list of algorithms.

In theory, key confusion could still occur with (2) in place if an application needed to accept both symmetric and asymmetric algorithms. The issue can also occur even if the application uses a trusted key from a trusted source, so I think it should be separate from 3.5.7. @randomstuff I like the idea of abstracting this to ensure that keys are only used for intended purposes, but I think abstracting it will make it more challenging to implement and test as a requirement, so here is a first attempt just focusing on key confusion with JWTs as an example:

Verify that key material is only used with algorithms intended for it to prevent key confusion attacks. For JWTs, ensure that token verification operations explicitly specify which algorithm is to be used.

Concerning 3.5.5:

...If both symmetric and asymmetric are needed, additional controls should prevent key confusion.

I think it is worthwhile to have a more precise requirement instead of "additional controls should". As is, the core of 3.5.5 addresses (2) from my points above and then appends that last phrase to address (1).

[randomstuff]

For JWTs, ensure that token verification operations explicitly specify which algorithm is to be used.

Is this necessary? Would it be OK if I'm using algorithms=["ES384", "ES512"]? It might be enough to avoid mixing MACs and digital signature in the list of allowed algorithms.

Should we say "For example, for JWTs, …"?

[ryarmst]

Good point, how about something more specific to key confusion:

Verify that key material is only used with algorithms intended for it to prevent key confusion attacks. For example, JWT verification operations must not permit a public key to be used as an HMAC secret.

[tghosth]

Please see my comment here: #2360 (comment)

@ryarmst @TobiasAhnoff @randomstuff