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 <michael_b_jo...@hotmail.com> 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 <rifaat.s.i...@gmail.com> > *Cc:* oauth <oauth@ietf.org> > *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 <rifaat.s.i...@gmail.com> > *Sent:* Saturday, July 6, 2024 5:05 AM > *To:* Michael Jones <michael_b_jo...@hotmail.com> > *Cc:* oauth <oauth@ietf.org> > *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 <michael_b_jo...@hotmail.com> > 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 <rifaat.s.i...@gmail.com> > *Sent:* Thursday, July 4, 2024 5:30 AM > *To:* oauth <oauth@ietf.org> > *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 > > > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
