Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

Hi Warren, this is described in detail in the linked paper on page 31 if
you need further clarification.

Aaron


On Wed, Jun 14, 2023 at 7:36 AM Warren Parad  wrote:

> That doesn't make sense to me.
>
> On Wed, Jun 14, 2023, 21:31 Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> Hi Alexander,
>> Am 14.06.23 um 15:19 schrieb Alexander Rademann:
>>
>> *Hello, everyone! Section 4.4.1 of the BCP
>> 
>> draft lists several variants of mix-up attacks; the description of the
>> Implicit grant variant reads as follows: "In the implicit grant, the
>> attacker receives an access token instead of the code; the rest of the
>> attack works as above." Given the attack description in that section, it is
>> not clear to me why an attacker would receive the access token and which
>> part the "rest of the attack" refers to. When the Implicit grant is used,
>> H-AS sends the access token (via redirect) to the user agent, which
>> extracts it and sends it to the client. However, the client does not send
>> the access token to A-AS, does it? (I hope that I didn’t overlook anything
>> in that section.)*
>>
>> * I also checked the referenced paper ;
>> there, the authors assume that the access token is sent to the
>> authorization server under the control of the attacker (or, using their
>> terminology, identity provider) to access some resource. [Appendix B, p.
>> 31ff] Perhaps this (or some similar) assumption should be added to the
>> description of this variant?*
>>
>> The underlying assumption is that when then user selected to use A-AS in
>> the beginning, the access token would also be used with a Resource Server
>> under the attacker's control.
>>
>> -Daniel
>>
>>
>> * I'm sorry if I missed anything or if this has already been addressed
>> before, I'm new to this mailing list and did not find anything in the
>> archives. Kind regardsAlex*
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Warren Parad]

That doesn't make sense to me.

On Wed, Jun 14, 2023, 21:31 Daniel Fett 
wrote:

> Hi Alexander,
> Am 14.06.23 um 15:19 schrieb Alexander Rademann:
>
> *Hello, everyone! Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above." Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
> * I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?*
>
> The underlying assumption is that when then user selected to use A-AS in
> the beginning, the access token would also be used with a Resource Server
> under the attacker's control.
>
> -Daniel
>
>
> * I'm sorry if I missed anything or if this has already been addressed
> before, I'm new to this mailing list and did not find anything in the
> archives. Kind regardsAlex*
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Daniel Fett]

Hi Alexander,

Am 14.06.23 um 15:19 schrieb Alexander Rademann:

**

Hello, everyone!

Section 4.4.1 of the BCP 
 
draft lists several variants of mix-up attacks; the description of the 
Implicit grant variant reads as follows: "In the implicit grant, the 
attacker receives an access token instead of the code; the rest of the 
attack works as above."


Given the attack description in that section, it is not clear to me 
why an attacker would receive the access token and which part the 
"rest of the attack" refers to. When the Implicit grant is used, H-AS 
sends the access token (via redirect) to the user agent, which 
extracts it and sends it to the client. However, the client does not 
send the access token to A-AS, does it? (I hope that I didn’t overlook 
anything in that section.)




I also checked the referenced paper 
; there, the authors assume that the 
access token is sent to the authorization server under the control of 
the attacker (or, using their terminology, identity provider) to 
access some resource. [Appendix B, p. 31ff] Perhaps this (or some 
similar) assumption should be added to the description of this variant?


**


The underlying assumption is that when then user selected to use A-AS in 
the beginning, the access token would also be used with a Resource 
Server under the attacker's control.


-Daniel



**

I'm sorry if I missed anything or if this has already been addressed 
before, I'm new to this mailing list and did not find anything in the 
archives.


Kind regards

Alex



___
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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

I've created a pull request to update this section here:
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/82/files

Aaron

On Wed, Jun 14, 2023 at 6:47 AM Aaron Parecki  wrote:

> Hi Alex,
>
> I see what you mean, in Section 4.4.1 with the implicit flow, the sequence
> ends with the redirect back to the client from H-AS with the access token.
> Steps 5 and 6 don't happen with the implicit flow, so "works as above"
> isn't descriptive enough.
>
> The paper describes a slightly different way the attacker gets the access
> token, which is after the client attempts to use the access token from H-AS
> to retrieve resources from A-RS or retrieve user info from A-AS. I believe
> the description of the implicit variant in the Security BCP should be
> updated to make this more clear.
>
> Thanks!
>
> Aaron
>
>
>
> On Wed, Jun 14, 2023 at 6:23 AM Alexander Rademann <
> alexander.radem...@web.de> wrote:
>
>>
>>
>> *Hello, everyone!Section 4.4.1 of the BCP
>> 
>> draft lists several variants of mix-up attacks; the description of the
>> Implicit grant variant reads as follows: "In the implicit grant, the
>> attacker receives an access token instead of the code; the rest of the
>> attack works as above."Given the attack description in that section, it is
>> not clear to me why an attacker would receive the access token and which
>> part the "rest of the attack" refers to. When the Implicit grant is used,
>> H-AS sends the access token (via redirect) to the user agent, which
>> extracts it and sends it to the client. However, the client does not send
>> the access token to A-AS, does it? (I hope that I didn’t overlook anything
>> in that section.)*
>>
>>
>>
>> *I also checked the referenced paper ;
>> there, the authors assume that the access token is sent to the
>> authorization server under the control of the attacker (or, using their
>> terminology, identity provider) to access some resource. [Appendix B, p.
>> 31ff] Perhaps this (or some similar) assumption should be added to the
>> description of this variant?I'm sorry if I missed anything or if this has
>> already been addressed before, I'm new to this mailing list and did not
>> find anything in the archives.Kind regardsAlex*
>> ___
>> 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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

Hi Alex,

I see what you mean, in Section 4.4.1 with the implicit flow, the sequence
ends with the redirect back to the client from H-AS with the access token.
Steps 5 and 6 don't happen with the implicit flow, so "works as above"
isn't descriptive enough.

The paper describes a slightly different way the attacker gets the access
token, which is after the client attempts to use the access token from H-AS
to retrieve resources from A-RS or retrieve user info from A-AS. I believe
the description of the implicit variant in the Security BCP should be
updated to make this more clear.

Thanks!

Aaron



On Wed, Jun 14, 2023 at 6:23 AM Alexander Rademann <
alexander.radem...@web.de> wrote:

>
>
> *Hello, everyone!Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above."Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
>
>
> *I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?I'm sorry if I missed anything or if this has
> already been addressed before, I'm new to this mailing list and did not
> find anything in the archives.Kind regardsAlex*
> ___
> 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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Warren Parad]

Presumably, the attacker can get the token by having the Honest-AS redirect
the user to a site controlled by the Attacker. That site then would
redirect the user back to the original site with the Honest-AS token. This
is no different than an ordinary phishing based attack.

On Wed, Jun 14, 2023, 20:24 Alexander Rademann 
wrote:

>
>
> *Hello, everyone!Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above."Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
>
>
> *I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?I'm sorry if I missed anything or if this has
> already been addressed before, I'm new to this mailing list and did not
> find anything in the archives.Kind regardsAlex*
> ___
> 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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Alexander Rademann]

*Hello, everyone!Section 4.4.1 of the BCP

draft lists several variants of mix-up attacks; the description of the
Implicit grant variant reads as follows: "In the implicit grant, the
attacker receives an access token instead of the code; the rest of the
attack works as above."Given the attack description in that section, it is
not clear to me why an attacker would receive the access token and which
part the "rest of the attack" refers to. When the Implicit grant is used,
H-AS sends the access token (via redirect) to the user agent, which
extracts it and sends it to the client. However, the client does not send
the access token to A-AS, does it? (I hope that I didn’t overlook anything
in that section.)*



*I also checked the referenced paper ;
there, the authors assume that the access token is sent to the
authorization server under the control of the attacker (or, using their
terminology, identity provider) to access some resource. [Appendix B, p.
31ff] Perhaps this (or some similar) assumption should be added to the
description of this variant?I'm sorry if I missed anything or if this has
already been addressed before, I'm new to this mailing list and did not
find anything in the archives.Kind regardsAlex*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth