Re: [OAUTH-WG] PAR - Can AS/client require request object?

[Torsten Lodderstedt]

Hi all,

I initially raised the question whether the AS should be able to require 
request objects for all clients (in the same way as we decided to let the AS 
required PAR for all clients) but this topic was never discussed later on. 

I suggest to add a server metadata parameter “require_request_objects” so the 
AS can indicate its policy to clients. 

I think the best place to define this parameter would be JAR, if that is not 
possible any longer, we could use a different PAR-specific name and add it to 
PAR.

What do you think?

best regards,
Torsten. 

> On 1. May 2020, at 17:56, Mike Jones 
>  wrote:
> 
> Works for me.
> 
>  
> 
> From: OAuth  On Behalf Of Torsten Lodderstedt
> Sent: Friday, May 1, 2020 2:51 AM
> To: Brian Campbell 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
> 
>  
> 
> Filip´s proposal works for me.
> 
>  
> 
> Are there any objections?
> 
>  
> 
> Brian Campbell  schrieb am Mo. 
> 27. Apr. 2020 um 20:57:
> 
> While there are certainly different permutations and contexts of use that 
> could be imagine, I tend to agree with Filip here in not seeing a strong need 
> to define new PAR specific metadata around signing/encryption of the request 
> object.
> 
>  
> 
> On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  wrote:
> 
> Considering there's going to be a setting that forces clients to use PAR 
> (other mailinglist thread), then we should rely on the existing 
> `request_object_signing_alg` presence to indicate a Request Object must be 
> used (as suggested by this upcoming OIDC Core errata), regardless of it being 
> PAR or JAR. I don't see the need for a PAR specific metadata, for one - 
> implementations wouldn't be easily able to re-use of existing pipelines, two 
> - yes the contexts differ but do you think clients will be using both 
> channels at the same time? And even if so, the Request Object is the same 
> therefore its applicable to both channels the same.
> 
> 
> Best,
> Filip Skokan
> 
>  
> 
>  
> 
> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt 
>  wrote:
> 
> Hi all, 
> 
> this is one of the topics we quickly flipped through in the virtual meeting 
> last week. 
> 
> I see the following open questions:
> - Can the client require its instances to use request objects only.
> - Are there further requirements on the properties of these objects? Signed 
> only, Signed and encrypted, algorithms? 
> - Can an AS require ALL clients to use request objects only? 
> - Further requirements here as well? 
> - Is this tied to PAR or relevant for JAR as well? 
> 
> In my opinion, client as well as AS should be able to control enforced use of 
> request objects. 
> 
> I could imagine the setting for JAR request objects (“request" parameter) and 
> request objects in the PAR context differ, as the first case goes through the 
> user’s browser whereas the PAR case goes direct from client to AS via a TLS 
> protected channel. I therefore feel the settings should be PAR specific. 
> 
> What do you think?
> 
> best regards,
> Torsten. 
> ___
> 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
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited...  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.
> 

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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Vittorio Bertocci]

It’s not really an interop issue either, given that following or not following 
this requirement doesn’t alter the shape of messages or tokens. It’s more of an 
architectural requirement, which preserves the relationships between the OAuth2 
roles involved and prevents the confusion that might arise by the availability 
of data that characterizes this particular scenario, but that doesn’t change 
the more general premises of the protocol. In terms of finding common ground, I 
am not sure if visions as diametrically opposed as pitting a MUST against a 
MUST NOT have much of an achievable common ground, especially given that the 
MUST NOT stance already passed consensus in the past year, and in more than one 
month of very public debate during last calls, the MUST side had mostly one 
backer and more than one opposed..

From: Jared Jennings 
Date: Monday, May 11, 2020 at 20:14
To: Vittorio Bertocci 
Cc: Denis , Benjamin Kaduk , 
"oa...@ietf..org" 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 
2.0 Access Tokens"

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide implementors from 
making bad choices, not from a security perspective. Meaning, it's not a 
security risk that a client does inspect or analyze the token. Instead, it's is 
an interop issue and thus we are guiding implementors to never assume or expect 
the token format to be consistent or of a expected format, for various reasons. 
I kinda know the answer to this question, but I am kinda asking this way to 
help restate the intent of the "topic" and maybe help guide to a wording that 
works for everyone.

For example, as a consultant, it can be very helpful to know how to decompile 
or inspect an "Object", but at the same time knowing that such a method or 
practice should never be used in production.

Jared



On May 11, 2020, at 19:24, Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>> wrote:

Real world scenarios are full of situations where additional assumptions can 
lower dangers that must be taken in consideration in the general case, which 
might make less of a risk going against the specin those particular 
circumstances, but their existence doesn’t warrant relaxing guidance for the 
general case. A concrete example: I worked on scenarios where resource servers 
wanted to guarantee some degree of business continuity in case of AS outage, 
which boiled down to RS’ willingness to accept ATs past their declared 
expiration time, on the condition that the AS outage condition was detectable 
and the staleness of the AT didn’t cross a tolerance threshold. The business 
scenario made sense, and the implementer was within their right in deciding 
that disregarding exp in those circumstances was acceptable. Nonetheless, I 
would not argue that given the existence of that scenario, rfc7519 should turn 
its MUST NOT into a SHOULD NOT.


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

Re: [OAUTH-WG] Subject: Re: Usage of Password Grant

[Aaron Parecki]

> In the password grant flow, the device holds the password and is not
involved in any interaction with the AS. This keeps the device use case
simple.

I'm not sure what you mean by this. If you're suggesting that the client
never interacts with the AS and sends the password directly to the resource
server, that's never been part of OAuth. That's specifically the situation
OAuth was created to avoid.

The password grant gave the client a way to exchange the password for an
access token by sending it first to the AS. As such, the difference between
the password grant and the client credentials grant is the presence of two
additional parameters in the request to the AS:

POST /token
grant_type=client_credentials
&client_id=X
&client_secret=Y

vs

POST /token
grant_type=password
&client_id=X
&client_secret=Y
&username=Z
&password=Q

The response of both of these is an access token, which the client then
sends to the resource server.

> In order to use Client Credentials in our use case, we need to do dynamic
> registration for the thousands of devices managed by the server

Regardless of which of these two methods you use, the client's credentials
(either client ID/secret or username/password) needs to be enrolled at the
AS in order to get an access token. That's why I'm saying there isn't a
functional difference and trying to clarify why you think the password
grant is a better fit for your situation. In reality for your use case it
seems it is only adding complexity to the situation compared to just using
a client ID and secret.

Aaron Parecki


On Mon, May 11, 2020 at 7:11 PM Francis Pouatcha  wrote:

> Hi Aaron,
>
>>
>>
>> Hi Beena,
>>
>> This sounds like a great use of the client credentials grant. The password
>> grant is being removed from OAuth 2.0 by the Security Best Current
>> Practice. Can you clarify what you've found useful about the password
>> grant
>> that the client credentials grant doesn't solve?
>>
> Beena could use the Dynamic Client Registration to have all those devices
> registered as oAuth Clients. But this seems to be inconvenient as he
> describes.
>
> In the password grant flow, the device holds the password and is not
> involved in any interaction with the AS. This keeps the device use case
> simple.
>
>
>>
>> Aaron Parecki
>>
>>
>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>> beenapurushotha...@gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> >
>> > We have a product with client server architecture where our server
>> manages
>> > thousands of devices. Each device has a client-piece that talks to the
>> > server over SOAP/REST. The client currently uses a HTTP Basic
>> > Authentication (unique id and a secret string) for all the calls. The
>> > secret string is created when the device enrolls to the server. It is
>> > available at the server as well as stored securely on the device. For
>> the
>> > rest calls it is the device that is getting authenticated.
>> >
>> >
>> >
>> >  Sending the credentials every time is less than ideal and we want to
>> move
>> > to some tokenized device authentication. We evaluated OpendID Connect
>> based
>> > on the general recommendation of SSO solution, but the issue is we do
>> not
>> > have any user interaction and hence there is no Grant flow that is
>> fitting.
>> > Hence we evaluated OAuth grant type of which we found Password Grant and
>> > Client Credentials Grant is matching our requirement.
>> >
>> >
>> >
>> >  In order to use Client Credentials in our use case, we need to do
>> dynamic
>> > registration for the thousands of devices managed by the server, if IoT
>> > comes into picture the number is going to be even higher, which is
>> highly
>> > cumbersome to manage.  Also, as per  RFC7591 on dynamic client
>> > registration, using access token for registering client is optional too.
>> > Even though the Password grant is highly discouraged by the spec, we
>> found
>> > it to be highly matching with our requirements.
>> >
>> >
>> >
>> > But as per the Oauth 2.1 proposal, password grant is going to be
>> removed. Can
>> > you suggest the way forward for us? I believe we are not a one-off case.
>> >
>> >
>> > Thank You,
>> >
>> > Beena
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/8873117a/attachment.html
>> >
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> --
>>
>> End of OAuth Digest, Vol 139, Issue 45
>> **
>>
>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.d

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Jared Jennings]

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide implementors from 
making bad choices, not from a security perspective. Meaning, it's not a 
security risk that a client does inspect or analyze the token. Instead, it's is 
an interop issue and thus we are guiding implementors to never assume or expect 
the token format to be consistent or of a expected format, for various reasons. 
I kinda know the answer to this question, but I am kinda asking this way to 
help restate the intent of the "topic" and maybe help guide to a wording that 
works for everyone.

For example, as a consultant, it can be very helpful to know how to decompile 
or inspect an "Object", but at the same time knowing that such a method or 
practice should never be used in production.

Jared


> On May 11, 2020, at 19:24, Vittorio Bertocci  
> wrote:
> 
> Real world scenarios are full of situations where additional assumptions can 
> lower dangers that must be taken in consideration in the general case, which 
> might make less of a risk going against the specin those particular 
> circumstances, but their existence doesn’t warrant relaxing guidance for the 
> general case. A concrete example: I worked on scenarios where resource 
> servers wanted to guarantee some degree of business continuity in case of AS 
> outage, which boiled down to RS’ willingness to accept ATs past their 
> declared expiration time, on the condition that the AS outage condition was 
> detectable and the staleness of the AT didn’t cross a tolerance threshold. 
> The business scenario made sense, and the implementer was within their right 
> in deciding that disregarding exp in those circumstances was acceptable. 
> Nonetheless, I would not argue that given the existence of that scenario, 
> rfc7519 should turn its MUST NOT into a SHOULD NOT.
> 

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

[OAUTH-WG] OAuth 2.1 - recalling ROPC

[Francis Pouatcha]

I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password
Credentials) with the following reasoning:

Auth Code Grant:
There are  many use cases on the market where redirection based flows do
not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the
complexity of user agents on non controllable client devices still make
user agent redirection a challenge.

Client Credentials Grant:
Requires the registration of an oAuth client.
- Citing the iot device use cases Beena which do not have a comfortable way
to have iot devices register with AS.
- This is a registration flow for the oAuth client role  and for the RO
(Resource Owner). Remember resource owner credentials might be sourced from
system external to the AS  like company's LDAP. oAuth Client Credentials
are generally managed by the AS.
For these reasons, we shall not use Client Credential Grant to manage RO
authorization.

ROPC:
Having an oAuth Client proxy the auth request of the RO to the AS only
presents a security risk if the oAuth Client is a third party application.
Therefore, the decision on whether to accept ROPC for a specified client
shall be left to the AS. Discarding this use case will take a lot of
business from oAuth servers back to the old market.

Beside this, I mentioned in my previous post that there are use cases in
the market where permanent passwords are replaced with one time passwords.

A lot of work is also being done in the direction of having the RO send
signed proof of ownership to the AS through the ROPC  flow using the
password field.

Therefore, I am ok with raising the attention of  implementers the same way
we are doing with PKCE,  mentioning that ROPC  must only be used if  AS /
oAuth Client can guarantee security of the RO credentials exposed to the
oAuth Client.

/Francis
-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Subject: Re: Usage of Password Grant

[Francis Pouatcha]

Hi Aaron,

>
>
> Hi Beena,
>
> This sounds like a great use of the client credentials grant. The password
> grant is being removed from OAuth 2.0 by the Security Best Current
> Practice. Can you clarify what you've found useful about the password grant
> that the client credentials grant doesn't solve?
>
Beena could use the Dynamic Client Registration to have all those devices
registered as oAuth Clients. But this seems to be inconvenient as he
describes.

In the password grant flow, the device holds the password and is not
involved in any interaction with the AS. This keeps the device use case
simple.


>
> Aaron Parecki
>
>
> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
> beenapurushotha...@gmail.com>
> wrote:
>
> > Hi,
> >
> >
> > We have a product with client server architecture where our server
> manages
> > thousands of devices. Each device has a client-piece that talks to the
> > server over SOAP/REST. The client currently uses a HTTP Basic
> > Authentication (unique id and a secret string) for all the calls. The
> > secret string is created when the device enrolls to the server. It is
> > available at the server as well as stored securely on the device. For the
> > rest calls it is the device that is getting authenticated.
> >
> >
> >
> >  Sending the credentials every time is less than ideal and we want to
> move
> > to some tokenized device authentication. We evaluated OpendID Connect
> based
> > on the general recommendation of SSO solution, but the issue is we do not
> > have any user interaction and hence there is no Grant flow that is
> fitting.
> > Hence we evaluated OAuth grant type of which we found Password Grant and
> > Client Credentials Grant is matching our requirement.
> >
> >
> >
> >  In order to use Client Credentials in our use case, we need to do
> dynamic
> > registration for the thousands of devices managed by the server, if IoT
> > comes into picture the number is going to be even higher, which is highly
> > cumbersome to manage.  Also, as per  RFC7591 on dynamic client
> > registration, using access token for registering client is optional too.
> > Even though the Password grant is highly discouraged by the spec, we
> found
> > it to be highly matching with our requirements.
> >
> >
> >
> > But as per the Oauth 2.1 proposal, password grant is going to be
> removed. Can
> > you suggest the way forward for us? I believe we are not a one-off case.
> >
> >
> > Thank You,
> >
> > Beena
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/8873117a/attachment.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
>
> End of OAuth Digest, Vol 139, Issue 45
> **
>


-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-bradley-oauth-jwt-encoded-state-09

[Aaron Parecki]

Hi John,

I noticed this individual draft expired a little over a year ago. Do you
have any intention of picking up this work again?

https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-09

Thanks!

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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Vittorio Bertocci]

Thank you Jared for your comment!
I have to admit I have been very tempted to go that route, mostly for moving 
things forward, but I still think we’d do the reader a disservice by relaxing 
the language there.
Real world scenarios are full of situations where additional assumptions can 
lower dangers that must be taken in consideration in the general case, which 
might make less of a risk going against the spec in those particular 
circumstances, but their existence doesn’t warrant relaxing guidance for the 
general case. A concrete example: I worked on scenarios where resource servers 
wanted to guarantee some degree of business continuity in case of AS outage, 
which boiled down to RS’ willingness to accept ATs past their declared 
expiration time, on the condition that the AS outage condition was detectable 
and the staleness of the AT didn’t cross a tolerance threshold. The business 
scenario made sense, and the implementer was within their right in deciding 
that disregarding exp in those circumstances was acceptable. Nonetheless, I 
would not argue that given the existence of that scenario, rfc7519 should turn 
its MUST NOT into a SHOULD NOT.
There might be circumstances in which the stars align and it is safe for a 
client to inspect the AT, but in the general case that’s not true (this has 
been covered in details in the various threads on the topic). Also note, the 
fact that the client (as the application code) is banned from doing that 
inspection doesn’t mean that the solution as a whole cannot do it. Developers 
can examine network traces, or use any other mechanism available in their 
particular circumstances to inspect traffic that are out of scope for this 
specification, and that would give them in practice the oversight discussed 
here where possible. The specification doesn’t aim at preventing that 
inspection in general, but it does aim at ensuring that the ability to do 
perform that is excluded from the contract between the roles described in 
OAuth2, so that any violation is either understood to be high bar, or the logic 
meant to perform those checks is implemented outside of the client code itself, 
preserving the protocol invariants and protecting developers from one of the 
most painful production issues I have observed in many years of real life use 
of JWT ATs.
Ultimately, the latter part is one of the reasons for which I have a hard time 
relaxing this part, whereas pretty easily relaxed constraints on other areas 
where my initial position was more strict (multiple resources in audience, 
etc). I know this to be very painful if not addressed correctly, and the only 
arguments against it appear to be more about principle than about concrete 
scenarios, expressive power or security.

From: Jared Jennings 
Date: Monday, May 11, 2020 at 06:30
To: Denis 
Cc: Benjamin Kaduk , Vittorio Bertocci 
, "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 
2.0 Access Tokens"

If I may, step in and offer a suggestion.

What if instead of "MUST NOT" replace with "SHOULD NOT"?

To me, (and this might be me), but MUST NOT describes a violation. As in I 
broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a 
guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the token, 
the risk is therefore known and on the "implementer" of the inspection.

Jared


On Mon, May 11, 2020 at 7:34 AM Denis 
mailto:denis.i...@free.fr>> wrote:
Hi Benjamin,

We are making progress since we now understand better each other. You wrote 
several sentences on which I agree:
"I do in fact agree that token inspection by a client can be useful in at least 
some situations".

"I fully support having privacy considerations sections that discuss the 
privacy properties of the protocol in question,
  even including aspects that are currently lacking.

"I do not believe that a JWT profile for OAuth use is the place to make changes 
to the core OAuth protocol that improve its privacy properties".
I also accept your apologies.

RFC 6749 is quite clear in section 1.4 that "The string [access token] is 
usually opaque to the client".
However, it does not mean that : "The client MUST NOT inspect the content of 
the access token".
I believe the wording I proposed corresponds to the reality:
There is no guarantee that token inspection can always be performed.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

[Mike Jones]

That works for me.  Thanks all for the useful back-and-forth that got us to 
this point of clarity.  I suspect many of us learned things along the way; I 
know that I did!

   Cheers,
   -- Mike

From: Aaron Parecki 
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG 
Cc: Neil Madden ; Mike Jones 

Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also update 
section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into the
authorization response by attackers. The use of the `code_challenge`
parameter is RECOMMENDED to this end. For confidential clients, the
OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used
instead of or in addition to the `code_challenge` parameter for this
purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
transaction-specific and securely bound to the client and the user agent
in which the transaction was started.

This change better clarifies the specific circumstances under which the "nonce" 
parameter is sufficient to protect against authorization code injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden 
mailto:neil.mad...@forgerock.com>> wrote:
I am happy with this proposed wording. Thanks for updating it.

— Neil


On 11 May 2020, at 19:52, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!

We would like to propose the following text, which is a slight variation from 
the text Neil proposed. This would replace the paragraph in 4.1.2.1 
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that 
begins with "If the client does not send the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clients, and 
MUST reject such requests from other clients unless there is reasonable 
assurance that the client mitigates authorization code injection in other ways. 
See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0 and 
2.1 clients simultaneously. The change from Neil's text is the clarification of 
which threats, and changing to MUST instead of SHOULD. The "MUST...unless" is 
more specific than "SHOULD", and since we are already describing the explicit 
exception to the rule, it's more clear as a MUST here.

Aaron Parecki




___
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] proposed resolution for PKCE in OAuth 2.1

[Aaron Parecki]

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also
update section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into the
authorization response by attackers. The use of the `code_challenge`
parameter is RECOMMENDED to this end. For confidential clients, the
OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used
instead of or in addition to the `code_challenge` parameter for this
purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
transaction-specific and securely bound to the client and the user agent
in which the transaction was started.

This change better clarifies the specific circumstances under which the
"nonce" parameter is sufficient to protect against authorization code
injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden 
wrote:

> I am happy with this proposed wording. Thanks for updating it.
>
> — Neil
>
> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
>
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
>
> We would like to propose the following text, which is a slight variation
> from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1)
> that begins with "If the client does not send the "code_challenge" in the
> request..."
>
> "An AS MUST reject requests without a code_challenge from public clients,
> and MUST reject such requests from other clients unless there is reasonable
> assurance that the client mitigates authorization code injection in other
> ways. See section 9.7 for details."
>
> Section 9.7 is where the nuances of PKCE vs nonce are described.
>
> As Neil described, we believe this will allow ASs to support both OAuth
> 2.0 and 2.1 clients simultaneously. The change from Neil's text is the
> clarification of which threats, and changing to MUST instead of SHOULD. The
> "MUST...unless" is more specific than "SHOULD", and since we are already
> describing the explicit exception to the rule, it's more clear as a MUST
> here.
>
> Aaron Parecki
>
>
>
>
> ___
> 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] I-D Action: draft-ietf-oauth-jwsreq-22.txt

[Nat Sakimura]

Torsten,

Thanks. I just updated the draft.

Best,

Nat Sakimura

On Sun, May 10, 2020 at 10:26 PM Torsten Lodderstedt  wrote:

> I just read over the diff between -21 and -22 and realised the example in
> Section 5.2.2.
>
> https://server.example.com/authorize?
>response_type=code%20id_token
>&client_id=s6BhdRkqt3
>&request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
>%2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
>
>  still has the “response_type" parameter. I think this parameter should be
> removed.
>
>
>
> > On 10. May 2020, at 02:51, internet-dra...@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol WG of the
> IETF.
> >
> >Title   : The OAuth 2.0 Authorization Framework: JWT
> Secured Authorization Request (JAR)
> >Authors : Nat Sakimura
> >  John Bradley
> >   Filename: draft-ietf-oauth-jwsreq-22.txt
> >   Pages   : 32
> >   Date: 2020-05-07
> >
> > Abstract:
> >   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
> >   query parameter serialization, which means that Authorization Request
> >   parameters are encoded in the URI of the request and sent through
> >   user agents such as web browsers.  While it is easy to implement, it
> >   means that (a) the communication through the user agents are not
> >   integrity protected and thus the parameters can be tainted, and (b)
> >   the source of the communication is not authenticated.  Because of
> >   these weaknesses, several attacks to the protocol have now been put
> >   forward.
> >
> >   This document introduces the ability to send request parameters in a
> >   JSON Web Token (JWT) instead, which allows the request to be signed
> >   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
> >   (JWE) so that the integrity, source authentication and
> >   confidentiality property of the Authorization Request is attained.
> >   The request can be sent by value or by reference.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-22
> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-22
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-22
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > ___
> > 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
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-23.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : The OAuth 2.0 Authorization Framework: JWT Secured 
Authorization Request (JAR)
Authors : Nat Sakimura
  John Bradley
Filename: draft-ietf-oauth-jwsreq-23.txt
Pages   : 32
Date: 2020-05-11

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-23


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

[Neil Madden]

I am happy with this proposed wording. Thanks for updating it.

— Neil

> On 11 May 2020, at 19:52, Aaron Parecki  wrote:
> 
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! 
> 
> We would like to propose the following text, which is a slight variation from 
> the text Neil proposed. This would replace the paragraph in 4.1.2.1 
> (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1 
> ) 
> that begins with "If the client does not send the "code_challenge" in the 
> request..."
> 
> "An AS MUST reject requests without a code_challenge from public clients, and 
> MUST reject such requests from other clients unless there is reasonable 
> assurance that the client mitigates authorization code injection in other 
> ways. See section 9.7 for details."
> 
> Section 9.7 is where the nuances of PKCE vs nonce are described.
> 
> As Neil described, we believe this will allow ASs to support both OAuth 2.0 
> and 2.1 clients simultaneously. The change from Neil's text is the 
> clarification of which threats, and changing to MUST instead of SHOULD. The 
> "MUST...unless" is more specific than "SHOULD", and since we are already 
> describing the explicit exception to the rule, it's more clear as a MUST here.
> 
> Aaron Parecki
> 
> 
> 
> 
> ___
> 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] proposed resolution for PKCE in OAuth 2.1

[Aaron Parecki]

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!

We would like to propose the following text, which is a slight variation
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1)
that begins with "If the client does not send the "code_challenge" in the
request..."

"An AS MUST reject requests without a code_challenge from public clients,
and MUST reject such requests from other clients unless there is reasonable
assurance that the client mitigates authorization code injection in other
ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0
and 2.1 clients simultaneously. The change from Neil's text is the
clarification of which threats, and changing to MUST instead of SHOULD. The
"MUST...unless" is more specific than "SHOULD", and since we are already
describing the explicit exception to the rule, it's more clear as a MUST
here.

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

Re: [OAUTH-WG] Redirect URIs in draft-ietf-oauth-security-topics

[Brian Campbell]

I suspect it was an unintentional oversight in the Security BCP and that it
should be updated to allow for it.

On Mon, May 11, 2020 at 10:03 AM Aaron Parecki  wrote:

> The Security BCP has pretty clear language around requiring exact matching
> of redirect URIs now.
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2...1
> 
>
> However the Native Apps BCP has an exception for localhost URIs to allow
> variable ports.
>
> https://tools.ietf.org/html/rfc8252#section-7.3
>
> Is the intention of the Security BCP to also prevent that use case?
>
> If so, it should probably be spelled out explicitly, since there is
> currently no mention of this. If not, then that exception should also be
> repeated in the Security BCP, since it is currently somewhat ambiguous
> whether the exception in the Native Apps BCP is still allowed.
>
> Aaron Parecki
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Redirect URIs in draft-ietf-oauth-security-topics

[Aaron Parecki]

The Security BCP has pretty clear language around requiring exact matching
of redirect URIs now.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1

However the Native Apps BCP has an exception for localhost URIs to allow
variable ports.

https://tools.ietf.org/html/rfc8252#section-7.3

Is the intention of the Security BCP to also prevent that use case?

If so, it should probably be spelled out explicitly, since there is
currently no mention of this. If not, then that exception should also be
repeated in the Security BCP, since it is currently somewhat ambiguous
whether the exception in the Native Apps BCP is still allowed.

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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Jared Jennings]

If I may, step in and offer a suggestion.

What if instead of "MUST NOT" replace with "SHOULD NOT"?

To me, (and this might be me), but MUST NOT describes a violation. As in I
broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a
guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the
token, the risk is therefore known and on the "implementer" of the
inspection.

Jared


On Mon, May 11, 2020 at 7:34 AM Denis  wrote:

> Hi Benjamin,
>
> We are making progress since we now understand better each other. You
> wrote several sentences on which I agree:
>
> "I do in fact agree that token inspection by a client can be useful in at
> least some situations".
>
> "I fully support having privacy considerations sections that discuss the
> privacy properties of the protocol in question,
>   *e**ven including aspects that are currently lacking*.
>
> "I do not believe that a JWT profile for OAuth use is the place to make
> changes to the core OAuth protocol that improve its privacy properties".
>
> I also accept your apologies.
>
> RFC 6749 is quite clear in section 1.4 that "The string [access token] *is
> usually opaqu**e* to the client".
> However, it does not mean that : "The client *MUST NOT* inspect the
> content of the access token".
> I believe the wording I proposed corresponds to the reality:
>
> There is no guarantee that token inspection can always be performed.
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Denis]

Hi Benjamin,

We are making progress since we now understand better each other. You 
wrote several sentences on which I agree:


   "I do in fact agree that token inspection by a client can be useful
   in at least some situations".

   "I fully support having privacy considerations sections that discuss
   the privacy properties of the protocol in question,
   ***e**ven including aspects that are currently lacking*.

   "I do not believe that a JWT profile for OAuth use is the place to
   make changes to the core OAuth protocol that improve its privacy
   properties".

I also accept your apologies.

RFC 6749 is quite clear in section 1.4 that "The string [access token] 
*is usually opaqu**e* to the client".
However, it does not mean that : "The client *MUST NOT* inspect the 
content of the access token".

I believe the wording I proposed corresponds to the reality:

   There is no guarantee that token inspection can always be performed.

When privacy is a concern, if a client wants to verify the claims that 
have been placed into the token but is unable to do it, it will simply 
not present it.


The document should consider more closely the recommendations included  
RFC 6973 (Privacy Considerations for Internet Protocols)

for the writing the Privacy considerations section.

Finally, you wrote:

   Making changes to OAuth that improves its privacy properties is a
   laudable goal, and
   I would happily read any I-Ds that proposed such protocol changes.

Since OAuth has not been constructed from the beginning along Privacy by 
Design rules, it is only possible to make a few improvements.

Whenever possible we should do it.

In my email sent on May the 8 th relative to another thread ( I-D 
Action: draft-ietf-oauth-security-topics-15.txt), I wrote:


   When the token contains one or more attributes that uniquely allow
   to identify the collaborative user (e.g. a "sub" claim),
   then Alice can only impersonate the collaborative user and such a
   case can easily be obtained using TeamViewer.

 * Unfortunately using the "sub" claim is not "privacy
   friendly", since collaborative RSs will be able to link the
   accounts
   of their respective users.  Nevertheless, this a good news
   for Vittorio, since the "sub" claim is REQUIRED in the
   "Profile for OAuth 2.0 Access Tokens". This means that,
   *when this profile is being used, OAuth 2.0 is resistant **to
   the ABC attack*.

 * Using a different claim that would only contain an
   identifier that is unique to the RS (such as a pseudo) would be
   more appropriate (as FIDO does), but I am not aware of a
   claim that has been defined which would have such a semantics.

If a claim that would only contain an identifier that is unique to the 
RS (such as a pseudo) has not already been defined in an I-D,

then it would be interesting to define it.

Denis


Hi Denis,

Sorry for the slow response.  I had several deadlines this week and
couldn't think much farther ahead than the next one, so my INBOX fell
behind.

On Mon, May 04, 2020 at 12:36:05PM +0200, Denis wrote:

Hello Benjamin,

First of all, you don't need to use an aggressive language to state your
opinion.

I would appreciate a little more clarity on which language comes across as
"aggressive"; I was trying very hard to stick to what I see as the facts:

- many people are frustrated with these long discussions that continue to
   rehash similar points and involve people having a hard time seeing each
   others' worldview
- you are making proposals for changes to this document that would
   represent drastic changes from previous specifications that are used by
   the current document (and are drastic changes from current practice),
   without acknowledging that they are in fact drastic changes to the core
   protocol

Please accept my apologies for however I deviated from that goal.

I am trying to get us to a place where we can have productive discussions
and improve the quality of our protocols.  Right now I don't think we're
having very productive discussions; in fact, we're holding up progress on a
document that looks likely to become widely deployed by asking it to do
more than is reasonable for it to do.


Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the
following title:"IETF Guidelines for Conduct". In particular:

 " Regardless of these individual differences, participants treat
 their colleagues with respect as persons especially
     when it is difficult to agree with them: treat other
 participants as you would like to be treated ".

I wrote:

(...)

      I will go one step further: if the client wants to inspect the
token and
      if the format of the token is unknown to the client, then the client
will simply stop its further transmission. For some clients, preserving
their
privacy may be more important than performing an access to a RS.

You responded 

[OAUTH-WG] New email address

[Rifaat Shekh-Yusef]

All,

I have a new email address *rifaat.s.i...@gmail.com
* to replace the old address rifaat.i...@gmail.com.
I did that because some spammers have been sending spam email and
pretending that they are using my old email address as the sender, and as a
result I would get angry replies from the recipients of these spam emails.

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

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?

[Torsten Lodderstedt]

> On 11. May 2020, at 10:59, Neil Madden  wrote:
> 
> 
> 
>> On 11 May 2020, at 08:53, Torsten Lodderstedt  
>> wrote:
>> 
>> 
>> 
>>> On 11. May 2020, at 09:34, Neil Madden  wrote:
>>> 
>>> 
>>> 
 On 11 May 2020, at 08:05, Torsten Lodderstedt  
 wrote:
 
 
 
>> On 11. May 2020, at 08:47, Neil Madden  wrote:
>> 
>> 
>> 
>>> On 11 May 2020, at 07:41, Torsten Lodderstedt  
>>> wrote:
>> 
>>> On 11. May 2020, at 07:38, Neil Madden  
>>> wrote:
>>> 
>>> There is no attack that this prevents so your claim of improving 
>>> security is unsubstantiated. I can’t see how we can ship a 
>>> 2.1-compliant-by-default AS while this requirement remains so I don’t 
>>> support it. 
>> 
>> Are you saying PKCE does not prevent any attack?
> 
> No, but servers and clients are already free to support PKCE. I’m saying 
> that rejecting requests from non-PKCE clients doesn’t prevent any attack. 
> It just denies service to legitimate clients. 
 
 There are two aspects to this topic:
 
 1) Do all ASs support PKCE? Requiring PKCE support fosters 
 interoperability and security. Security since the client can be sure the 
 AS supports PKCE. Today, if the AS does not support PKCE, the client will 
 never learn since a compliant AS will just ignore additional request 
 parameters.
>>> 
>>> But just saying that a 2.1 AS MUST support PKCE is enough for this. 
>>> Rejecting requests just to support feature discovery is a sledgehammer to 
>>> crack a nut. 
>>> 
 
 2) Do ASs enforce PKCE? This fosters security since it forces clients to 
 implement a means against code replay and CSRF.
 
>>> 
>>> Again, just saying that 2.1 clients MUST support PKCE achieves this aim. 
>>> Rejecting non-PKCE requests doesn’t add anything to security. 
>>> 
>>> And as has been pointed out elsewhere in this thread there are clients that 
>>> don’t benefit from PKCE such as confidential OIDC clients. Indeed for most 
>>> confidential clients the gains of PKCE are relatively minor - code 
>>> injection attacks are already pretty hard to pull off in practice against 
>>> such clients. 
>> 
>> I agree, but I wouldn’t say they don’t benefit at all. 
>> 
>> 1) The nonce check happens after the OP had issued the ID Token. This means 
>> even if the transaction is being evaluated to be fraudulent afterwards, the 
>> OP releases PII to the RP. Depending on the way the OP obtained this data, 
>> this might have already caused unneglectable cost (e.g. for an external 
>> commercial claims provider).
>> 
>> That’s not the case with PKCE.
> 
> We’re talking about confidential clients. If the ID Token is not meant for 
> this client then client authentication will fail, or else the auth code was 
> meant for this client (but not this session) in which case the user already 
> consented to release of PII to that RP.
> 
> If you are talking about a hybrid flow then PKCE doesn’t protect that either.

Sure. The OP won’t issue an ID Token if the PKCE check fails.

> I’d like to see encrypted ID tokens become mandatory in hybrid flows, but 
> that’s not for this WG.
> 
>> 
>> 2) The whole check relies on the client. I would rather rely on the OP/AS to 
>> enforce this security check since clients have a less promising track record 
>> of implementing security checks. 
>> 
>> 3) In mixed OAuth/OIDC scenarios, switching back and force between nonce and 
>> PKCE does not make developers live simpler. 
> 
> Maybe, but I don’t think either of these rise to the level of mandating that 
> ASes reject non-PKCE requests.
> 
> In the interests of building consensus, maybe something along the lines of: 
> “An AS MUST reject requests without a code_challenge from public clients, and 
> SHOULD reject such requests from other clients unless there is reasonable 
> assurance that the client mitigates these threats in other ways”?

Sounds reasonable. 

> 
> — Neil
> 

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

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?

[Neil Madden]

> On 11 May 2020, at 08:53, Torsten Lodderstedt  wrote:
> 
> 
> 
>> On 11. May 2020, at 09:34, Neil Madden  wrote:
>> 
>> 
>> 
>>> On 11 May 2020, at 08:05, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> 
>>> 
> On 11. May 2020, at 08:47, Neil Madden  wrote:
> 
> 
> 
>> On 11 May 2020, at 07:41, Torsten Lodderstedt  
>> wrote:
> 
>> On 11. May 2020, at 07:38, Neil Madden  wrote:
>> 
>> There is no attack that this prevents so your claim of improving 
>> security is unsubstantiated. I can’t see how we can ship a 
>> 2.1-compliant-by-default AS while this requirement remains so I don’t 
>> support it. 
> 
> Are you saying PKCE does not prevent any attack?
 
 No, but servers and clients are already free to support PKCE. I’m saying 
 that rejecting requests from non-PKCE clients doesn’t prevent any attack. 
 It just denies service to legitimate clients. 
>>> 
>>> There are two aspects to this topic:
>>> 
>>> 1) Do all ASs support PKCE? Requiring PKCE support fosters interoperability 
>>> and security. Security since the client can be sure the AS supports PKCE. 
>>> Today, if the AS does not support PKCE, the client will never learn since a 
>>> compliant AS will just ignore additional request parameters.
>> 
>> But just saying that a 2.1 AS MUST support PKCE is enough for this. 
>> Rejecting requests just to support feature discovery is a sledgehammer to 
>> crack a nut. 
>> 
>>> 
>>> 2) Do ASs enforce PKCE? This fosters security since it forces clients to 
>>> implement a means against code replay and CSRF.
>>> 
>> 
>> Again, just saying that 2.1 clients MUST support PKCE achieves this aim. 
>> Rejecting non-PKCE requests doesn’t add anything to security. 
>> 
>> And as has been pointed out elsewhere in this thread there are clients that 
>> don’t benefit from PKCE such as confidential OIDC clients. Indeed for most 
>> confidential clients the gains of PKCE are relatively minor - code injection 
>> attacks are already pretty hard to pull off in practice against such 
>> clients. 
> 
> I agree, but I wouldn’t say they don’t benefit at all. 
> 
> 1) The nonce check happens after the OP had issued the ID Token. This means 
> even if the transaction is being evaluated to be fraudulent afterwards, the 
> OP releases PII to the RP. Depending on the way the OP obtained this data, 
> this might have already caused unneglectable cost (e.g. for an external 
> commercial claims provider).
> 
> That’s not the case with PKCE.

