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

[Philippe De Ryck]

From working with a lot of developers on understanding OAuth 2.0 and OIDC, I 
definitely vote for simplicity. Understanding the subtle nuances of when a 
nonce is fine and when PKCE should be used is impossible without in-depth 
knowledge of the flows and their properties. Misunderstandings will cause 
security vulnerabilities, which can easily be avoided.

Since OAuth 2.1 is a separate spec, I don’t really see a problem with existing 
code not being compliant. They support OAuth 2.0, and if they want to be OAuth 
2.1 compliant, they add PKCE. If I’m not mistaken, other requirements of OAuth 
2.1 would also clash with existing deployments (e.g., using non-exact redirect 
URIs).

I believe that optimizing for making OAuth 2.1 easier to understand will yield 
the highest return.

Philippe


> On 8 May 2020, at 03:42, Mike Jones 
>  wrote:
> 
> Aaron, I believe you’re trying to optimize the wrong thing.  You’re concerned 
> about “the amount of explanation this will take”.  That’s optimizing for spec 
> simplicity – a goal that I do understand.  However, by writing these few 
> sentences or paragraphs, we’ll make it clear to developers that hundreds or 
> thousands of deployed OpenID Connect RPs won’t have to change their 
> deployments.  That’s optimizing for interoperability and minimizing the 
> burden on developers, which are far more important.
>  
> As Brian Campbell wrote, “They are not equivalent and have very different 
> ramifications on interoperability”.
>  
> Even if you’re optimizing for writing, taking a minimally invasive protocol 
> change approach will optimize that, overall.  If we proceed as you’re 
> suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
> SlashDot, blogs, and other developer forums, where confused developers will 
> ask “Why do I have to change my deployed code?” with the answers being 
> “Despite what the 2.1 spec says, there’s no need to change your deployed 
> code.”
>  
> I’d gladly write a few sentences in our new specs now to prevent ongoing 
> confusion and interop problems that would otherwise result.  Let me know when 
> you’re ready to incorporate them into the spec text.
>  
>-- Mike
>  
> From: Aaron Parecki mailto:aa...@parecki.com>> 
> Sent: Thursday, May 7, 2020 4:39 PM
> To: Dick Hardt mailto:dick.ha...@gmail.com>>
> Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net>>; Mike Jones 
> mailto:michael.jo...@microsoft.com>>
> Subject: Re: OAuth 2.1 - require PKCE?
>  
> Backing up a step or two, there's another point here that I think has been 
> missed in these discussions.
>  
> PKCE solves two problems: stolen authorization codes for public clients, and 
> authorization code injection for all clients. We've only been talking about 
> authorization code injection on the list so far. The quoted section of the 
> security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
> talking about preventing authorization code injection.
>  
> The nonce parameter solves authorization code injection if the client 
> requests an ID token. Public clients using the nonce parameter are still 
> susceptible to stolen authorization codes so they still need to do PKCE as 
> well.
>  
> The only case where OpenID Connect clients don't benefit from PKCE is if they 
> are also confidential clients. Public client OIDC clients still need to do 
> PKCE even if they check the nonce.
>  
> OpenID Connect servers working with confidential clients still benefit from 
> PKCE because they can then enforce the authorization code injection 
> protection server-side rather than cross their fingers that clients 
> implemented the nonce check properly.
>  
> I really don't think it's worth the amount of explanation this will take in 
> the future to write an exception into OAuth 2.1 or the Security BCP for only 
> some types of OpenID Connect clients when all clients would benefit from PKCE 
> anyway.
>  
> Aaron
>  
>  
>  
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  > wrote:
> Hello!
>  
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best 
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the 
> nonce solves some of the issues that PKCE protects against. We think that 
> most OpenID Connect implementations also support OAuth 2.0, and hence have 
> support for PKCE if following best practices.
>  
> The advantages or requiring PKCE are:
>  
> - a simpler programming model across all OAuth applications and profiles as 
> they all use PKCE
>  
> - reduced attack surface when using  S256 as a fingerprint of the verifier is 
> sent through the browser instead of the clear text value
>  
> - enforcement by AS not client - makes it easier to handle for client 
> developers and AS can ensure the check is conducted
>  
> What are disadvantages besides the potential impact to OpenID Connect 

Re: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT

[Prabath Siriwardena]

Thanks Vittorio for your thoughts!


On Thu, May 7, 2020 at 1:29 PM Vittorio Bertocci  wrote:

> Hi Prabath,
>
> Thanks for your comment! Here are my thoughts.
>
> I don’t believe embedding the state in the AT would help. The state is
> generated (hence verified, if used for protection) by the client, but the
> content of the AT is really meant for the RS, which has no direct knowledge
> of what the state value should be, not in the first nor all the subsequent
> uses of the AT within its validity period. Also, the client itself is
> forbidden to inspect the content of the access token- you can find the
> details behind that in recent discussions on the list.
>
> I’ll add to this that the implicit grant is on its way out of the grants
> stage, hence doing major changes to accommodate its quirks wouldn’t give a
> lot of ROI.
>
> HTH
>
> Thanks!
>
> V.
>
>
>
> *From: *OAuth  on behalf of Prabath Siriwardena
> 
> *Date: *Thursday, May 7, 2020 at 11:56
> *To: *Rifaat Shekh-Yusef , oauth 
> *Subject: *[OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding
> state into the JWT
>
>
>
> Hi all,
>
>
>
> Can we say in [1], that the AS should add the value of *state* parameter
> from the authorization request (if present), to the JWT access token it
> generates?
>
>
>
> This will help to address token injection issue [2], with respect to the
> implicit grant type.
>
>
>
> Appreciate your thoughts on this.
>
>
>
> [1]: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>
> [2]:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4..6
>
>
>
> Thanks
>
> -Prabath
>
>
>
> On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef 
> wrote:
>
> Hi all,
>
>
>
> This is a 3rd working group last call for "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>
>
>
> Please send your comments to the OAuth mailing list by May 12, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
> ___
> 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] OAuth 2.1 - require PKCE?

[Mike Jones]

Aaron, I believe you’re trying to optimize the wrong thing.  You’re concerned 
about “the amount of explanation this will take”.  That’s optimizing for spec 
simplicity – a goal that I do understand.  However, by writing these few 
sentences or paragraphs, we’ll make it clear to developers that hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki 
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt 
Cc: OAuth WG ; Torsten Lodderstedt ; 
Mike Jones 
Subject: Re: OAuth 2.1 - require PKCE?

Backing up a step or two, there's another point here that I think has been 
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients, and 
authorization code injection for all clients. We've only been talking about 
authorization code injection on the list so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection 
server-side rather than cross their fingers that clients implemented the nonce 
check properly.

I really don't think it's worth the amount of explanation this will take in the 
future to write an exception into OAuth 2.1 or the Security BCP for only some 
types of OpenID Connect clients when all clients would benefit from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
Hello!

We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best 
practice for OAuth 2.0. It is not common in OpenID Connect servers as the nonce 
solves some of the issues that PKCE protects against. We think that most OpenID 
Connect implementations also support OAuth 2.0, and hence have support for PKCE 
if following best practices.

The advantages or requiring PKCE are:

- a simpler programming model across all OAuth applications and profiles as 
they all use PKCE

- reduced attack surface when using  S256 as a fingerprint of the verifier is 
sent through the browser instead of the clear text value

- enforcement by AS not client - makes it easier to handle for client 
developers and AS can ensure the check is conducted

What are disadvantages besides the potential impact to OpenID Connect 
deployments? How significant is that impact?

Dick, Aaron, and Torsten

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

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

[Aaron Parecki]

Backing up a step or two, there's another point here that I think has been
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients,
and authorization code injection for all clients. We've only been talking
about authorization code injection on the list so far. The quoted section
of the security BCP (4.5.3) which says clients can do PKCE or use the
nonce, is only talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client
requests an ID token. Public clients using the nonce parameter are still
susceptible to stolen authorization codes so they still need to do PKCE as
well.

The only case where OpenID Connect clients don't benefit from PKCE is if
they are also confidential clients. Public client OIDC clients still need
to do PKCE even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from
PKCE because they can then enforce the authorization code injection
protection server-side rather than cross their fingers that clients
implemented the nonce check properly.

I really don't think it's worth the amount of explanation this will take in
the future to write an exception into OAuth 2.1 or the Security BCP for
only some types of OpenID Connect clients when all clients would benefit
from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:

> Hello!
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence have
> support for PKCE if following best practices.
>
> The advantages or requiring PKCE are:
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
> - reduced attack surface when using  S256 as a fingerprint of the verifier
> is sent through the browser instead of the clear text value
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
> Dick, Aaron, and Torsten
>
> ᐧ
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT

[Vittorio Bertocci]

Hi Prabath,
Thanks for your comment! Here are my thoughts.
I don’t believe embedding the state in the AT would help. The state is 
generated (hence verified, if used for protection) by the client, but the 
content of the AT is really meant for the RS, which has no direct knowledge of 
what the state value should be, not in the first nor all the subsequent uses of 
the AT within its validity period. Also, the client itself is forbidden to 
inspect the content of the access token- you can find the details behind that 
in recent discussions on the list.
I’ll add to this that the implicit grant is on its way out of the grants stage, 
hence doing major changes to accommodate its quirks wouldn’t give a lot of ROI.
HTH
Thanks!
V.

From: OAuth  on behalf of Prabath Siriwardena 

Date: Thursday, May 7, 2020 at 11:56
To: Rifaat Shekh-Yusef , oauth 
Subject: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into 
the JWT

Hi all,

Can we say in [1], that the AS should add the value of state parameter from the 
authorization request (if present), to the JWT access token it generates?

This will help to address token injection issue [2], with respect to the 
implicit grant type.

Appreciate your thoughts on this.

[1]: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
[2]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.6

Thanks
-Prabath

On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Hi all,

This is a 3rd working group last call for "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07

Please send your comments to the OAuth mailing list by May 12, 2020.

Regards,
 Rifaat & Hannes
___
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] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT

[Prabath Siriwardena]

Hi all,

Can we say in [1], that the AS should add the value of *state* parameter
from the authorization request (if present), to the JWT access token it
generates?

This will help to address token injection issue [2], with respect to the
implicit grant type.

Appreciate your thoughts on this.

[1]: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
[2]:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.6

Thanks
-Prabath

On Tue, May 5, 2020 at 11:19 AM Rifaat Shekh-Yusef 
wrote:

> Hi all,
>
>
>
> This is a 3rd working group last call for "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>
>
>
> Please send your comments to the OAuth mailing list by May 12, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
> ___
> 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-security-topics-15.txt

[Daniel Fett]

Hi Denis,

Am 07.05.20 um 14:46 schrieb Denis:
> (...)
>
> A new definition for the term client should be adopted for this
> document.  However, you are right, the two wordings shall remain.
>
I cannot follow any of this, sorry.

>>>
>>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been
>>> "updated to account for the potentially _dynamic relationships
>>> involving multiple parties_".
>>> However, it still misses to address the case of _dynamic
>>> relationships between clients_, which include scenarios of
>>> _collaborative clients_.
>>>
>> That is not correct. Web attackers (A1) can participate in the
>> protocol as one or more users (resource owners) or clients. Of
>> course, these can collaborate between each other.
>>
> Section 3 states:
>
>    *OAuth MUST ensure that* the authorization of the resource owner
> (RO)  (with a user agent) at the authorization server (AS) and
>    the subsequent usage of the access token at the resource server
> (RS) *is protected _at least_ against the following attackers*:
>
>   *  (A1) *Web Attackers *(...)
>
> If a collaboration / collusion between clients were covered under this
> case, then it would mean that *OAUTH MUST provide a protection for it*,
> whereas this is technically impossible.
>
You are confusing the attacker model with the security goals (aka
security properties).

A commonly accepted security property for OAuth would be:

"An attacker should not be able to obtain access to or use a protected
resource protected by an uncompromised AS if that resource is only used
by an honest user with an uncompromised client and user agent."

(roughly equivalent to the one in
https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)

Being resistant to collusion attacks is not a commonly accepted/expected
security property.

So: Yes, attackers are free to collude, and that is part of the model.
No, that is not a problem, as they are not breaking anything anyone
would expect.

-Daniel


> Since AOuth is unable to protect against a collusion attack between
> clients, the collusion attack cannot belong to this section, in
> particular under (A1).
>
> Section 3 is confusing the threat model with the resistance of OAuth
> to these threats.
>
> At this time, an RFC reader may not catch the fact that a collusion
> attack between clients may ever exist and thus may not
> grasp the fact that this kind of attack cannot be countered by OAuth,
> even when following the Best Practices.
>
> The "Updated OAuth 2.0 Attacker Model" does not take into "account for
> the potentially _dynamic relationships involving multiple parties_".
> as it is advertised, in particular the case of _dynamic relationships
> between clients_ which include the case of _collaborative clients_.
>
> The text currently does not  incorporate words like "collusion",
> "colluding", whereas it should. The text should clearly indicate that
> a protection against a collusion between clients is currently not
> possible using OAuth.
>
>>> Such a collaboration between clients is possible and should be
>>> considered in the "updated model".
>>>
>> This is considered in the model.
>
> See my comments above. While promised by the text, the case of
> collaborative clients is not considered in the model.
>
>>> which are human beings, it cannot be assumed that all the human
>>> beings in the world will necessary be honest. Whether or not Auth
>>> 2.0 is able or not
>>> to counter such an attack is another issue.
>>>
>> This as well. 
>
> As said above, the model should only express the threats (or the
> possible attacks) and another section should indicate which threats
> cannot countered. 
>
>>> In another section, it should be mentioned that OAuth 2.0 is unable
>>> to counter such an attack.
>>>
>> The problem is not that this type of collusion attack is not possible
>> under the model. The problem is it is not commonly expected that
>> OAuth protects against this type of attack.
>>
> RFC readers who have not followed or participated to this thread will
> not necessarily know that OAuth does not protect against this type of
> attack.
>
> The purpose of this document is to inform the reader about _all_ known
> types of attacks, whether they can be defeated or not by OAuth 2.0.
>
> Denis
>
>> -Daniel
>>
>>> Stating that such an attack is "out of the scope" of OAuth 2.0 would
>>> not be an appropriate statement.
>>>
>>> It should not be forgotten, that the purpose of this document is to
>>> inform the reader about _all_ the relevant security issues.
>>>
>>> Denis
>>>
 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   : OAuth 2.0 Security Best Current Practice
 Authors : Torsten Lodderstedt
   John Bradley
 

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

[Brock Allen]

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

[Denis]

Hi Daniel,


Hi Denis,

Am 05.05.20 um 17:19 schrieb Denis:

Comments on draft-ietf-oauth-security-topics-15

1) Historically, the acronym RO (Resource Owner) has been used but is 
still used in this document.
    Since a client is not necessarily any more a RO, it would be more 
adequate to use the word "Client"

    instead of "RO"  in this document.

The terms Resource Owner and Client are clearly defined in RFC6749 and 
refer to two different entities.


RFC 6749 contains the two following definitions:

resource owner
  An entity capable of granting access to a protected resource.
  When the resource owner is a person, it is referred to as an
  end-user.

client
  An application making protected resource requests *on behalf of the**
**  resource owner and* with its authorization.  The term "client" does
  not imply any particular implementation characteristics (e.g.,
  whether the application executes on a server, a desktop, or other
  devices).

The original definition of a client does not appear to be adequate any more.
It is questionable whether the definition of a client from RFC 6749 
should be reused word-to-word.


The original definition of a client mentions the resource owner and 
misses to mention the authorisation server.
I wonder whether the use of the wording "on behalf of the resource 
owner" is really adequate. A client is not

impersonating the resource owner.

A client is an application *using an authorisation server *for 
performing protected resource requests

that will be granted or not by a resource owner.

A new definition for the term client should be adopted for this 
document.  However, you are right, the two wordings shall remain.



2) The structure of the document is the following:

1.Introduction
2.Recommendations
3.The Updated OAuth 2.0 Attacker Model

It is rather odd to have recommendations placed before the Attacker 
Model. Before providing solutions to some problems,
it is important to understand what the problems are. The Updated 
OAuth 2.0 Attacker model should be placed after the introduction.


The "most important recommendations of the OAuth working group for 
every OAuth implementor" should be placed after the "Attacks and 
Mitigations" section.


This structure was chosen specifically to have the recommendations - 
arguably the most important section for everyday users of OAuth - in 
the front.


This means that most readers will only read the recommendations section 
placed upfront and are likely to ignore the other sections,
in particular the Updated OAuth 2.0 Attacker Model. They will thus kept 
ignorant of attacks that cannot be countered using the "Best Practices".
They may then believe that their implementations are secure whereas it 
will not be the case.




3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
"updated to account for the potentially _dynamic relationships 
involving multiple parties_".
However, it still misses to address the case of _dynamic 
relationships between clients_, which include scenarios of 
_collaborative clients_.


That is not correct. Web attackers (A1) can participate in the 
protocol as one or more users (resource owners) or clients. Of course, 
these can collaborate between each other.



Section 3 states:

*OAuth MUST ensure that* the authorization of the resource owner (RO)  
(with a user agent) at the authorization server (AS) and
   the subsequent usage of the access token at the resource server (RS) 
*is protected _at least_ against the following attackers*:


  *  (A1) *Web Attackers *(...)

If a collaboration / collusion between clients were covered under this 
case, then it would mean that *OAUTH MUST provide a protection for it*,

whereas this is technically impossible.

Since AOuth is unable to protect against a collusion attack between 
clients, the collusion attack cannot belong to this section, in 
particular under (A1).


Section 3 is confusing the threat model with the resistance of OAuth to 
these threats.


At this time, an RFC reader may not catch the fact that a collusion 
attack between clients may ever exist and thus may not
grasp the fact that this kind of attack cannot be countered by OAuth, 
even when following the Best Practices.


The "Updated OAuth 2.0 Attacker Model" does not take into "account for 
the potentially _dynamic relationships involving multiple parties_".
as it is advertised, in particular the case of _dynamic relationships 
between clients_ which include the case of _collaborative clients_.


The text currently does not  incorporate words like "collusion", 
"colluding", whereas it should. The text should clearly indicate that
a protection against a collusion between clients is currently not 
possible using OAuth.


Such a collaboration between clients is possible and should be 
considered in the "updated model".



This is considered in the model.


See my comments above. While promised by the text, the case of 
collaborative 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

[Daniel Fett]

Hi Denis,

Am 05.05.20 um 17:19 schrieb Denis:
> Comments on draft-ietf-oauth-security-topics-15
>
> 1) Historically, the acronym RO (Resource Owner) has been used but is
> still used in this document.
>     Since a client is not necessarily any more a RO, it would be more
> adequate to use the word "Client"
>     instead of "RO"  in this document.
>
The terms Resource Owner and Client are clearly defined in RFC6749 and
refer to two different entities.
>
>
> 2) The structure of the document is the following:
>
>    1.  Introduction
>    2.  Recommendations
>    3.  The Updated OAuth 2.0 Attacker Model
>
> It is rather odd to have recommendations placed before the Attacker
> Model. Before providing solutions to some problems,
> it is important to understand what the problems are. The Updated OAuth
> 2.0 Attacker model should be placed after the introduction.
>
> The "most important recommendations of the OAuth working group for
> every OAuth implementor" should be placed after the "Attacks and
> Mitigations" section.
>
This structure was chosen specifically to have the recommendations -
arguably the most important section for everyday users of OAuth - in the
front.
>
>
> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been
> "updated to account for the potentially _dynamic relationships
> involving multiple parties_".
> However, it still misses to address the case of _dynamic relationships
> between clients_, which include scenarios of _collaborative clients_.
>
That is not correct. Web attackers (A1) can participate in the protocol
as one or more users (resource owners) or clients. Of course, these can
collaborate between each other.

> Such a collaboration between clients is possible and should be
> considered in the "updated model".
>
This is considered in the model.
>
> which are human beings, it cannot be assumed that all the human beings
> in the world will necessary be honest. Whether or not Auth 2.0 is able
> or not
> to counter such an attack is another issue.
>
This as well.
>
> In another section, it should be mentioned that OAuth 2.0 is unable to
> counter such an attack.
>
The problem is not that this type of collusion attack is not possible
under the model. The problem is it is not commonly expected that OAuth
protects against this type of attack.

-Daniel

> Stating that such an attack is "out of the scope" of OAuth 2.0 would
> not be an appropriate statement.
>
> It should not be forgotten, that the purpose of this document is to
> inform the reader about _all_ the relevant security issues.
>
> Denis
>
>> 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   : OAuth 2.0 Security Best Current Practice
>> Authors : Torsten Lodderstedt
>>   John Bradley
>>   Andrey Labunets
>>   Daniel Fett
>>  Filename: draft-ietf-oauth-security-topics-15.txt
>>  Pages   : 46
>>  Date: 2020-04-05
>>
>> Abstract:
>>This document describes best current security practice for OAuth 2.0.
>>It updates and extends the OAuth 2.0 Security Threat Model to
>>incorporate practical experiences gathered since OAuth 2.0 was
>>published and covers new threats relevant due to the broader
>>application of OAuth 2.0.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>>
>>
>> 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


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