On 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 * alg:none doesn’t require a key, so will not be caught by checks on key type/algorithm * alg:none purports to be a signature algorithm, but isn’t. Many developers don’t even know it exists. 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. > > An ID Token using "alg":"none" sent over a TLS connect is fine, because TLS > makes it tamper-proof. This not true. > 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? > > 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. 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. — Neil _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
