Thanks for caring about the security of JOSE, Neil. I'll take one more shot at this, with replies inline...-----Original Message-----From: Neil Madden <[email protected]>Sent: Wednesday, March 6, 2024 12:10 AMTo: Michael Jones <[email protected]>Cc: Manu Sporny <[email protected]>; JOSE WG <[email protected]>Subject: Re: [jose] Deprecation of legacy algorithmsOn 5 Mar 2024, at 23:24, Michael Jones <[email protected]> wrote:
While this is been said many times before, it seems that it's time to say it again. The last point in the Message Signature or MAC Validation section at https://www.rfc-editor.org/rfc/rfc7515.html#section-5.2 is:
"Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid."
"alg":"none" can only cause a problem if the application fails to validate whether the algorithms used are appropriate for use by the application in that context. The need to validate whether "alg":"none" is appropriate is no different than the need to validate whether use of RSA1_5 is appropriate.
There are three big differences between these cases:
* alg:none provides no security properties, whereas all of the other algorithms do
Nor was it ever intended to - hence being called "none". :-) It's for use where security properties are unnecessary.
Or when attackers want to circumvent those security properties.
* alg:none doesn’t require a key, so will not be caught by checks on key type/algorithm
It's caught by the algorithm check when the recipient inspects the "alg" header parameter value.
But lots of libraries and applications fail to perform such a check. For the benefit of anyone that isn’t aware, here is a sample of some of the alg:none vulnerabilities from the last decade or so. There are almost certainly many more.
* alg:none purports to be a signature algorithm, but isn’t. Many developers don’t even know it exists.
It's fine that developers don't know it exists. If they don't know about it, it won't be in the list of acceptable "alg" values when they do the check, and therefore it will be rejected.
Oh, of course!
For example, OIDC says ID Tokens MUST be signed, which would imply to most people that they are always integrity protected. But somehow “none” is a valid signature algorithm.
Actually, I already cited the Connect spec text saying that "alg":"none" can be used when requested by the RP and the ID Token is sent over TLS from the Token Endpoint.
The full paragraph from section 2:
ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS[JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 16.14. If the ID Token is encrypted, it MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. ID Tokens MUST NOT use none as the alg value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of none at Registration time.
So “MUST be signed” but also somehow can use “none” in one limited circumstance 🤷♂️. Personally I read this spec paragraph as self-contradicting: “none” JWTs are not signed so are a violation of the first sentence.
An ID Token using "alg":"none" sent over a TLS connect is fine, because TLS makes it tamper-proof.
This not true.
It guarantees delivery of the issued ID Token without changes from the OP to the RP.
Apart from when redirects occur, or when there is more than one TLS hop, or when a cert has been misissued, or the cert is in the process of being revoked (allowed to take over a week in WebPKI), or in the presence of XSS, or … etc etc.
As it says at https://openid.net/specs/openid-connect-core-1_0.html#IDToken:
"ID Tokens MUST NOT use "none" as the "alg" value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of "none" at Registration time."
The context where the algorithm is used matters. In the above usage, "alg":"none" is safe and appropriate.
Sure, but just returning some JSON would also be fine. What benefit does it gain?
It gains the benefit that all ID Tokens have fields base64url-encoded in the same manner and that they are all URL safe. JSON is not URL safe.
And that use-case doesn’t return a token in a URL - because putting unsecured JWTs in a URL is unsafe!
The issues that have happened only happened in applications that didn't implement the algorithm appropriateness check in Section 5.2. If they're not doing it for "none", they probably aren't doing it for any algorithms, and so the application would still be vulnerable to using obsolete algorithms even if we deprecated "none".
Fix the broken applications. Don't remove essential functionality that's been a standard for nearly a decade and has been in production use longer than that.
This is the same reasoning as “C is a safe language, you’re just using it wrong”. We can’t keep having multiple critical vulnerabilities per year due to a feature that actually almost nobody intentionally uses.
Again, if you don't check the "alg" value, critical vulnerabilities will occur regardless. I view the presence of "none" as a not-so-subtle reminder to do just that. :-)As a counterpoint, while I was still there ForgeRock disabled “none” by default. As far as I’m aware nobody ever complained or even noticed. I’ve never met anyone who wants unsecured ID Tokens.
The last I knew, Deutsche Telekom uses "alg":"none" in their ID Tokens. In fact, the ability to do so was added to OpenID Connect when Torsten Lodderstedt was identity lead there. He wanted DT RPs to not need cryptographic code (other than the TLS stacks beneath them). It worked fine.
Finally, I know of other JOSE libraries that make you jump through special hoops to use "none" - somehow indicating that "I know what I'm doing" in the API. That's fine and I support that.
That's different than deprecating "none" in the algorithms registry, which would be an overly blunt instrument trying to take away useful and used functionality.
You have only named a single *possible* user of this functionality. This is not a compelling reason to keep it around.
— Neil |
