[OAUTH-WG] Re: Shepherd Review for OAuth 2.0 Protected Resource Metadata draft

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

All,

Mike and I met yesterday and discussed this.
My concern was with the potential of a downgrade attack if there is a MITM
between the client and the resource server.
It seems that the draft defined a protection against such an attack as
described in section 3.3.

The next step is the shepherd write-up, which I will start soon.

Regards,
 Rifaat




On Mon, Jul 8, 2024 at 9:24 AM Michael Jones <[e-mail]>
wrote:

> Can you reply to this today, Rifaat?
>
> Thanks,
> -- Mike
>
>
> ------------------------------
> *From:* Michael Jones
> *Sent:* Saturday, July 6, 2024 12:55:19 PM
> *To:* Rifaat Shekh-Yusef <[e-mail]>
> *Cc:* oauth <[e-mail]>
> *Subject:* RE: [OAUTH-WG] Shepherd Review for OAuth 2.0 Protected
> Resource Metadata draft
>
>
> What puzzles me of talking about downgrade attacks in this context is
> between what points in time you are anticipating that a downgrade might
> occur.  The Resource Server advertises its proposed authentication methods
> in a WWW-Authenticate response.  The client then chooses one of them,
> probably within milliseconds of receiving the WWW-Authenticate response.
> When in that flow are you thinking that a downgrade might occur?
>
>
>
> Remember that the client is essentially instantaneously using fresh
> information provided by the resource server.  It is not using information
> provided at some prior time.
>
>
>
> If not the text already proposed in the PR, what specifically would you
> suggest that we say about downgrade possibilities?
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef <[e-mail]>
> *Sent:* Saturday, July 6, 2024 5:05 AM
> *To:* Michael Jones <[e-mail]>
> *Cc:* oauth <[e-mail]>
> *Subject:* Re: [OAUTH-WG] Shepherd Review for OAuth 2.0 Protected
> Resource Metadata draft
>
>
>
>
>
> A fair question is whether allowing clients to choose from among
>  supported authentication methods represents an opportunity for a
> downgrade attack.
>  Since resource servers will only enumerate authentication methods
> acceptable to them, by definition,
>  any choice made by the client from among them is one that the resource
> server is OK with.
>  Thus, the resource server allowing the use of different supported
> authentication methods
>  does not represent an opportunity for a downgrade attack.
>
>
>
> A resource server could be configured to accept a method that is
> considered secure at one time, that might be considered insecure later on.
>
> A resource server could also be misconfigured with insecure methods.
>
>
>
> For this reason, I still think that a discussion of a potential downgrade
> attack is warranted in the security consideration section.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Jul 6, 2024 at 12:30 AM Michael Jones <[e-mail]>
> wrote:
>
> The PR
> https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/45 is
> intended to address these shepherd review comments.  Please review.
>
>
>
>                                                                 Thanks,
>
>                                                                 -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef <[e-mail]>
> *Sent:* Thursday, July 4, 2024 5:30 AM
> *To:* oauth <[e-mail]>
> *Subject:* [OAUTH-WG] Shepherd Review for OAuth 2.0 Protected Resource
> Metadata draft
>
>
>
> Mike, Phil, Aaron,
>
>
>
> The following is my shepherd review for OAuth 2.0 Protected Resource
> Metadata
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html
>
> *Comments/Questions*
>
> 5.4. Compatibility with other authentication methods
>
> Would this not open the door for potential downgrade attacks if the list
> of authentication methods include weaker methods?
> I think this should be discussed in the Security Consideration section.
>
>
> *Nits*
>
> Section 1, second sentence:
> “This specification is intentionally as parallel as possible …”
> It feels like there is a missing word after “intentionally”; maybe
> “designed”, “specified”?
>
> Regards,
>
>  Rifaat
>
>
>
>