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

[Richard Backman, Annabelle]

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 
Signatures ought to be able to handle DPoP's use cases, albeit complexity in 
different places. But not vice-versa.


The current draft being proposed for adoption I believe is fixed to the same 
HTTP properties that DPoP leverages, and thus appears to be targeting the same 
use cases with a different proof expression.

This is a misconception that should get clarified in the draft. One of the core 
concepts behind Message Signatures is that it defines a standard mechanism for 
signature components of an HTTP message and for communicating which components 
are signed, but it does not dictate which components need to be signed. That 
will vary from deployment to deployment, based on which components are 
semantically meaningful. E.g., an RS that accepts POST requests and receives 
parameters in the request body may require that the `Digest` header field be 
signed, whereas one that only accepts GET requests may only need the URL to be 
signed. The draft defines an `Accept-Signature` header field that can be 
included in a message to indicate which components need to be signed.

Justin's draft introduces a requirement that signatures intended to provide PoP 
for OAuth MUST sign the `Authorization` header field, since that's where the 
access token is. Beyond that, RSes can indicate their API-specific signing 
requirements via `Accept-Signature`. (And/or through out-of-band documentation)

The duplication within the token is also a trade-off: it allows an 
implementation to have a white list of acceptable internal values, if say the 
host and path are rewritten by reverse proxies.

I agree, there are trade-offs. For some, especially those already using JWTs 
all over the place, the simplicity of using a format and libraries they are 
already familiar with may outweigh the risk I described.

FWIW, the Message Signatures approach to the situation you described would be 
for the reverse proxy to add an `X-Forwarded-Host` or similar header field, and 
add a signature over that, the `Host` header field, and the client's signature. 
(Message Signatures supports multiple signatures on one message) I like this 
approach as the signatures are guaranteed to be validated against the same data 
the application uses. (Since there's only one copy of the data)

—
Annabelle Backman (she/her)
richa...@amazon.com




On Oct 13, 2021, at 11:41 AM, David Waite 
mailto:da...@alkaline-solutions.com>> wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle 
mailto:richa...@amazon.com>> 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 have pushed back on 
extending DPoP to cover additional use cases them due to a desire to keep DPoP 
simple and lightweight. I don't begrudge them that. I think it's reasonable to 
have a "dirt simple" solution, particularly for SPAs given the relative 
limitations of the browser environment.

Other issues are inherent to fundamental design choices, such as the use of JWS 
to prove possession of the key. E.g., you cannot avoid the data duplication 
issue since a JWS signature only covers a specific serialization of the JWT 
header and body.

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. The current 
draft being proposed for adoption I believe is fixed to the same HTTP 
properties that DPoP leverages, and thus appears to be targeting the same use 
cases with a different proof expression.

The duplication within the token is also a trade-off: it allows an 
implementation to have a white list of acceptable internal values, if say the 
host and path are rewritten by reverse proxies. It also allows an 
implementation to give richer diagnostic information when receiving 
unacceptable DPoP tokens, which may very well come at runtime from an 
independently-operating portion of an organization reconfiguring intermediaries.

-DW

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

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
Subject: Webex meeting changed: OAuth WG Interims - October 2021
To: 




You changed the Webex meeting information.


When it's time, start your Webex meeting here.


Occurs every Wednesday effective Wednesday, October 20, 2021 until
Wednesday, November 17, 2021 from 12:00 PM to 1:00 PM, (UTC-04:00) Eastern
Time (US & Canada)
12:00 PM  |  (UTC-04:00) Eastern Time (US & Canada)  |  1 hr

Start meeting


*More ways to join:*

*Join from the meeting link*
https://ietf.webex.com/ietf/j.php?MTID=mcebff0f84a22f7685b909e11c6db6cc6

*Join by meeting number*
Meeting number (access code): 2433 141 4281
Meeting password: NQu43NnicM2

*Tap to join from a mobile device (attendees only)*
+1-650-479-3208,,24331414281##
<%2B1-650-479-3208,,*01*24331414281%23%23*01*> Call-in toll number
(US/Canada)

*Join by phone*
1-650-479-3208 Call-in toll number (US/Canada)
Global call-in numbers


*Join from a video system or application*
Dial 24331414...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

If you are a host, click here

to view host information.

Need help? Go to https://help.webex.com


invite.ics
Description: application/ics


Webex_Meeting.ics
Description: application/ics
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Web Authorization Protocol Working Group]

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
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20211013T213828Z
ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org
ORGANIZER;CN="Web Authorization Protocol Working Group":MAILTO:oauth-cha...@ietf.org
DTSTART;TZID=America/New_York:20211020T12
DTEND;TZID=America/New_York:20211020T13
LOCATION:https://ietf.webex.com/ietf
TRANSP:OPAQUE
SEQUENCE:1634161108
UID:b627e7b9-32e2-4a13-b409-e7913187192b
DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Interims - October 2021\nDate: Occurs every Wednesday effective Wednesday, October 20, 2021 until Wednesday, November 17, 2021 from 12:00 PM to 1:00 PM, (UTC-04:00) Eastern Time (US & Canada)\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n
SUMMARY:OAuth WG Interims - October 2021
PRIORITY:5
CLASS:PUBLIC
RRULE:FREQ=WEEKLY;WKST=SU;COUNT=5;INTERVAL=1;BYDAY=WE
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR


Webex_Meeting.ics
Description: Binary data
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Web Authorization Protocol Working Group]

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
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20211013T213724Z
ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org
ORGANIZER;CN="Web Authorization Protocol Working Group":MAILTO:oauth-cha...@ietf.org
DTSTART;TZID=America/New_York:20211020T12
DTEND;TZID=America/New_York:20211020T13
LOCATION:https://ietf.webex.com/ietf/j.php?MTID=m67515b67dc464c76c07bdf18e140780c
TRANSP:OPAQUE
SEQUENCE:1634161044
UID:b627e7b9-32e2-4a13-b409-e7913187192b
DESCRIPTION:\n\n\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=m67515b67dc464c76c07bdf18e140780c\nMeeting number (access code): 2433 141 4281\n\nMeeting password: NQu43NnicM2\n\n\n\nTAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,24331414281## tel:%2B1-650-479-3208,,*01*24331414281%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=m6b559846d809c1490cb26df98e6fce75\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:24331414...@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting number.\n\n\n\n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/WBX29055\n\n\nIMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.\n
X-ALT-DESC;FMTTYPE=text/html:\ntable {\n	border-collapse: separate; width =100%;	border: 0;	border-spacing: 0;}\n\ntr {\n	line-height: 18px;}\n\na, td {\n	font-size: 14px;	font-family: Arial;	color: #333;	word-wrap: break-word;	word-break: normal;	padding: 0;}\n\n.title {\n	font-size: 28px;}\n\n.image {\n	width: auto;	max-width: auto;}\n\n.footer {\n	width: 604px;}\n\n.main {\n\n}@media screen and (max-device-width: 800px) {\n	.title {\n		font-size: 22px !important;	}\n	.image {\n		width: auto !important;		max-width: 100% !important;	}\n	.footer {\n		width: 100% !important;		max-width: 604px !important\n	}\n	.main {\n		width: 100% !important;		max-width: 604px !important\n	}\n}\n\n\n\n	\n	\n		\n			\n\n\n\n\n\n			\n\n	\n		When it's time, join the Webex meeting here.\n	\n\n		\n\n\n	\n			\n\n	\n		\n			https://ietf.webex.com/ietf/j.php?MTID=m67515b67dc464c76c07bdf18e140780c; style="color:#FF; font-size:20px; text-decoration:none;">Join meeting\n		\n	\n\n			\n		\n		\n			\n			\n\n		More ways to join:\n\n	\n\n	\n\n		Join from the meeting link\n\n	\n	\n\n		https://ietf.webex.com/ietf/j.php?MTID=m67515b67dc464c76c07bdf18e140780c\n\n	\n	\n			\n\n		Join by meeting number\n\n	\n			\n\n	Meeting number (access code): 2433 141 4281\n\n			\n		\n		Meeting password:NQu43NnicM2\n\n \n\n Tap to join from a mobile device (attendees only)  +1-650-479-3208,,24331414281## Call-in toll number (US/Canada) Join by phone  1-650-479-3208 Call-in toll number (US/Canada)  https://ietf.webex.com/ietf/globalcallin.php?MTID=m6b559846d809c1490cb26df98e6fce75; style="text-decoration:none;font-size:14px;color:#005E7D">Global call-in numbers \n\n\n\nJoin from a video system or applicationDial 24331414...@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number.   \n\n\n\n	\n	\n\n			\n\n\n	Need help? Go to https://help.webex.com; style="color:#005E7D; text-decoration:none;">https://help.webex.com\n	\n\n\n			\n		\n	\n\n
SUMMARY:OAuth WG Interims - October 2021
PRIORITY:5
CLASS:PUBLIC
RRULE:FREQ=WEEKLY;WKST=SU;COUNT=5;INTERVAL=1;BYDAY=WE
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR


Webex_Meeting.ics
Description: Binary data
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

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 "SHOULD" to
continue to point out the possibility of enforcing one-time authorization
codes if desired.



On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman <
pieter.kassel...@microsoft.com> wrote:

> 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
> another layer, one time use enforcement is another. Assuming breach and
> designing from a defence in depth perspective is a good practice, so why
> not give implementors options (and guidance) to add additional layers of
> defence to match their risk profiles?
>
>
>
>
>
> *From:* OAuth  *On Behalf Of *Sascha Preibisch
> *Sent:* Wednesday 13 October 2021 22:06
> *To:* Aaron Parecki 
> *Cc:* IETF oauth WG 
> *Subject:* 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 confirm that
> as the general implementation.
>
>
>
> On Wed, 13 Oct 2021 at 13:56, Aaron Parecki  wrote:
>
> 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 avoid storing server-side state.
>
>
>
> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
> saschapreibi...@gmail.com> wrote:
>
> 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 the given argument. I would
> prefer to keep MUST as it is today.
>
>
>
>
>
> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:
>
> 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?
>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> 
> .
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  wrote:
>
> 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 authorization server log, you likely have much bigger problems
> than authorization code replays.
>
>
>
> Keep in mind that even with the proposed change to drop the requirement of
> authorization codes being one time use, authorization servers are free to
> enforce this still if they want. Authorization code lifetimes are still
> expected to be short lived as well.
>
>
>
> Aaron
>
>
>
>
>
> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
> pieter.kassel...@microsoft.com> wrote:
>
> 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 and the Code Verifier from a log and replay it.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth  *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 13 October 2021 18:40
> *To:* Warren Parad 
> *Cc:* Mike Jones ;
> oauth@ietf.org
> *Subject:* [EXTERNAL] 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 

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

[Pieter Kasselman]

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 another layer, 
one time use enforcement is another. Assuming breach and designing from a 
defence in depth perspective is a good practice, so why not give implementors 
options (and guidance) to add additional layers of defence to match their risk 
profiles?


From: OAuth  On Behalf Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki 
Cc: IETF oauth WG 
Subject: 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 confirm that as 
the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
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 
avoid storing server-side state.

On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch 
mailto:saschapreibi...@gmail.com>> wrote:
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 the given argument. I would prefer 
to keep MUST as it is today.


On Wed, 13 Oct 2021 at 13:37, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
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 
mailto:wpa...@rhosys.ch>> 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?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress.


On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
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 
authorization server log, you likely have much bigger problems than 
authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of 
authorization codes being one time use, authorization servers are free to 
enforce this still if they want. Authorization code lifetimes are still 
expected to be short lived as well.

Aaron


On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman 
mailto:pieter.kassel...@microsoft.com>> wrote:
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 and the Code Verifier 
from a log and replay it.

Cheers

Pieter

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Cc: Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>;
 oauth@ietf.org
Subject: [EXTERNAL] 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 as it doesn't 
provide any additional benefit.

If anyone can think of a possible attack by allowing authorization codes to be 
reused 

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

[Richard Backman, Annabelle]

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 for the 
protocol to work while still being slow enough to leave open a window of replay 
opportunity.

—
Annabelle Backman (she/her)
richa...@amazon.com




On Oct 13, 2021, at 1:56 PM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


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 
avoid storing server-side state.

On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch 
mailto:saschapreibi...@gmail.com>> wrote:
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 the given argument. I would prefer 
to keep MUST as it is today.


On Wed, 13 Oct 2021 at 13:37, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
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 
mailto:wpa...@rhosys.ch>> 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?

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data with IAM authorization as a service. Implement 
Authress.


On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
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 
authorization server log, you likely have much bigger problems than 
authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of 
authorization codes being one time use, authorization servers are free to 
enforce this still if they want. Authorization code lifetimes are still 
expected to be short lived as well.

Aaron


On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman 
mailto:pieter.kassel...@microsoft.com>> wrote:
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 and the Code Verifier 
from a log and replay it.

Cheers

Pieter

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Cc: Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>;
 oauth@ietf.org
Subject: [EXTERNAL] 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 as it doesn't 
provide any additional benefit.

If anyone can think of a possible attack by allowing authorization codes to be 
reused *even with a valid PKCE code verifier* then that would warrant keeping 
this requirement.

---
Aaron Parecki


On Wed, Oct 13, 2021 at 10:27 AM Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>> wrote:
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 than flat out 
saying: sure, there's a valid reason

In other words, how do we think about RFCs? Do they exist to be followed to the 
letter or not at all? Or do they exist to stipulate this is the way, but 
acknowledge that not everyone will build a solution that holds them as law.

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

[Sascha Preibisch]

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 confirm that
as the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki  wrote:

> 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 avoid storing server-side state.
>
> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
> saschapreibi...@gmail.com> wrote:
>
>> 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 the given argument. I would
>> prefer to keep MUST as it is today.
>>
>>
>> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:
>>
>>> 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?

 Warren Parad

 Founder, CTO
 Secure your user data with IAM authorization as a service. Implement
 Authress .


 On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
 wrote:

> 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 authorization server log, you likely have much bigger problems
> than authorization code replays.
>
> Keep in mind that even with the proposed change to drop the
> requirement of authorization codes being one time use, authorization
> servers are free to enforce this still if they want. Authorization code
> lifetimes are still expected to be short lived as well.
>
> Aaron
>
>
> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
> pieter.kassel...@microsoft.com> wrote:
>
>> 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 and the Code Verifier from a log and replay it.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Pieter
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Aaron Parecki
>> *Sent:* Wednesday 13 October 2021 18:40
>> *To:* Warren Parad 
>> *Cc:* Mike Jones ;
>> oauth@ietf.org
>> *Subject:* [EXTERNAL] 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 as 
>> it
>> doesn't provide any additional benefit.
>>
>>
>>
>> If anyone can think of a possible attack by allowing authorization
>> codes to be reused *even with a valid PKCE code verifier* then that would
>> warrant keeping this requirement.
>>
>>
>>
>> ---
>>
>> Aaron Parecki
>>
>>
>>
>>
>>
>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad > 40rhosys...@dmarc.ietf.org> wrote:
>>
>> 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 than flat out saying: *sure, there's a valid reason*
>>
>>
>>
>> In other words, how do we think about RFCs? Do they exist to be
>> followed to the letter or not at all? Or do they exist to stipulate this 
>> is
>> the way, but acknowledge that not everyone will build a solution that 
>> holds
>> them as law.
>>
>>
>>
>> Let's look at *SHOULD*

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

[Aaron Parecki]

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 avoid storing server-side state.

On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch 
wrote:

> 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 the given argument. I would
> prefer to keep MUST as it is today.
>
>
> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:
>
>> 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?
>>>
>>> Warren Parad
>>>
>>> Founder, CTO
>>> Secure your user data with IAM authorization as a service. Implement
>>> Authress .
>>>
>>>
>>> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
>>> wrote:
>>>
 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 authorization server log, you likely have much bigger problems
 than authorization code replays.

 Keep in mind that even with the proposed change to drop the requirement
 of authorization codes being one time use, authorization servers are free
 to enforce this still if they want. Authorization code lifetimes are still
 expected to be short lived as well.

 Aaron


 On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
 pieter.kassel...@microsoft.com> wrote:

> 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 and the Code Verifier from a log and replay it.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth  *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 13 October 2021 18:40
> *To:* Warren Parad 
> *Cc:* Mike Jones ;
> oauth@ietf.org
> *Subject:* [EXTERNAL] 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 as it
> doesn't provide any additional benefit.
>
>
>
> If anyone can think of a possible attack by allowing authorization
> codes to be reused *even with a valid PKCE code verifier* then that would
> warrant keeping this requirement.
>
>
>
> ---
>
> Aaron Parecki
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
> 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 than flat out saying: *sure, there's a valid reason*
>
>
>
> In other words, how do we think about RFCs? Do they exist to be
> followed to the letter or not at all? Or do they exist to stipulate this 
> is
> the way, but acknowledge that not everyone will build a solution that 
> holds
> them as law.
>
>
>
> Let's look at *SHOULD*
>
> This word, or the adjective "RECOMMENDED", mean that there may exist
> valid reasons in particular circumstances to ignore a particular item, but
> the full implications must be understood and carefully weighed before
> choosing a different course.
>
>
>
> I think *recommended* here is not sufficient nor are there valid
> reasons. "It's too hard" isn't really a valid reason. Isn't it better in
> this case for an AS to not be compliant with the RFC, than it is to relax
> this to SHOULD and have lots of AS thinking 

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

[Warren Parad]

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
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 10:50 PM Sascha Preibisch 
wrote:

> 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 the given argument. I would
> prefer to keep MUST as it is today.
>
>
> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:
>
>> 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?
>>>
>>> Warren Parad
>>>
>>> Founder, CTO
>>> Secure your user data with IAM authorization as a service. Implement
>>> Authress .
>>>
>>>
>>> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
>>> wrote:
>>>
 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 authorization server log, you likely have much bigger problems
 than authorization code replays.

 Keep in mind that even with the proposed change to drop the requirement
 of authorization codes being one time use, authorization servers are free
 to enforce this still if they want. Authorization code lifetimes are still
 expected to be short lived as well.

 Aaron


 On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
 pieter.kassel...@microsoft.com> wrote:

> 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 and the Code Verifier from a log and replay it.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth  *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 13 October 2021 18:40
> *To:* Warren Parad 
> *Cc:* Mike Jones ;
> oauth@ietf.org
> *Subject:* [EXTERNAL] 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 as it
> doesn't provide any additional benefit.
>
>
>
> If anyone can think of a possible attack by allowing authorization
> codes to be reused *even with a valid PKCE code verifier* then that would
> warrant keeping this requirement.
>
>
>
> ---
>
> Aaron Parecki
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
> 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 than flat out saying: *sure, there's a valid reason*
>
>
>
> In other words, how do we think about RFCs? Do they exist to be
> followed to the letter or not at all? Or do they exist to stipulate this 
> is
> the way, but acknowledge that not everyone will build a solution that 
> holds
> them as law.
>
>
>
> Let's look at *SHOULD*
>
> This word, or the adjective "RECOMMENDED", mean that there may exist
> valid reasons in particular circumstances to ignore a particular item, but
> the full implications must be understood and carefully weighed before
> choosing a different course.
>
>
>
> I think *recommended* here is not sufficient nor are there valid
> reasons. "It's too hard" isn't really a valid reason. Isn't it better in
> this case for an AS to not be compliant with the RFC, 

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

[Sascha Preibisch]

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 the given argument. I would
prefer to keep MUST as it is today.


On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:

> 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?
>>
>> Warren Parad
>>
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement
>> Authress .
>>
>>
>> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  wrote:
>>
>>> 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 authorization server log, you likely have much bigger problems
>>> than authorization code replays.
>>>
>>> Keep in mind that even with the proposed change to drop the requirement
>>> of authorization codes being one time use, authorization servers are free
>>> to enforce this still if they want. Authorization code lifetimes are still
>>> expected to be short lived as well.
>>>
>>> Aaron
>>>
>>>
>>> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
>>> pieter.kassel...@microsoft.com> wrote:
>>>
 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 and the Code Verifier from a log and replay it.



 Cheers



 Pieter



 *From:* OAuth  *On Behalf Of *Aaron Parecki
 *Sent:* Wednesday 13 October 2021 18:40
 *To:* Warren Parad 
 *Cc:* Mike Jones ;
 oauth@ietf.org
 *Subject:* [EXTERNAL] 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 as it
 doesn't provide any additional benefit.



 If anyone can think of a possible attack by allowing authorization
 codes to be reused *even with a valid PKCE code verifier* then that would
 warrant keeping this requirement.



 ---

 Aaron Parecki





 On Wed, Oct 13, 2021 at 10:27 AM Warren Parad >>> 40rhosys...@dmarc.ietf.org> wrote:

 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 than flat out saying: *sure, there's a valid reason*



 In other words, how do we think about RFCs? Do they exist to be
 followed to the letter or not at all? Or do they exist to stipulate this is
 the way, but acknowledge that not everyone will build a solution that holds
 them as law.



 Let's look at *SHOULD*

 This word, or the adjective "RECOMMENDED", mean that there may exist
 valid reasons in particular circumstances to ignore a particular item, but
 the full implications must be understood and carefully weighed before
 choosing a different course.



 I think *recommended* here is not sufficient nor are there valid
 reasons. "It's too hard" isn't really a valid reason. Isn't it better in
 this case for an AS to not be compliant with the RFC, than it is to relax
 this to SHOULD and have lots of AS thinking reusing auth codes is a viable
 solution, "because they are a special snowflake where SHOULD should apply".



 Are we setting the standard or instead attempting to sustain a number
 of "AS that are in compliance with the RFC"?



 *Warren Parad*

 Founder, CTO

 Secure your user data with IAM authorization as a service. Implement
 Authress
 

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

[Aaron Parecki]

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?
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  wrote:
>
>> 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 authorization server log, you likely have much bigger problems
>> than authorization code replays.
>>
>> Keep in mind that even with the proposed change to drop the requirement
>> of authorization codes being one time use, authorization servers are free
>> to enforce this still if they want. Authorization code lifetimes are still
>> expected to be short lived as well.
>>
>> Aaron
>>
>>
>> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
>> pieter.kassel...@microsoft.com> wrote:
>>
>>> 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 and the Code Verifier from a log and replay it.
>>>
>>>
>>>
>>> Cheers
>>>
>>>
>>>
>>> Pieter
>>>
>>>
>>>
>>> *From:* OAuth  *On Behalf Of *Aaron Parecki
>>> *Sent:* Wednesday 13 October 2021 18:40
>>> *To:* Warren Parad 
>>> *Cc:* Mike Jones ;
>>> oauth@ietf.org
>>> *Subject:* [EXTERNAL] 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 as it
>>> doesn't provide any additional benefit.
>>>
>>>
>>>
>>> If anyone can think of a possible attack by allowing authorization codes
>>> to be reused *even with a valid PKCE code verifier* then that would warrant
>>> keeping this requirement.
>>>
>>>
>>>
>>> ---
>>>
>>> Aaron Parecki
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad >> 40rhosys...@dmarc.ietf.org> wrote:
>>>
>>> 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 than flat out saying: *sure, there's a valid reason*
>>>
>>>
>>>
>>> In other words, how do we think about RFCs? Do they exist to be followed
>>> to the letter or not at all? Or do they exist to stipulate this is the way,
>>> but acknowledge that not everyone will build a solution that holds them as
>>> law.
>>>
>>>
>>>
>>> Let's look at *SHOULD*
>>>
>>> This word, or the adjective "RECOMMENDED", mean that there may exist
>>> valid reasons in particular circumstances to ignore a particular item, but
>>> the full implications must be understood and carefully weighed before
>>> choosing a different course.
>>>
>>>
>>>
>>> I think *recommended* here is not sufficient nor are there valid
>>> reasons. "It's too hard" isn't really a valid reason. Isn't it better in
>>> this case for an AS to not be compliant with the RFC, than it is to relax
>>> this to SHOULD and have lots of AS thinking reusing auth codes is a viable
>>> solution, "because they are a special snowflake where SHOULD should apply".
>>>
>>>
>>>
>>> Are we setting the standard or instead attempting to sustain a number of
>>> "AS that are in compliance with the RFC"?
>>>
>>>
>>>
>>> *Warren Parad*
>>>
>>> Founder, CTO
>>>
>>> Secure your user data with IAM authorization as a service. Implement
>>> Authress
>>> 
>>> .
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones >> 40microsoft@dmarc.ietf.org> wrote:
>>>
>>> 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 

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

[Warren Parad]

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 Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  wrote:

> 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 authorization server log, you likely have much bigger problems
> than authorization code replays.
>
> Keep in mind that even with the proposed change to drop the requirement of
> authorization codes being one time use, authorization servers are free to
> enforce this still if they want. Authorization code lifetimes are still
> expected to be short lived as well.
>
> Aaron
>
>
> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
> pieter.kassel...@microsoft.com> wrote:
>
>> 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 and the Code Verifier from a log and replay it.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Pieter
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Aaron Parecki
>> *Sent:* Wednesday 13 October 2021 18:40
>> *To:* Warren Parad 
>> *Cc:* Mike Jones ;
>> oauth@ietf.org
>> *Subject:* [EXTERNAL] 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 as it
>> doesn't provide any additional benefit.
>>
>>
>>
>> If anyone can think of a possible attack by allowing authorization codes
>> to be reused *even with a valid PKCE code verifier* then that would warrant
>> keeping this requirement.
>>
>>
>>
>> ---
>>
>> Aaron Parecki
>>
>>
>>
>>
>>
>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad > 40rhosys...@dmarc.ietf.org> wrote:
>>
>> 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 than flat out saying: *sure, there's a valid reason*
>>
>>
>>
>> In other words, how do we think about RFCs? Do they exist to be followed
>> to the letter or not at all? Or do they exist to stipulate this is the way,
>> but acknowledge that not everyone will build a solution that holds them as
>> law.
>>
>>
>>
>> Let's look at *SHOULD*
>>
>> This word, or the adjective "RECOMMENDED", mean that there may exist
>> valid reasons in particular circumstances to ignore a particular item, but
>> the full implications must be understood and carefully weighed before
>> choosing a different course.
>>
>>
>>
>> I think *recommended* here is not sufficient nor are there valid
>> reasons. "It's too hard" isn't really a valid reason. Isn't it better in
>> this case for an AS to not be compliant with the RFC, than it is to relax
>> this to SHOULD and have lots of AS thinking reusing auth codes is a viable
>> solution, "because they are a special snowflake where SHOULD should apply".
>>
>>
>>
>> Are we setting the standard or instead attempting to sustain a number of
>> "AS that are in compliance with the RFC"?
>>
>>
>>
>> *Warren Parad*
>>
>> Founder, CTO
>>
>> Secure your user data with IAM authorization as a service. Implement
>> Authress
>> 
>> .
>>
>>
>>
>>
>>
>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones > 40microsoft@dmarc.ietf.org> wrote:
>>
>> 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
>>
>>  revoke (when possible) all tokens previously issued based on
>>
>>  that authorization code.”
>>
>>
>>
>> The rationale given was that 

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

[Rifaat Shekh-Yusef]

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 recording of the
> meeting:
>
> https://datatracker.ietf.org/meeting/interim-2021-oauth-12/materials/minutes-interim-2021-oauth-12-202110131200-00
> file:///Users/rifaat/Downloads/OAuth%20WG%20Interim%20Meeting.html
>
> Regards,
>  Rifaat & Hannes
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

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 authorization server log, you likely have much bigger problems
than authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of
authorization codes being one time use, authorization servers are free to
enforce this still if they want. Authorization code lifetimes are still
expected to be short lived as well.

Aaron


On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
pieter.kassel...@microsoft.com> wrote:

> 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 and the Code Verifier from a log and replay it.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth  *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 13 October 2021 18:40
> *To:* Warren Parad 
> *Cc:* Mike Jones ;
> oauth@ietf.org
> *Subject:* [EXTERNAL] 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 as it
> doesn't provide any additional benefit.
>
>
>
> If anyone can think of a possible attack by allowing authorization codes
> to be reused *even with a valid PKCE code verifier* then that would warrant
> keeping this requirement.
>
>
>
> ---
>
> Aaron Parecki
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
> 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 than flat out saying: *sure, there's a valid reason*
>
>
>
> In other words, how do we think about RFCs? Do they exist to be followed
> to the letter or not at all? Or do they exist to stipulate this is the way,
> but acknowledge that not everyone will build a solution that holds them as
> law.
>
>
>
> Let's look at *SHOULD*
>
> This word, or the adjective "RECOMMENDED", mean that there may exist valid
> reasons in particular circumstances to ignore a particular item, but the
> full implications must be understood and carefully weighed before choosing
> a different course.
>
>
>
> I think *recommended* here is not sufficient nor are there valid reasons.
> "It's too hard" isn't really a valid reason. Isn't it better in this case
> for an AS to not be compliant with the RFC, than it is to relax this to
> SHOULD and have lots of AS thinking reusing auth codes is a viable
> solution, "because they are a special snowflake where SHOULD should apply".
>
>
>
> Are we setting the standard or instead attempting to sustain a number of
> "AS that are in compliance with the RFC"?
>
>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> 
> .
>
>
>
>
>
> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
> 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
>
>  revoke (when possible) all tokens previously issued based on
>
>  that authorization code.”
>
>
>
> The rationale given was that enforcing one-time use is impractical in
> distributed authorization server deployments.
>
>
>
> Thinking about this some more, at most, we should relax this to:
>
>  The client MUST NOT use the authorization code
>
>  more than once.  If an authorization code is used more than
>
>  once, the authorization server SHOULD deny the request and SHOULD
>
>  revoke (when possible) all tokens previously issued based on
>
>  that authorization code.”
>
>
>
> In short, it 

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

[Pieter Kasselman]

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 and the Code Verifier 
from a log and replay it.

Cheers

Pieter

From: OAuth  On Behalf Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad 
Cc: Mike Jones ; oauth@ietf.org
Subject: [EXTERNAL] 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 as it doesn't 
provide any additional benefit.

If anyone can think of a possible attack by allowing authorization codes to be 
reused *even with a valid PKCE code verifier* then that would warrant keeping 
this requirement.

---
Aaron Parecki


On Wed, Oct 13, 2021 at 10:27 AM Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>> wrote:
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 than flat out 
saying: sure, there's a valid reason

In other words, how do we think about RFCs? Do they exist to be followed to the 
letter or not at all? Or do they exist to stipulate this is the way, but 
acknowledge that not everyone will build a solution that holds them as law.

Let's look at SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid 
reasons in particular circumstances to ignore a particular item, but the full 
implications must be understood and carefully weighed before choosing a 
different course.

I think recommended here is not sufficient nor are there valid reasons. "It's 
too hard" isn't really a valid reason. Isn't it better in this case for an AS 
to not be compliant with the RFC, than it is to relax this to SHOULD and have 
lots of AS thinking reusing auth codes is a viable solution, "because they are 
a special snowflake where SHOULD should apply".

Are we setting the standard or instead attempting to sustain a number of "AS 
that are in compliance with the RFC"?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress.


On Wed, Oct 13, 2021 at 7:17 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
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
 revoke (when possible) all tokens previously issued based on
 that authorization code."

The rationale given was that enforcing one-time use is impractical in 
distributed authorization server deployments.

Thinking about this some more, at most, we should relax this to:
 The client MUST NOT use the authorization code
 more than once.  If an authorization code is used more than
 once, the authorization server SHOULD deny the request and SHOULD
 revoke (when possible) all tokens previously issued based on
 that authorization code."

In short, it should remain illegal for the client to try to reuse the 
authorization code.  We can relax the MUST to SHOULD in the server requirements 
in recognition of the difficulty of enforcing the MUST.

Code reuse is part of some attack scenarios.  We must not sanction it.

  -- Mike

___
OAuth mailing list
OAuth@ietf.org

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

[Rifaat Shekh-Yusef]

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
file:///Users/rifaat/Downloads/OAuth%20WG%20Interim%20Meeting.html

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

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 RS based on an RS challenge. In either case, a symmetric key basis 
requires resource-constrained keys and possibly tokens.

It also makes preventing exfiltration of keys (and the associated tokens) 
harder to prevent - you would likely want to include key derivation in grant 
processes. The HTTP Signature key identifier might actually be from the AS or 
server, and even represent a wrapped key.

I suspect adding this use case to DPoP would be more than a doubling of 
complexity.

IMHO past discussions around symmetric keys were more arguments over whether 
DPoP could be considered complete without that additional complexity, due to 
the computational efficiencies of symmetric keys over asymmetric ones. This 
comes into play when the network/computational and complexity costs of a per-RS 
key/token negotiation is dwarfed by the ongoing use of that token to talk to a 
particular RS.

This also means that it is primarily a concern when MTLS is not possible, as 
MTLS will negotiate a symmetric key at a lower level anyway.

-DW

> On Oct 13, 2021, at 3:51 AM, Warren Parad  wrote:
> 
> 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 
> interested in improving, for instance cnf being an array, and attempting to 
> utilize the Authorization header more effectively, but this isn't the thread 
> to discuss those. Is there a reason we can't just improve the existing DPoP 
> draft to remove the limitations you listed above?
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress 
> .
> 
> 
> On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle 
> mailto:40amazon@dmarc.ietf.org>> 
> wrote:
> David, Warren, Hannes and others:
> 
> The limitations of DPoP and mTLS have been discussed numerous times within 
> the Working Group. Here is a summary of those that I am aware of; others may 
> have additional concerns.
> 
> (Though please note first that none of this is to say that DPoP and mTLS are 
> bad or useless – they each are targeted at certain use cases, and they serve 
> those well. They just don't serve every use case well.)
> 
> DPoP Limitations:
> Does not support symmetric keys.
> Requires the same key to be used with AS and RSes.
> Does not support multiple valid signing keys.
> Signed content is copied into the JWT and therefore duplicated within the 
> message. This allows for bugs where the verifier fails to check that these 
> values match, or performs that check incorrectly. (e.g., assuming case 
> insensitivity)
> Only covers the method, scheme, host, and path. Allows for additional 
> arbitrary content to be signed, but does not provide any guidance or support 
> for defining interoperable extensions.
> Depends on JWT, which may be a new dependency, particularly for clients that 
> are doing OAuth 2.0 but not OIDC.
> 
> mTLS Limitations:
> Requires a single end-to-end TLS connection between client and AS/RS. This 
> often is not the case in modern distributed systems, e.g., TLS may be 
> terminated at a load balancer, or by the hosting platform in the case of a 
> "serverless" application. On the client side, enterprises may have TLS 
> inspection appliances that break the TLS connection.
> Abysmal user experience in the browser. (though that is what DPoP was 
> intended to address, at least initially)
> 
> In contrast, Justin's HTTP Message Signatures-based approach:
> Allows for flexibility regarding key selection.
> Allows signing of as much or as little of the HTTP message as is appropriate 
> for the request.
> Does not duplicate signed content.
> Does not depend on JWT, unless you want it to.
> Does not depend on an end-to-end TLS connection, or any other specifics below 
> the HTTP layer.
> Allows servers to use the same signature mechanism for other HTTP signing use 
> cases. (e.g., browser signing authorization cookies, LBs adding a signature 
> over the `X-Forwarded-For` header field)
> 
> Note that these concerns regarding use cases not addressed by DPoP and mTLS 
> are not new. Below are excerpts taken from WG meeting notes going back to 
> 2019:
> 
> IETF 105 :
> MTLS is good but not great for browser. TOKBIND has no current browser 
> support. Need solution for browser apps.
> 
> [Daniel Fett]: DPOP is hopefully a simple and concise mechanism.
> 
> [Brian Campbell]: DPOP came out of a desire 

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

[Warren Parad]

(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 the same semantics as possible, except name them:
* Symmetric DPoP for OAuth
* Asymmetric DPoP for OAuth

Handling key exchange is so fundamentally different as well as signature
verification steps, token and source trusting, that I agree having both in
the same document is problematic. Which is the reason I wanted to suggest
what are the non-negotiables for the authors of the new draft.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 9:05 PM David Waite 
wrote:

> 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 RS based on an RS challenge. In
> either case, a symmetric key basis requires resource-constrained keys and
> possibly tokens.
>
> It also makes preventing exfiltration of keys (and the associated tokens)
> harder to prevent - you would likely want to include key derivation in
> grant processes. The HTTP Signature key identifier might actually be from
> the AS or server, and even represent a wrapped key.
>
> I suspect adding this use case to DPoP would be more than a doubling of
> complexity.
>
> IMHO past discussions around symmetric keys were more arguments over
> whether DPoP could be considered complete without that additional
> complexity, due to the computational efficiencies of symmetric keys over
> asymmetric ones. This comes into play when the network/computational and
> complexity costs of a per-RS key/token negotiation is dwarfed by the
> ongoing use of that token to talk to a particular RS.
>
> This also means that it is primarily a concern when MTLS is not possible,
> as MTLS will negotiate a symmetric key at a lower level anyway.
>
> -DW
>
> On Oct 13, 2021, at 3:51 AM, Warren Parad  wrote:
>
> 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 interested in improving, for instance *cnf *being an array, and
> attempting to utilize the Authorization header more effectively, but this
> isn't the thread to discuss those. Is there a reason we can't just improve
> the existing DPoP draft to remove the limitations you listed above?
>
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
>
>> David, Warren, Hannes and others:
>>
>> The limitations of DPoP and mTLS have been discussed numerous times
>> within the Working Group. Here is a summary of those that I am aware of;
>> others may have additional concerns.
>>
>> (Though please note first that none of this is to say that DPoP and mTLS
>> are bad or useless – they each are targeted at certain use cases, and they
>> serve those well. They just don't serve *every* use case well.)
>>
>> DPoP Limitations:
>>
>>1. Does not support symmetric keys.
>>2. Requires the same key to be used with AS and RSes.
>>3. Does not support multiple valid signing keys.
>>4. Signed content is copied into the JWT and therefore duplicated
>>within the message. This allows for bugs where the verifier fails to check
>>that these values match, or performs that check incorrectly. (e.g.,
>>assuming case insensitivity)
>>5. Only covers the method, scheme, host, and path. Allows for
>>additional arbitrary content to be signed, but does not provide any
>>guidance or support for defining interoperable extensions.
>>6. Depends on JWT, which may be a new dependency, particularly for
>>clients that are doing OAuth 2.0 but not OIDC.
>>
>>
>> mTLS Limitations:
>>
>>1. Requires a single end-to-end TLS connection between client and
>>AS/RS. This often is not the case in modern distributed systems, e.g., TLS
>>may be terminated at a load balancer, or by the hosting platform in the
>>case of a "serverless" application. On the client side, enterprises may
>>have TLS inspection appliances that break the TLS connection.
>>2. Abysmal user experience in the browser. (though that is what DPoP
>>was intended to address, at least initially)
>>
>>
>> In contrast, Justin's HTTP Message Signatures-based approach:
>>
>>1. Allows for 

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

[Warren Parad]

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 keeping DPoP simple if it meant that 99% of problems
were solved, in which case the question would be why do we need this RFC,
and if what is here is so common, then what good is the DPoP one? Simple is
useless if it is never used.

If there are really so many cases, then I think we need to focus on
recreating PoP in an extensible way that allows the DPoP to sit on top, and
other RFCs to be layered in without a bunch of RFCs to all have competing
semantics.

Here's a great example. I think having an additional header is unjustified,
DPoP, Signature, or whatever you want to call it. But the only thing more
unjustified than that is having different headers for different
implementations of PoP. We can start with a new Draft that just says, PoP
header is X, end of story, might as well call it *Authorization-Extra-Info*,
and then layer in what you want in there. Then the number of differences
through these refactoring between these two drafts becomes smaller. Surely
we can agree to a draft that contains only the semantics that are the same
between the existing two, and then reuse the same terminology and the same
implementation, header name, etc...

We definitely need a PoP RFC, there's no question there (at least I don't
think there is), so let's start with the subset of all pieces that both
sets of authors can agree to.

Is this the list of current concerning limitations?

>
>1. Does not support symmetric keys.
>2. Requires the same key to be used with AS and RSes.
>3. Does not support multiple valid signing keys.
>4. Signed content is copied into the JWT and therefore duplicated
>within the message. This allows for bugs where the verifier fails to check
>that these values match, or performs that check incorrectly. (e.g.,
>assuming case insensitivity)
>5. Only covers the method, scheme, host, and path. Allows for
>additional arbitrary content to be signed, but does not provide any
>guidance or support for defining interoperable extensions.
>6. Depends on JWT, which may be a new dependency, particularly for
>clients that are doing OAuth 2.0 but not OIDC.
>
> Can we narrow this down to the non-negotiables? For instance surely (1),
(4), (6) aren't that bad, sure they may not be optimal for every case. I
can (2) & (3) to be actually limiting and (5) to be easy to allow
extensibility. Would your concerns be at least somewhat be mitigated by
allowing for solutions regarding (2) & (3)?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 8:41 PM David Waite  wrote:

>
>
> > On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle <
> richa...@amazon.com> 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 have
> pushed back on extending DPoP to cover additional use cases them due to a
> desire to keep DPoP simple and lightweight. I don't begrudge them that. I
> think it's reasonable to have a "dirt simple" solution, particularly for
> SPAs given the relative limitations of the browser environment.
> >
> > Other issues are inherent to fundamental design choices, such as the use
> of JWS to prove possession of the key. E.g., you cannot avoid the data
> duplication issue since a JWS signature only covers a specific
> serialization of the JWT header and body.
>
> 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. The
> current draft being proposed for adoption I believe is fixed to the same
> HTTP properties that DPoP leverages, and thus appears to be targeting the
> same use cases with a different proof expression.
>
> The duplication within the token is also a trade-off: it allows an
> implementation to have a white list of acceptable internal values, if say
> the host and path are rewritten by reverse proxies. It also allows an
> implementation to give richer diagnostic information when receiving
> unacceptable DPoP tokens, which may very well come at runtime from an
> independently-operating portion of an organization reconfiguring
> intermediaries.
>
> -DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

> 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 have pushed back 
> on extending DPoP to cover additional use cases them due to a desire to keep 
> DPoP simple and lightweight. I don't begrudge them that. I think it's 
> reasonable to have a "dirt simple" solution, particularly for SPAs given the 
> relative limitations of the browser environment.
> 
> Other issues are inherent to fundamental design choices, such as the use of 
> JWS to prove possession of the key. E.g., you cannot avoid the data 
> duplication issue since a JWS signature only covers a specific serialization 
> of the JWT header and body.

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. The current 
draft being proposed for adoption I believe is fixed to the same HTTP 
properties that DPoP leverages, and thus appears to be targeting the same use 
cases with a different proof expression.

The duplication within the token is also a trade-off: it allows an 
implementation to have a white list of acceptable internal values, if say the 
host and path are rewritten by reverse proxies. It also allows an 
implementation to give richer diagnostic information when receiving 
unacceptable DPoP tokens, which may very well come at runtime from an 
independently-operating portion of an organization reconfiguring intermediaries.

-DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

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, at 11:16 AM, Mike Jones 
>  wrote:
> 
> 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
>  revoke (when possible) all tokens previously issued based on
>  that authorization code.”
>  
> The rationale given was that enforcing one-time use is impractical in 
> distributed authorization server deployments.
>  
> Thinking about this some more, at most, we should relax this to:
>  The client MUST NOT use the authorization code
>  more than once.  If an authorization code is used more than
>  once, the authorization server SHOULD deny the request and SHOULD
>  revoke (when possible) all tokens previously issued based on
>  that authorization code.”
>  
> In short, it should remain illegal for the client to try to reuse the 
> authorization code.  We can relax the MUST to SHOULD in the server 
> requirements in recognition of the difficulty of enforcing the MUST.
>  
> Code reuse is part of some attack scenarios.  We must not sanction it.
>  
>   -- Mike
>  
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

(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
roundtrip through libraries.)

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 8:15 PM Jeff Craig  wrote:

> OAuth 2.1 makes PKCE a requirement.
>
> I'm of two minds about PKCE for Confidential Clients, but it isn't a
> substantially more complex flow even if Confidential Clients benefit far
> less from PKCE than Public Clients, and I see the benefit to always doing
> it.
>
> I am inclined to agree that with PKCE, replay attacks are substantially
> less of a risk, but I need to think more about this (and I missed today's
> meeting, so I should look over the notes before commenting too deeply).
>
> On Wed, Oct 13, 2021 at 1:03 PM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
>> 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 user data with IAM authorization as a service. Implement
>> Authress .
>>
>>
>> On Wed, Oct 13, 2021 at 7:59 PM Neil Madden 
>> wrote:
>>
>>> 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 see anything in the minutes of the meeting describing the
>>> difficulty of implementing the one-time use req. I seem to see
>>> announcements for new globally-consistent high-scale cloud database
>>> services every day - is this really that hard to implement?
>>>
>>> — Neil
>>>
>>> On 13 Oct 2021, at 18:41, Aaron Parecki  wrote:
>>>
>>> 
>>> 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 as it
>>> doesn't provide any additional benefit.
>>>
>>> If anyone can think of a possible attack by allowing authorization codes
>>> to be reused *even with a valid PKCE code verifier* then that would warrant
>>> keeping this requirement.
>>>
>>> ---
>>> Aaron Parecki
>>>
>>>
>>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad >> 40rhosys...@dmarc.ietf.org> wrote:
>>>
 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 than flat out saying: *sure, there's a valid reason*

 In other words, how do we think about RFCs? Do they exist to be
 followed to the letter or not at all? Or do they exist to stipulate this is
 the way, but acknowledge that not everyone will build a solution that holds
 them as law.

 Let's look at *SHOULD*

> This word, or the adjective "RECOMMENDED", mean that there may exist
> valid reasons in particular circumstances to ignore a particular item, but
> the full implications must be understood and carefully weighed before
> choosing a different course.


 I think *recommended* here is not sufficient nor are there valid
 reasons. "It's too hard" isn't really a valid reason. Isn't it better in
 this case for an AS to not be compliant with the RFC, than it is to relax
 this to SHOULD and have lots of AS thinking reusing auth codes is a viable
 solution, "because they are a special snowflake where SHOULD should apply".

 Are we setting the standard or instead attempting to sustain a number
 of "AS that are in compliance with the RFC"?


 Warren Parad

 Founder, CTO
 Secure your user data with IAM authorization as a service. Implement
 Authress .


 On Wed, Oct 13, 2021 at 7:17 PM Mike Jones >>> 40microsoft@dmarc.ietf.org> wrote:

> 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
>
>   

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

[Aaron Parecki]

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 using the "plain" type
but that may not be enough confidence to rely on this mechanism and give up
others.

Aaron



On Wed, Oct 13, 2021 at 11:02 AM Warren Parad  wrote:

> 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 user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Oct 13, 2021 at 7:59 PM Neil Madden 
> wrote:
>
>> 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 see anything in the minutes of the meeting describing the
>> difficulty of implementing the one-time use req. I seem to see
>> announcements for new globally-consistent high-scale cloud database
>> services every day - is this really that hard to implement?
>>
>> — Neil
>>
>> On 13 Oct 2021, at 18:41, Aaron Parecki  wrote:
>>
>> 
>> 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 as it
>> doesn't provide any additional benefit.
>>
>> If anyone can think of a possible attack by allowing authorization codes
>> to be reused *even with a valid PKCE code verifier* then that would warrant
>> keeping this requirement.
>>
>> ---
>> Aaron Parecki
>>
>>
>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad > 40rhosys...@dmarc.ietf.org> wrote:
>>
>>> 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 than flat out saying: *sure, there's a valid reason*
>>>
>>> In other words, how do we think about RFCs? Do they exist to be followed
>>> to the letter or not at all? Or do they exist to stipulate this is the way,
>>> but acknowledge that not everyone will build a solution that holds them as
>>> law.
>>>
>>> Let's look at *SHOULD*
>>>
 This word, or the adjective "RECOMMENDED", mean that there may exist
 valid reasons in particular circumstances to ignore a particular item, but
 the full implications must be understood and carefully weighed before
 choosing a different course.
>>>
>>>
>>> I think *recommended* here is not sufficient nor are there valid
>>> reasons. "It's too hard" isn't really a valid reason. Isn't it better in
>>> this case for an AS to not be compliant with the RFC, than it is to relax
>>> this to SHOULD and have lots of AS thinking reusing auth codes is a viable
>>> solution, "because they are a special snowflake where SHOULD should apply".
>>>
>>> Are we setting the standard or instead attempting to sustain a number of
>>> "AS that are in compliance with the RFC"?
>>>
>>>
>>> Warren Parad
>>>
>>> Founder, CTO
>>> Secure your user data with IAM authorization as a service. Implement
>>> Authress .
>>>
>>>
>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones >> 40microsoft@dmarc.ietf.org> wrote:
>>>
 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

  revoke (when possible) all tokens previously issued based on

  that authorization code.”



 The rationale given was that enforcing one-time use is impractical in
 distributed authorization server deployments.



 Thinking about this some more, at most, we should relax this to:

  The client MUST NOT use the authorization code

  more than once.  If an authorization code is used more than

  once, the authorization server SHOULD deny the request and
 SHOULD

  revoke (when possible) all tokens previously issued based on

  that authorization code.”

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

[Warren Parad]

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 user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 7:59 PM Neil Madden 
wrote:

> 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 see anything in the minutes of the meeting describing the
> difficulty of implementing the one-time use req. I seem to see
> announcements for new globally-consistent high-scale cloud database
> services every day - is this really that hard to implement?
>
> — Neil
>
> On 13 Oct 2021, at 18:41, Aaron Parecki  wrote:
>
> 
> 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 as it
> doesn't provide any additional benefit.
>
> If anyone can think of a possible attack by allowing authorization codes
> to be reused *even with a valid PKCE code verifier* then that would warrant
> keeping this requirement.
>
> ---
> Aaron Parecki
>
>
> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
>> 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 than flat out saying: *sure, there's a valid reason*
>>
>> In other words, how do we think about RFCs? Do they exist to be followed
>> to the letter or not at all? Or do they exist to stipulate this is the way,
>> but acknowledge that not everyone will build a solution that holds them as
>> law.
>>
>> Let's look at *SHOULD*
>>
>>> This word, or the adjective "RECOMMENDED", mean that there may exist
>>> valid reasons in particular circumstances to ignore a particular item, but
>>> the full implications must be understood and carefully weighed before
>>> choosing a different course.
>>
>>
>> I think *recommended* here is not sufficient nor are there valid
>> reasons. "It's too hard" isn't really a valid reason. Isn't it better in
>> this case for an AS to not be compliant with the RFC, than it is to relax
>> this to SHOULD and have lots of AS thinking reusing auth codes is a viable
>> solution, "because they are a special snowflake where SHOULD should apply".
>>
>> Are we setting the standard or instead attempting to sustain a number of
>> "AS that are in compliance with the RFC"?
>>
>>
>> Warren Parad
>>
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement
>> Authress .
>>
>>
>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones > 40microsoft@dmarc.ietf.org> wrote:
>>
>>> 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
>>>
>>>  revoke (when possible) all tokens previously issued based on
>>>
>>>  that authorization code.”
>>>
>>>
>>>
>>> The rationale given was that enforcing one-time use is impractical in
>>> distributed authorization server deployments.
>>>
>>>
>>>
>>> Thinking about this some more, at most, we should relax this to:
>>>
>>>  The client MUST NOT use the authorization code
>>>
>>>  more than once.  If an authorization code is used more than
>>>
>>>  once, the authorization server SHOULD deny the request and
>>> SHOULD
>>>
>>>  revoke (when possible) all tokens previously issued based on
>>>
>>>  that authorization code.”
>>>
>>>
>>>
>>> In short, it should remain illegal for the client to try to reuse the
>>> authorization code.  We can relax the MUST to SHOULD in the server
>>> requirements in recognition of the difficulty of enforcing the MUST.
>>>
>>>
>>>
>>> Code reuse is part of some attack scenarios.  We must not sanction it.
>>>
>>>
>>>
>>>   -- Mike
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth 

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

[Neil Madden]

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 see anything in the minutes of the meeting describing the difficulty of 
implementing the one-time use req. I seem to see announcements for new 
globally-consistent high-scale cloud database services every day - is this 
really that hard to implement?

— Neil

> On 13 Oct 2021, at 18:41, Aaron Parecki  wrote:
> 
> 
> 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 as it doesn't 
> provide any additional benefit.
> 
> If anyone can think of a possible attack by allowing authorization codes to 
> be reused *even with a valid PKCE code verifier* then that would warrant 
> keeping this requirement.
> 
> ---
> Aaron Parecki
> 
> 
>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad 
>>  wrote:
>> 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 than flat out saying: sure, there's a valid reason
>> 
>> In other words, how do we think about RFCs? Do they exist to be followed to 
>> the letter or not at all? Or do they exist to stipulate this is the way, but 
>> acknowledge that not everyone will build a solution that holds them as law.
>> 
>> Let's look at SHOULD
>>> This word, or the adjective "RECOMMENDED", mean that there may exist valid 
>>> reasons in particular circumstances to ignore a particular item, but the 
>>> full implications must be understood and carefully weighed before choosing 
>>> a different course.
>> 
>> I think recommended here is not sufficient nor are there valid reasons. 
>> "It's too hard" isn't really a valid reason. Isn't it better in this case 
>> for an AS to not be compliant with the RFC, than it is to relax this to 
>> SHOULD and have lots of AS thinking reusing auth codes is a viable solution, 
>> "because they are a special snowflake where SHOULD should apply".
>> 
>> Are we setting the standard or instead attempting to sustain a number of "AS 
>> that are in compliance with the RFC"?
>>  
>> 
>> Warren Parad
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement 
>> Authress.
>> 
>> 
>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones 
>>>  wrote:
>>> 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
>>> 
>>>  revoke (when possible) all tokens previously issued based on
>>> 
>>>  that authorization code.”
>>> 
>>>  
>>> 
>>> The rationale given was that enforcing one-time use is impractical in 
>>> distributed authorization server deployments.
>>> 
>>>  
>>> 
>>> Thinking about this some more, at most, we should relax this to:
>>> 
>>>  The client MUST NOT use the authorization code
>>> 
>>>  more than once.  If an authorization code is used more than
>>> 
>>>  once, the authorization server SHOULD deny the request and SHOULD
>>> 
>>>  revoke (when possible) all tokens previously issued based on
>>> 
>>>  that authorization code.”
>>> 
>>>  
>>> 
>>> In short, it should remain illegal for the client to try to reuse the 
>>> authorization code.  We can relax the MUST to SHOULD in the server 
>>> requirements in recognition of the difficulty of enforcing the MUST.
>>> 
>>>  
>>> 
>>> Code reuse is part of some attack scenarios.  We must not sanction it.
>>> 
>>>  
>>> 
>>>   -- Mike
>>> 
>>>  
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Manage My Preferences , Unsubscribe 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

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 as it
doesn't provide any additional benefit.

If anyone can think of a possible attack by allowing authorization codes to
be reused *even with a valid PKCE code verifier* then that would warrant
keeping this requirement.

---
Aaron Parecki


On Wed, Oct 13, 2021 at 10:27 AM Warren Parad  wrote:

> 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 than flat out saying: *sure, there's a valid reason*
>
> In other words, how do we think about RFCs? Do they exist to be followed
> to the letter or not at all? Or do they exist to stipulate this is the way,
> but acknowledge that not everyone will build a solution that holds them as
> law.
>
> Let's look at *SHOULD*
>
>> This word, or the adjective "RECOMMENDED", mean that there may exist
>> valid reasons in particular circumstances to ignore a particular item, but
>> the full implications must be understood and carefully weighed before
>> choosing a different course.
>
>
> I think *recommended* here is not sufficient nor are there valid reasons.
> "It's too hard" isn't really a valid reason. Isn't it better in this case
> for an AS to not be compliant with the RFC, than it is to relax this to
> SHOULD and have lots of AS thinking reusing auth codes is a viable
> solution, "because they are a special snowflake where SHOULD should apply".
>
> Are we setting the standard or instead attempting to sustain a number of
> "AS that are in compliance with the RFC"?
>
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
>> 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
>>
>>  revoke (when possible) all tokens previously issued based on
>>
>>  that authorization code.”
>>
>>
>>
>> The rationale given was that enforcing one-time use is impractical in
>> distributed authorization server deployments.
>>
>>
>>
>> Thinking about this some more, at most, we should relax this to:
>>
>>  The client MUST NOT use the authorization code
>>
>>  more than once.  If an authorization code is used more than
>>
>>  once, the authorization server SHOULD deny the request and
>> SHOULD
>>
>>  revoke (when possible) all tokens previously issued based on
>>
>>  that authorization code.”
>>
>>
>>
>> In short, it should remain illegal for the client to try to reuse the
>> authorization code.  We can relax the MUST to SHOULD in the server
>> requirements in recognition of the difficulty of enforcing the MUST.
>>
>>
>>
>> Code reuse is part of some attack scenarios.  We must not sanction it.
>>
>>
>>
>>   -- Mike
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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 than flat out saying: *sure, there's a valid reason*

In other words, how do we think about RFCs? Do they exist to be followed to
the letter or not at all? Or do they exist to stipulate this is the way,
but acknowledge that not everyone will build a solution that holds them as
law.

Let's look at *SHOULD*

> This word, or the adjective "RECOMMENDED", mean that there may exist valid
> reasons in particular circumstances to ignore a particular item, but the
> full implications must be understood and carefully weighed before choosing
> a different course.


I think *recommended* here is not sufficient nor are there valid reasons.
"It's too hard" isn't really a valid reason. Isn't it better in this case
for an AS to not be compliant with the RFC, than it is to relax this to
SHOULD and have lots of AS thinking reusing auth codes is a viable
solution, "because they are a special snowflake where SHOULD should apply".

Are we setting the standard or instead attempting to sustain a number of
"AS that are in compliance with the RFC"?


Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 7:17 PM Mike Jones  wrote:

> 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
>
>  revoke (when possible) all tokens previously issued based on
>
>  that authorization code.”
>
>
>
> The rationale given was that enforcing one-time use is impractical in
> distributed authorization server deployments.
>
>
>
> Thinking about this some more, at most, we should relax this to:
>
>  The client MUST NOT use the authorization code
>
>  more than once.  If an authorization code is used more than
>
>  once, the authorization server SHOULD deny the request and SHOULD
>
>  revoke (when possible) all tokens previously issued based on
>
>  that authorization code.”
>
>
>
> In short, it should remain illegal for the client to try to reuse the
> authorization code.  We can relax the MUST to SHOULD in the server
> requirements in recognition of the difficulty of enforcing the MUST.
>
>
>
> Code reuse is part of some attack scenarios.  We must not sanction it.
>
>
>
>   -- Mike
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Authorization code reuse and OAuth 2.1

[Mike Jones]

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
 revoke (when possible) all tokens previously issued based on
 that authorization code."

The rationale given was that enforcing one-time use is impractical in 
distributed authorization server deployments.

Thinking about this some more, at most, we should relax this to:
 The client MUST NOT use the authorization code
 more than once.  If an authorization code is used more than
 once, the authorization server SHOULD deny the request and SHOULD
 revoke (when possible) all tokens previously issued based on
 that authorization code."

In short, it should remain illegal for the client to try to reuse the 
authorization code.  We can relax the MUST to SHOULD in the server requirements 
in recognition of the difficulty of enforcing the MUST.

Code reuse is part of some attack scenarios.  We must not sanction it.

  -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef via Datatracker]

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/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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 interested in improving, for instance *cnf *being an array, and
attempting to utilize the Authorization header more effectively, but this
isn't the thread to discuss those. Is there a reason we can't just improve
the existing DPoP draft to remove the limitations you listed above?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle  wrote:

> David, Warren, Hannes and others:
>
> The limitations of DPoP and mTLS have been discussed numerous times within
> the Working Group. Here is a summary of those that I am aware of; others
> may have additional concerns.
>
> (Though please note first that none of this is to say that DPoP and mTLS
> are bad or useless – they each are targeted at certain use cases, and they
> serve those well. They just don't serve *every* use case well.)
>
> DPoP Limitations:
>
>1. Does not support symmetric keys.
>2. Requires the same key to be used with AS and RSes.
>3. Does not support multiple valid signing keys.
>4. Signed content is copied into the JWT and therefore duplicated
>within the message. This allows for bugs where the verifier fails to check
>that these values match, or performs that check incorrectly. (e.g.,
>assuming case insensitivity)
>5. Only covers the method, scheme, host, and path. Allows for
>additional arbitrary content to be signed, but does not provide any
>guidance or support for defining interoperable extensions.
>6. Depends on JWT, which may be a new dependency, particularly for
>clients that are doing OAuth 2.0 but not OIDC.
>
>
> mTLS Limitations:
>
>1. Requires a single end-to-end TLS connection between client and
>AS/RS. This often is not the case in modern distributed systems, e.g., TLS
>may be terminated at a load balancer, or by the hosting platform in the
>case of a "serverless" application. On the client side, enterprises may
>have TLS inspection appliances that break the TLS connection.
>2. Abysmal user experience in the browser. (though that is what DPoP
>was intended to address, at least initially)
>
>
> In contrast, Justin's HTTP Message Signatures-based approach:
>
>1. Allows for flexibility regarding key selection.
>2. Allows signing of as much or as little of the HTTP message as is
>appropriate for the request.
>3. Does not duplicate signed content.
>4. Does not depend on JWT, unless you want it to.
>5. Does not depend on an end-to-end TLS connection, or any other
>specifics below the HTTP layer.
>6. Allows servers to use the same signature mechanism for other HTTP
>signing use cases. (e.g., browser signing authorization cookies, LBs adding
>a signature over the `X-Forwarded-For` header field)
>
>
> Note that these concerns regarding use cases not addressed by DPoP and
> mTLS are not new. Below are excerpts taken from WG meeting notes going back
> to 2019:
>
>
>- IETF 105
>:
>   - MTLS is good but not great for browser. TOKBIND has no current
>   browser support. Need solution for browser apps.
>
>   - [Daniel Fett]: DPOP is hopefully a simple and concise mechanism.
>
>   - [Brian Campbell]: DPOP came out of a desire for a simplified
>   concise public key mechanism at both the authz and resource 
> server….there
>   isn’t the overhead for symmetric keys.
>
>   - [Annabelle Backman]: We too find [DPoP] limiting without
>   symmetric as asymmetric can be just too slow.
>
>   - [John Bradley]: The origin of [DPoP] came from the security
>   workshop specifically focused on applications to do PoP should token
>   binding not come to fruition. We could use web-crypto and create a
>   non-exportable key in the browser. This is why there is no support for
>   symmetric key.
>
>   - [Mike Jones]: Want to use different POP keys for AT and RT.
>
>   - [Justin Richer]: I really like this approach. But I agree with
>   Hannes that having a server provided symmetric key is useful.
>
>   - Roman [Danyliw]: Strongly urge the equities of other groups and
>   surface them.
>
>   - IETF 106
>
> :
>
>   - Annabelle [Backman]: Would you consider using a HTTP signing
>   solution and not do this
>   John [Bradley]: ...[DPoP] has limited aspirations than the http
>   signing.
>
>   - Some discussions on symmetric vs asymmetric encryption and
>   Annabelle is concerned about