Re: [OAUTH-WG] OAuth GREASE

I will point out that OpenID Connect certification tests that the implementation ignores not-understood request parameters.  So at least all the authorization servers that are also certified OpenID Connect implementations should be successfully ignoring not-understood parameters.

I’d personally point out these non-compliant behaviors to the vendors and ask them to fix them.  Their non-compliance makes it harder for clients to interoperate with them, hurting both.  Name names, if that’s what it takes.

                                                       -- Mike

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Neil Madden
Sent: Thursday, April 23, 2020 2:30 AM
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth GREASE

If a clients sends a handful of random additional parameters on authorization requests a compliant AS will already ignore them, so there should be no additional burden on the AS.

However, the ship may already have sailed on the specific issue of request parameters, as there are major deployed services already rejecting unknown parameters. (I won’t name them, but probably a fair proportion of people on this list have an account with at least one of them). Of course, even if they eventually do enable PKCE we won’t start using it until we notice and remove them from the blacklist, so this harms security as well as interoperability.

I’m not saying the situation is anywhere near as bad for OAuth as it is for TLS with all the incompatible middleboxes, but there are definitely some other areas of potential ossification:

- I know of services that error if a published JWKSet has more than one key in it
- some error if there’s a JWK with an unknown “kty” (e.g “okp”) even if they don’t need to use that JWK, same for unknown “crv” values
- there are clients that error if any value in the id_token_signing_alg_values_supported is not one of the original JWS signing algorithms (e.g., “EdDSA”), making it hard to adopt a new signature algorithm

(Basically there are quite a few clients that use JSON mapping tools with enum types - List<JWSAlgorithm>. I know there are parts of our own codebase where we do this too).

I was only semi-serious about GREASE, but I think this is a problem that will only get worse over time.

— Neil

On 23 Apr 2020, at 08:54, Vladimir Dzhuvinov <vladimir@connect2id.com<mailto:vladimir@connect2id.com>> wrote:

I get your frustration with PKCE. It would be a bad policy and example to burden compliant ASes with additional stuff just because a few AS implementations are not complying with the spec. It's not fair and can end up creating all sorts of bad incentives in future.
Vladimir
On 22/04/2020 10:29, Neil Madden wrote:
Section 3.1 of RFC 6749 says (of the authorization endpoint):

The authorization server MUST ignore

   unrecognized request parameters.

We hoped to be able to use this to opportunistically apply PKCE - always send a code_challenge in the hope that the AS supports it and there should be no harm if it doesn’t.

Sadly I learned yesterday of yet another public AS that fails hard if the request contains unrecognised parameters. It appears this part of the spec is widely ignored.

Given that this hampers the ability to add new request parameters in future, do we need our own GREASE to prevent these joints rusting tight?

https://www.rfc-editor.org/rfc/rfc8701.html<https://www..rfc-editor.org/rfc/rfc8701.html>

— Neil

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth