[OAUTH-WG] Protocol Action: 'OAuth 2.0 Authorization Server Issuer Identification' to Proposed Standard (draft-ietf-oauth-iss-auth-resp-04.txt)

The IESG has approved the following document: - 'OAuth 2.0 Authorization Server Issuer Identification' (draft-ietf-oauth-iss-auth-resp-04.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Roman

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

On Wed, Jan 5, 2022 at 5:51 PM George Fletcher wrote: > So it seems to me, two factors need to be present for something "bad" to > happen... > > 1. The client always sends PKCE but the AS doesn't require the client to > use PKCE > 2. The client must accept uninitiated authorization response messa

Re: [OAUTH-WG] [Editorial Errata Reported] RFC8707 (6810)

Seems legit. On Wed, Jan 5, 2022 at 5:03 AM RFC Errata System wrote: > The following errata report has been submitted for RFC8707, > "Resource Indicators for OAuth 2.0". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid68

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

So it seems to me, two factors need to be present for something "bad" to happen... 1. The client always sends PKCE but the AS doesn't require the client to use PKCE 2. The client must accept uninitiated authorization response messages (i.e. from the attacker) If either of the above are not t

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

Hi Roman, Thanks for getting back to me - I'm somewhat out of my depth here, but really I think that I find this sentence to be somewhat ambiguous: "the use and verification of the iss parameter is not necessary and MAY be omitted." I read this as allowing both: (i) a send can choose to not i

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

The PKCE downgrade attack is the converse, here we are adding in PKCE where there was none. An attacker can thus send the victim the authorization response, after the > victim clicks the link, the client application sends a Token Request with > the code_verifier present with the client to Keycloak

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

Hi Rob! Thanks for your review. I wanted to close the loop on your COMMENT. See below. > -Original Message- > From: OAuth On Behalf Of Robert Wilton via > Datatracker > Sent: Tuesday, November 30, 2021 5:31 AM > To: The IESG > Cc: oauth@ietf.org; draft-ietf-oauth-iss-auth-r...@ietf.org

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

Greetings, Is this scenario any different from a PKCE downgrade attack, as described in OAuth 2.0 Security Best Current Practice section 4.8.2 ? Warm regards and happy new year! Christopher Burroughs Original Message On Jan 5, 2022, 21:29, Benjamin Häublein wrote: > The foll

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

The following example shows this behavior in keycloak: Authorization Request: http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce&redirect_uri=http%3A%2F%2Flocalhost%2F&response_mode=fragment&response_type=code&scope=openid Authorization Respo

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

I'm not following to be honest. Could you detail concretely what the flow would be that would result in vulnerability? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

Finally, I'm not sure a client that doesn't send the 'code_challenge' and 'code_challenge_method' on the authorization request but does send the 'code_verifier' on the token request should consider that the client has implemented PKCE correctly and hence can rely on it for CSRF. My point is not,

[OAUTH-WG] [Editorial Errata Reported] RFC8707 (6810)

The following errata report has been submitted for RFC8707, "Resource Indicators for OAuth 2.0". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6810 -- Type: Editorial Reported by: Jan Goebel

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

Hi Benjamin, thanks for bringing this up! What you describe is essentially a downgrade from PKCE to a non-PKCE flow. Nov Matake pointed out this possibility in an earlier discussion: https://mailarchive.ietf.org/arch/msg/oauth/qrLAf3nWRt8HAFkO49qGrPRuelo/ We therefore added this attack to the S