test for long 'nonce' parameter

[jogu]

We ran into an interoperability problem where the RP was passing a 300 byte nonce and the OP only supported up to 100 bytes. The OP is OIDF certified.

By my reading of the OpenID connect specification, no limit is placed on the length of nonce, so I think it would be reasonable to add a test that has a (say) 1000 byte nonce.

[jogu]

For what it's worth, https://gitlab.com/fintechlabs/fapi-conformance-suite has a few tests that use 128 byte states, but it never occurred to us to test nonces that long. I think given we've now seen 300 byte nonces we should also be testing states longer than 128 bytes.

[zandbelt]

For the record the spec doesn't say anything about the length https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes, there's probably room for improvement there.

For interoperability purposes and to avoid hitting browser or server limitations we may add a nonce length test to the suite, or perhaps even a generic maximum parameter length check including state, request and request_uri, and/or a maximum URL length test.

The spec does mention request URI length in:
https://openid.net/specs/openid-connect-core-1_0.html#RequestUriParameter

The entire Request URI MUST NOT exceed 512 ASCII characters.

and the request URL length for a Self-Issued OpenID Provider Request:
https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedRequest

The entire URL MUST NOT exceed 2048 ASCII characters.

The URL length of the total Authorization Request across all cases should stay under 2000 characters, see:
https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers
and:
http://www.boutell.com/newfaq/misc/urllength.html

[jogu]

Further info: we found one of the UK CMA9 banks (Lloyds) seems to have a hard limit on the URL length of 2069 characters, above which something (probably a gateway in front of the AS) returns "Request-URI Too Long The requested URL's length exceeds the capacity limit for this server."

A fairly generic request from the OB conformance suite uses ~1500 bytes (mainly due to the size of the signed request object), so there's a relatively small margin for using longer states or nonces. (Here's an example with a 128 byte state: https://fapidev-as.authlete.net/api/authorization?request=eyJraWQiOiJyMGxCRzRYeDZVM1ZPXzNpWkRaUW8wQTJLUmdsQlEweFYyRTBaQzVtbm9jIiwidHlwIjoiSldUIiwiYWxnIjoiUFMyNTYifQ.eyJhdWQiOiJodHRwczpcL1wvZmFwaWRldi1hcy5hdXRobGV0ZS5uZXRcLyIsInNjb3BlIjoib3BlbmlkIGFjY291bnRzLW9iIiwiY2xhaW1zIjp7ImlkX3Rva2VuIjp7ImFjciI6eyJ2YWx1ZSI6InVybjpvcGVuYmFua2luZzpwc2QyOnNjYSIsImVzc2VudGlhbCI6dHJ1ZX0sIm9wZW5iYW5raW5nX2ludGVudF9pZCI6eyJ2YWx1ZSI6ImUwMTRiZjEyLTVmM2EtNDI2YS1hODM0LThjMmRlNDBmZDY2NCIsImVzc2VudGlhbCI6dHJ1ZX19fSwiaXNzIjoiMzA0MjU1NzQ3MzkiLCJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOlwvXC9maW50ZWNobGFicy1mYXBpLWNvbmZvcm1hbmNlLXN1aXRlLXN0YWdpbmcuZmludGVjaGxhYnMuaW9cL3Rlc3RcL2FcL2ZpbnRlY2gtYXV0aGxldGVcL2NhbGxiYWNrP2R1bW15MT1sb3JlbSZkdW1teTI9aXBzdW0iLCJzdGF0ZSI6IndjbllkVFJnbFJHRWVrcGlXaTZGNXN1OWZKemZ3THFRMDBZelFvRDNuNHVZZ2tWQ0o3b0ZKZjZuU2lJdmhoeVl2U0xESURERjhGVUR0WGpyVExJVnpPN3B3d3ZRQVNsZ1g1TVkwd3A2UEpsb0U3OWtkZDU5WGpCVFdvMXc2YTR2IiwiZXhwIjoxNTQwMTgzNDc0LCJub25jZSI6ImV5QlZJaVN6dmsiLCJpYXQiOjE1NDAxODMxNzQsImNsaWVudF9pZCI6IjMwNDI1NTc0NzM5In0.qaCaJ7THYniir45No5Ot2Fvs419pfmlm_Sk0_MfradXH6arp57PXp2_jTFLZjUvXh-454kaV5I1aTx75Hv3C5LKGjLQV6-rQlBvAyvv9dN-1Eu35CMO0q4pVKlJeAja1Sh0oYMIElJIbJIk1C0thTEz-JfAF8TqabIsFOOc0_XHD1AJUECbIXdSB-4pvi-nc4qkZYmEdjz6wBhAhrunj8ZAZMX_9DXTdZdDFMJbybNEqu6jBozgn5FO-GYtiHo6bcbFek3k8dI_1yllD-1ER7K1QzUOxw5dH9H2DRMrzGMO3P7rf5Qq8MzM-TVou2sZvi8P3MwZjikMaoqdDWmVHmQ&client_id=30425574739&redirect_uri=https://fintechlabs-fapi-conformance-suite-staging.fintechlabs.io/test/a/fintech-authlete/callback?dummy1%3Dlorem%26dummy2%3Dipsum&scope=openid%20accounts-ob&response_type=code%20id_token )

[selfissued]

It's probably worth filing an issue for the Connect spec itself at https://bitbucket.org/openid/connect/issues talking about the possible need to have practical limits for the entire request.

[jogu]

Thanks Mike. I've raised https://bitbucket.org/openid/connect/issues/1055/limits-on-overall-url-length

[sakimura]

And exactly to cater this kind of cases, we have something called request_uri in OpenID Connect and forthcoming OAuth JAR.

[zandbelt]

@sakimura well not exactly: although in principle (and by design) those can be used to mitigate request URL length issues, there are actually no boundaries specified there either so it is still up in the air. Even the JAR draft only implicitly addresses this by restricting the length of only one parameter and mentioning the maximum URL length for a particular browser. More restrictive text is needed.

[jogu]

I believe there is a boundary in https://openid.net/specs/openid-connect-core-1_0.html#RequestUriParameter :

The entire Request URI MUST NOT exceed 512 ASCII characters.

(I'd say the bigger issue is that request_uri isn't supported in many real world deployments :-) )

[zandbelt]

It is not clear whether this is about the request_uri parameter value lenght or about the total authorization request length. For the latter it should allow 2000.

[sakimura]

This is on request_uri parameter value. There is no limit the specification to the length of each parameter in the specification. Some of them can be pretty big depending on the nature of the claim. When you are not using request_uri, there is an implicit length limit due to the (old) browser limitations. Some browsers has/had 2046 or so bytes limitation on the entire URI length. That browser was pretty common, so it was a practice at the time to factor that into in designing the parameters values.

…

On Fri, Nov 2, 2018 at 3:34 AM Hans Zandbelt ***@***.***> wrote: It is not clear whether this is about the request_uri parameter value lenght or about the total authorization request length. For the latter it should allow 2000. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#134 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJSN4ZNyIDU6M2WWH6dyaZKKO-bn-W3ks5uqz6agaJpZM4XHyL3> .

-- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en

[zandbelt]

So yes, there's a limit on the request_uri value but when this value is sent to the OP it may still result in an authorization request value that is truncated by browsers since it may contain state/nonce or may just overrun because the authorization endpoint URL is 1800 characters long itself...

[panva]

I don’t think we should be testing for something not in the specs and at most it should be giving recommendations, not impose limits on these parameters. I believe we can agree there are more pressing topics to spend time on in this area, e.g. actually giving OP/RP assurances that request object is used and no downgrade on the auth request can happen or #92 actually testing the OPs are using the params from request objects.

[zandbelt]

I disagree: firstly the spec should be extended, secondly the test suite is not just about spec compliance, it also for increasing interoperability and this is a real problem, albeit with somewhat lower priority indeed.

[panva]

Once the spec is updated with new requirements or recommendations, sure. Agreed on the prio.