Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Agreed with keeping DPoP simple, which was why I was asking if the proposal could indicate it was targeting some of these other use cases. It's clear from the feedback that the current draft does not clearly express these use cases. There is overlap with DPoP – on a technical level, Message

[OAUTH-WG] Fwd: Webex meeting changed: OAuth WG Interims - October 2021

All, We have extended this series by one more week, *until Nov 3rd*, for a session that will cover the *Token Exchange Profile for Enterprise* documents. Regards, Rifaat -- Forwarded message - From: Web Authorization Protocol Working Group Date: Wed, Oct 13, 2021 at 5:39 PM

[OAUTH-WG] Canceled Webex meeting: OAuth WG Interims - October 2021

BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20201011T015911Z TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT

[OAUTH-WG] Webex meeting invitation: OAuth WG Interims - October 2021

BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20201011T015911Z TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Yes, as I said before, authorization servers are free to enforce one-time use of the authorization code even if there isn't a requirement to. The proposal is just to remove the *requirement* of authorization servers enforcing it. I am okay with Mike's suggestion of changing the language to

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Log files can exist in lots of place (clients, servers, data lakes). The question is whether it is a valid assumption that an attacker cannot obtain an Authorization Code and a Code Verifier and present it a second time round. Limiting the validity period is one layer of defence, PKCE is

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Even a distributed system with server-side state can still encounter challenges maintaining one-time usage, particularly if server-side state itself is distributed and eventually consistent. Given all the redirects and user actions in OAuth 2.0, a storage layer may reach consistency fast enough

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Ok, if the goal is to avoid unnecessary requirements I am suggesting to point out why MUST was changed to SHOULD. Otherwise developers will start to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit their needs. In regards to encrypted values in PKCE, Aaron, I can also not

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

The PKCE spec actually says "Typically, the "code_challenge" and "code_challenge_method" values are stored in encrypted form in the "code" itself" which I feel like might be a stretch to say that's typical, but this scenario was clearly thought of ahead of time. Doing that would enable an AS to

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

The argument is "let's not have a requirement that doesn't serve to increase security". If we can't think of a reason why it's necessary or some attack it prevents against, it's better to allow AS to decide, rather than forcing an unnecessary implementation detail. Warren Parad Founder, CTO

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

If the challenge is based on distributed authorization server configurations, how would they handle PKCE? I imagine that managing the state for PKCE is not less challenging than managing authorization codes on the server side, preventing reuse of them. With that in mind I am not sure if I follow

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

HTTPS, because if that's broken then the rest of OAuth falls apart too. On Wed, Oct 13, 2021 at 1:36 PM Warren Parad wrote: > I feel like I'm missing something, what stops just plain old network > sniffing and replying the whole encrypted payload to the AS and getting > back a valid token? > >

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

I feel like I'm missing something, what stops just plain old network sniffing and replying the whole encrypted payload to the AS and getting back a valid token? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On

Re: [OAUTH-WG] OAuth Interim Meeting Minutes - October 13

Here is the correct IETF notes link: https://notes.ietf.org/notes-ietf-interim-2021-oauth-12-oauth On Wed, Oct 13, 2021 at 4:23 PM Rifaat Shekh-Yusef wrote: > All, > > Thanks to *Hannes* and *Dick* for taking the minutes for this meeting. > The following links have the minutes, attendees, and

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Aside from the "plain" method, the PKCE code verifier never leaves the client until it's sent along with the authorization code in the POST request to the token endpoint. The only place it can leak at that point is if the authorization server itself leaks it. If you have things leaking from the

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Aaron, I was curious what prevents an attacker from presenting an Authorization Code and a PKCE Code Verifier for a second time if the one time use requirement is removed. Is there another countermeasure in PKCE that would prevent it? For example, an attacker may obtain the Authorization Code

[OAUTH-WG] OAuth Interim Meeting Minutes - October 13

All, Thanks to *Hannes* and *Dick* for taking the minutes for this meeting. The following links have the minutes, attendees, and recording of the meeting: https://datatracker.ietf.org/meeting/interim-2021-oauth-12/materials/minutes-interim-2021-oauth-12-202110131200-00

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Specifically to the discussion of symmetric keys: Adding symmetric keys implies one of a set of rather different architectures. For example, one may look (even more) close to Kerberos, with access tokens resembling service tickets, while another might negotiate a symmetric key/token local to a

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

(Honestly I'm struggling to fathom a circumstance where symmetric keys not only could be used effectively, but should be used, especially in the context of PoP where there is more than one entity involved) If the breaking point is symmetric keys, then I would recommend two drafts with as close to

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

If keeping DPoP simple means we have to have come up with 10 different variants to handle all the different cases that it doesn't support, then it isn't keeping it simple, it is just pushing the problem forward to the implementers to figure out which set of RFCs to implement. I would agree with

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

> On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle > wrote: > > Those issues that could be addressed without completely redesigning DPoP have > been discussed within the Working Group multiple times. (See quotes and > meeting notes references in my previous message) The authors

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

I agree that PKCE (with a non-plain operational mode) protects the code from attacker use by the security BCP model (but not necessarily stronger models) Would the prevalence for ASs which cannot enforce an atomic code grant warrant further language against plain PKCE? -DW > On Oct 13, 2021,

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

(It's a bit of a tangent, but having the PKCE for confidential clients severely cuts down on extra complexity for client platforms/development teams when an AS choses to allow it for some clients and not for others. Consistency here is a good thing, since it's fairly easy to implement the

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

PKCE is built in to the authorization code flow in OAuth 2.1 and does not depend on the client type. Neil does bring up a good point about the "plain" challenge type though. The "plain" type does undermine some of the security guarantees that PKCE provides. The Security BCP does recommend against

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Thanks Aaron, that's a great point. In light of that, I would ask about the recommendation for non-SPA. I was under the impression that non-SPA's don't require the use of PKCE, which would make them vulnerable to replay attacks. Or am I missing something? Warren Parad Founder, CTO Secure your

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

I wasn’t on the call either, so maybe I’m missing something. If you’re using PKCE with the “plain” challenge type then both the auth code and the verifier are exposed in redirect URI parameters in the user-agent aren’t they? That seems a bit risky to drop the one-time use requirement. I can’t

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Warren, I didn't see you on the interim call, so you might be missing some context. The issue that was discussed is that using PKCE already provides all the security benefit that is gained by enforcing single-use authorization codes. Therefore, requiring that they are single-use isn't necessary

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Isn't it better for it to be worded as we want it to be, with the implication being that of course it might be difficult to do that, but that AS devs will think long and hard about sometimes not denying the request? Even with MUST, some AS will still allow reuse of auth codes. Isn't that better

[OAUTH-WG] Authorization code reuse and OAuth 2.1

During today's call, it was asked whether we should drop the OAuth 2.0 language that: The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD

[OAUTH-WG] Publication has been requested for draft-ietf-oauth-iss-auth-resp-02

Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-iss-auth-resp-02 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ ___

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Are there things about the OAuth DPoP that are possibly problematic, definitely, but it is still in draft. Wouldn't this be the best opportunity to expose these problems to the authors and work through possible solutions? This conversation has already brought some things to mind which I'd be