Subject: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [2/3]

From: Hans Zandbelt <[email-masked]>
Date: Mon, 11 Nov 2019 10:57:37 +0100

Hi,

Please find my feedback on page 11-20 below.

Hans.

P14
4.2.4 For an RP there should be more explicit text and guidance about
having a single dedicated immutatable redirect URI per client that
"demultiplexes" access to the protected resource by storing the original
location that the user agent was trying to access in the state associated
with the authorization request.

P15
same section 4.2.4, 2nd paragraph: if I'm correct the text about
authorization codes being single use only and revoke access tokens on 2nd
use is not different from the original RFC is it? If so, why repeat here?

3rd paragraph: why not a MUST for invalidating state (and randomizing it
for that matter) but only a SHOULD?

P16
4.3.2 the "postmessage communication" is mentioned here without any context
or explanation; I guess this refers to the OIDC session management spec
somehow?

4.4 Mixup: I would like to emphasize here that the mixup attack works
perfectly fine against two statically configured OPs, to avoid the
impression that it is somehow applicable in dynamic scenarios only.

P17
About the description of the mixup attack: as long as the attacker is able
to trigger a request (by having the user click a link) and read the
query/POST parameters on the A-AS (perhaps from the logs) he can execute a
mixup attack by starting from the A-AS rather than the H-AS (as
demonstrated in the OAuth 2.0 security workshop in Darmstadt December
2016). Perhaps this can be made more explicit.

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 19 Nov 2019 14:34:40 +0800

Hi Hans, 

> On 11. Nov 2019, at 17:57, Hans Zandbelt <[email-masked]> wrote:
> 
> Hi,
> 
> 4.2.4 For an RP there should be more explicit text and guidance about having a single dedicated immutatable redirect URI per client that "demultiplexes" access to the protected resource by storing the original location that the user agent was trying to access in the state associated with the authorization request.
> 

Anything different from the guidance given in 3.1?

> P15
> same section 4.2.4, 2nd paragraph: if I'm correct the text about authorization codes being single use only and revoke access tokens on 2nd use is not different from the original RFC is it? If so, why repeat here?

To provide a complete list of measures and to remind the reader of what is already stated in RFC 6749.

The alternative would be to state something like, "beyond the measures given in RFC 6749, the following additional measures further reduce the chances of a successful
   attack:"

> 
> 3rd paragraph: why not a MUST for invalidating state (and randomizing it for that matter) but only a SHOULD?

Because this is a discussion of options not the normative recommendation. Beside this, invalidating state introduces more state at the client, which might cause scalability problems.  

> 
> P16
> 4.3.2 the "postmessage communication" is mentioned here without any context or explanation; I guess this refers to the OIDC session management spec somehow?

It refers to a (non-existing) postMessage-based protocol to pass the code to the RP.

We adopted the second measure with our recommendation towards code&PKCE.

> 
> 4..4 Mixup: I would like to emphasize here that the mixup attack works perfectly fine against two statically configured OPs, to avoid the impression that it is somehow applicable in dynamic scenarios only. 

Changed it 

"Mix-up is an attack on scenarios where an OAuth client interacts with
multiple authorization servers, as is usually the case when dynamic
registration is used or if the client is statically configured to interact with multiple authorization servers."

> 
> P17
> About the description of the mixup attack: as long as the attacker is able to trigger a request (by having the user click a link) and read the query/POST parameters on the A-AS (perhaps from the logs) he can execute a mixup attack by starting from the A-AS rather than the H-AS (as demonstrated in the OAuth 2.0 security workshop in Darmstadt December 2016). Perhaps this can be made more explicit.

I will ask Daniel to take a look into this.

best,
Torsten. 

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth