Re: [OAUTH-WG] Security BCP Review

[Rifaat Shekh-Yusef <[e-mail]>]

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

> 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
>
>
> 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.
>
>
> 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.


> 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.
>
>
> 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.
>
> 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
>
>