Subject: Re: [OAUTH-WG] Security BCP Review

From: Daniel Fett <[email-masked]>
Date: Mon, 11 Apr 2022 17:13:46 +0200

Hi Rifaat,

Am 14.02.22 um 22:26 schrieb Rifaat Shekh-Yusef:
>
> As part of the preparation for the shepherd write-up, I reviewed the 
> document and have the following comments:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-19.html 
> <https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-19.html>
>
>
>
> General comment
>
> The document refers to a number of drafts that are not active anymore, 
> e.g., token binding, pop key distribution, signing http requests, etc.
>
> What is the reason behind including these in this document?
>
The reason is to provide a general idea of other approaches that have 
been conceived and to discuss various approaches to specific problems. 
It may be helpful to the reader to see that sometimes, a certain 
solution has been discussed already, even when it was not pursued further.

>
> Section 4.5.4
>
> I am not clear on how the attacker can do that. Let’s take the 
> code_challenge example. Wouldn’t the AS be able to detect this attack 
> because it gets the *code verifier* associated with the *original code 
> challenge* from the Client?
>
Yes, but this can be circumvented if the attacker can modify the 
authorization request from the client to the AS before it reaches the 
AS. In this case, the attacker can define the code_challenge in the 
request such that it works with the code_verifier that will be sent 
later on.
>
>
> Nits
>
> Section 2.1, 3rd paragraph, 3rd sentence: “MAY rely the” to “, MAY 
> rely on the”
>
> Section 2.3, second paragraph: replace ietf-oauth-resource-indicators 
> with RFC8707
>
> Section 4.1.3. Last paragraph: replace the jwsreq and PAR draft 
> references with rfc9101 and rfc9126 respectively.
>
>
> Who might want to sweep through the document and update the various 
> references, as there seem to be too many old references
>
Thanks, we will fix this for the next revision and update the references.

-Daniel

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 16 Apr 2022 10:20:45 -0400

On Mon, Apr 11, 2022 at 11:13 AM Daniel Fett <[email-masked]> wrote:

> The reason is to provide a general idea of other approaches that have been
> conceived and to discuss various approaches to specific problems. It may be
> helpful to the reader to see that sometimes, a certain solution has been
> discussed already, even when it was not pursued further.
>
>
> I agree that including these might be useful to some people. But as a
developer working on following this specification, this does not add much
value and just adds more noise to the document.
I think that all these, options considered but not pursued, could be
captured in an appendix at the end of the document and you could refer to
the appendix when needed.

> authorization request from the client to the AS before it reaches the AS.
> In this case, the attacker can define the code_challenge in the request
> such that it works with the code_verifier that will be sent later on.
>
>
> But such an attack is not a limitation of this specific case. If an
attacker is able to control the Client or mount a MITM attack between
the Client and the AS, then all bets are off.
I am looking at this from a developer perspective; what would a developer
need to do in this case?

Regards,
 Rifaat

> Nits
>
> Section 2.1, 3rd paragraph, 3rd sentence: “MAY rely the” to “, MAY rely on
> the”
>
> Section 2.3, second paragraph: replace ietf-oauth-resource-indicators with
> RFC8707
>
> Section 4.1.3. Last paragraph: replace the jwsreq and PAR draft references
> with rfc9101 and rfc9126 respectively.
>