We’re talking about confidential clients. If the ID Token is not meant for this 
client then client authentication will fail, or else the auth code was meant 
for this client (but not this session) in which case the user already consented 
to release of PII to that RP.

If you are talking about a hybrid flow then PKCE doesn’t protect that either. 
I’d like to see encrypted ID tokens become mandatory in hybrid flows, but 
that’s not for this WG.

> 
> 2) The whole check relies on the client. I would rather rely on the OP/AS to 
> enforce this security check since clients have a less promising track record 
> of implementing security checks. 
> 
> 3) In mixed OAuth/OIDC scenarios, switching back and force between nonce and 
> PKCE does not make developers live simpler. 

Maybe, but I don’t think either of these rise to the level of mandating that 
ASes reject non-PKCE requests.

In the interests of building consensus, maybe something along the lines of: “An 
AS MUST reject requests without a code_challenge from public clients, and 
SHOULD reject such requests from other clients unless there is reasonable 
assurance that the client mitigates these threats in other ways”?

— Neil

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

Re: [OAUTH-WG] draft-ietf-oauth-jwsreq-21

[Dominick Baier]

Would be also interested in the official language here.

Would an implementation need to introduce an optional  “strict JAR
validation mode”  - which complies with JAR, but breaks OIDC compatibility?

———
Dominick Baier

On 7. May 2020 at 15:32:33, Brock Allen (brockal...@gmail.com) wrote:

Perhaps quite late, but a few comments/questions related to this:

1) When decoded, all the JWT samples are missing the "typ" claim from the
header, which I think should be "oauth.authz.req+jwt".

2) When validating the JAR if we are to validate the "typ" then this would
be incompatible with OIDC's request object, I think?

3) When the JAR is passed by reference, then the HTTP response Content-Type
of "application/oauth.authz.req+jwt" would also seem to break or be
incompatible with OIDC's request object passed by reference?

There might need to be clarification when mixing this w/ an OIDC OP
implementation.

TIA

-Brock

___
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] [EXTERNAL] Re: OAuth 2.1 - require PKCE?

[Torsten Lodderstedt]

> On 11. May 2020, at 09:34, Neil Madden  wrote:
> 
> 
> 
>> On 11 May 2020, at 08:05, Torsten Lodderstedt  
>> wrote:
>> 
>> 
>> 
 On 11. May 2020, at 08:47, Neil Madden  wrote:
 
 
 
> On 11 May 2020, at 07:41, Torsten Lodderstedt  
> wrote:
 
> On 11. May 2020, at 07:38, Neil Madden  wrote:
> 
> There is no attack that this prevents so your claim of improving security 
> is unsubstantiated. I can’t see how we can ship a 
> 2.1-compliant-by-default AS while this requirement remains so I don’t 
> support it. 
 
 Are you saying PKCE does not prevent any attack?
>>> 
>>> No, but servers and clients are already free to support PKCE. I’m saying 
>>> that rejecting requests from non-PKCE clients doesn’t prevent any attack. 
>>> It just denies service to legitimate clients. 
>> 
>> There are two aspects to this topic:
>> 
>> 1) Do all ASs support PKCE? Requiring PKCE support fosters interoperability 
>> and security. Security since the client can be sure the AS supports PKCE. 
>> Today, if the AS does not support PKCE, the client will never learn since a 
>> compliant AS will just ignore additional request parameters.
> 
> But just saying that a 2.1 AS MUST support PKCE is enough for this. Rejecting 
> requests just to support feature discovery is a sledgehammer to crack a nut. 
> 
>> 
>> 2) Do ASs enforce PKCE? This fosters security since it forces clients to 
>> implement a means against code replay and CSRF.
>> 
> 
> Again, just saying that 2.1 clients MUST support PKCE achieves this aim. 
> Rejecting non-PKCE requests doesn’t add anything to security. 
> 
> And as has been pointed out elsewhere in this thread there are clients that 
> don’t benefit from PKCE such as confidential OIDC clients. Indeed for most 
> confidential clients the gains of PKCE are relatively minor - code injection 
> attacks are already pretty hard to pull off in practice against such clients. 

I agree, but I wouldn’t say they don’t benefit at all. 

1) The nonce check happens after the OP had issued the ID Token. This means 
even if the transaction is being evaluated to be fraudulent afterwards, the OP 
releases PII to the RP. Depending on the way the OP obtained this data, this 
might have already caused unneglectable cost (e.g. for an external commercial 
claims provider).

That’s not the case with PKCE.

2) The whole check relies on the client. I would rather rely on the OP/AS to 
enforce this security check since clients have a less promising track record of 
implementing security checks. 

3) In mixed OAuth/OIDC scenarios, switching back and force between nonce and 
PKCE does not make developers live simpler. 

> 
> Neil

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

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?

[Neil Madden]

> On 11 May 2020, at 08:05, Torsten Lodderstedt  wrote:
> 
> 
> 
>>> On 11. May 2020, at 08:47, Neil Madden  wrote:
>>> 
>>> 
>>> 
 On 11 May 2020, at 07:41, Torsten Lodderstedt  
 wrote:
>>> 
 On 11. May 2020, at 07:38, Neil Madden  wrote:
 
 There is no attack that this prevents so your claim of improving security 
 is unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default 
 AS while this requirement remains so I don’t support it. 
>>> 
>>> Are you saying PKCE does not prevent any attack?
>> 
>> No, but servers and clients are already free to support PKCE. I’m saying 
>> that rejecting requests from non-PKCE clients doesn’t prevent any attack. It 
>> just denies service to legitimate clients. 
> 
> There are two aspects to this topic:
> 
> 1) Do all ASs support PKCE? Requiring PKCE support fosters interoperability 
> and security. Security since the client can be sure the AS supports PKCE. 
> Today, if the AS does not support PKCE, the client will never learn since a 
> compliant AS will just ignore additional request parameters.

But just saying that a 2.1 AS MUST support PKCE is enough for this. Rejecting 
requests just to support feature discovery is a sledgehammer to crack a nut. 

> 
> 2) Do ASs enforce PKCE? This fosters security since it forces clients to 
> implement a means against code replay and CSRF.
> 

Again, just saying that 2.1 clients MUST support PKCE achieves this aim. 
Rejecting non-PKCE requests doesn’t add anything to security. 

And as has been pointed out elsewhere in this thread there are clients that 
don’t benefit from PKCE such as confidential OIDC clients. Indeed for most 
confidential clients the gains of PKCE are relatively minor - code injection 
attacks are already pretty hard to pull off in practice against such clients. 

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

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

[Dominick Baier]

In IdentityServer, the PKCE requirement is per client.

We started with a default of false - and now switched to true.

FWIW
———
Dominick Baier

On 10. May 2020 at 22:22:35, Mike Jones (
michael.jones=40microsoft@dmarc.ietf.org) wrote:

Exactly!



I believe that this also the same point that Brian Campbell was making
earlier about interoperability implications.



   -- Mike



*From:* Neil Madden 
*Sent:* Sunday, May 10, 2020 1:06 PM
*To:* Dick Hardt 
*Cc:* Mike Jones ; oauth@ietf.org; Torsten
Lodderstedt 
*Subject:* Re: [OAUTH-WG] Re: OAuth 2.1 - require PKCE?



But if an AS upgrades to OAuth 2.1 then it MUST reject authorization
requests that don’t include a code_challenge (section 4.1.2.1), so this
will only be possible when all clients support PKCE.



This makes it impossible for a 2.1-compliant AS to also support non-PKCE
2.0 clients (i.e., the vast majority of them).



I think we can have a 2.1 spec that says clients and servers MUST support
PKCE without this hard-fail clause. Otherwise I can’t see how we’d ever
ship with 2.1-compliance enabled out-of-the-box.



— Neil



On 10 May 2020, at 20:38, Dick Hardt  wrote:



Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
2.0 was voluntary.



Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?





On Sun, May 10, 2020 at 12:02 PM Mike Jones  wrote:

I agree with actively maintaining and improving the OAuth 2.0 specs by
adding enhancements that are voluntary to use.  I’ve worked on many such
improvements, including Dynamic Client Registration, Authorization
Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
etc.  The issue that’s the subject is the current discussion is whether to
make use of another enhancement, PKCE, mandatory in cases where it’s
actually not needed, rather than making its use voluntary like the other
enhancements, which I certainly support.



   -- Mike



*From:* Torsten Lodderstedt 
*Sent:* Sunday, May 10, 2020 3:15 AM
*To:* Mike Jones 
*Cc:* Daniel Fett ; oauth@ietf.org
*Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?



Hi Mike,



Mike Jones  schrieb am Fr. 8.
Mai 2020 um 18:55:

OAuth 2.1 was supposed to not introduce breaking changes.

I cannot remember the WG met that decision. Can you please refer to the
respective thread?



Requiring exact redirect URI matching is already a breaking change. Do you
oppose against this as well?





If you want to do that, please do it in TxAuth instead.



Interesting statement. Does it mean you want to conserve OAuth 2.0 and
force any enhancements/improvements to go into TXAuth? This would cause
huge migration efforts for existing deployments wanting to benefit from
those enhancements.



I think existing deployments are better served by actively maintaining and
evolving the 2.x line. For example, PAR and RAR are attempts to improve
OAuth 2.x and make it usable for new use cases. That’s better protection of
existing investments than sending them of to TXAuth.

Kind regards,

Torsten.





   -- Mike



*From:* OAuth  *On Behalf Of *Daniel Fett
*Sent:* Thursday, May 7, 2020 11:50 PM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?



+1 to all what Aaron said. Thanks for pointing this out!



We need to address this in the security BCP and this will be a normative
change that affects OpenID Connect Core (just as our current recommendation
on the usage of nonce).



We would then have:



- use PKCE, except if you use OIDC with a nonce, then you don't need PKCE,
except if you are a public client, then you still need PKCE.

- use state, except if you use PKCE, then you don't need state.



I think there are very good reasons to simplify this down to



- use PKCE

- you may or may not use state



First and foremost, not many people will understand why there are cases
when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
understanding *why* you have to do something is key to compliance. The
short version "PKCE protects the code; there is a specific case where it is
not needed, but its better to use it all the time" is easy to understand.
We will not see many implementations following the long version above
correctly.



Second, we dramatically reduce technical complexity by reducing cases that
need to be handled. We reduce correctness and compliance testing complexity
in the same way. We reduce the cost of security analysis, which scales
really badly to more cases.



And finally, using nonce to protect against code injection is less robust
than PKCE. AS have a better track record than clients when it comes to
correctly implementing security mechanisms.



Yes, this will make a number of implementations non-spec-compliant, but I
do 

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?

[Torsten Lodderstedt]

> On 11. May 2020, at 08:47, Neil Madden  wrote:
> 
> 
> 
>> On 11 May 2020, at 07:41, Torsten Lodderstedt  
>> wrote:
>> 
>>> On 11. May 2020, at 07:38, Neil Madden  wrote:
>>> 
>>> There is no attack that this prevents so your claim of improving security 
>>> is unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default 
>>> AS while this requirement remains so I don’t support it. 
>> 
>> Are you saying PKCE does not prevent any attack?
> 
> No, but servers and clients are already free to support PKCE. I’m saying that 
> rejecting requests from non-PKCE clients doesn’t prevent any attack. It just 
> denies service to legitimate clients. 

There are two aspects to this topic:

1) Do all ASs support PKCE? Requiring PKCE support fosters interoperability and 
security. Security since the client can be sure the AS supports PKCE. Today, if 
the AS does not support PKCE, the client will never learn since a compliant AS 
will just ignore additional request parameters.

2) Do ASs enforce PKCE? This fosters security since it forces clients to 
implement a means against code replay and CSRF.

> 
> — Neil

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