Surely "rogue" resource servers already have a lot of ways they can annoy their own users? Is this a realistic threat?
-- Neil > On 2 Mar 2023, at 08:23, Valery Smyslov <val...@smyslov.net> wrote: > > Thank you for pointing to the deployment consideration section, I re-read it > :-) > This section is mostly concerned with accidental bad used experience > caused by incompatible policies. My point is slightly different. > > My point is that since this extension adds the possibility of an additional > interactive step > needed for the client to get access to the resource, this gives rogue > resource servers > a possibility to request this step even if in fact it is not needed, just to > annoy user > (so, it is not due to incompatible policies, it is due to resource servers > intentional bad behavior). > I think it’s worth to mention in the Security Considerations section, > although I agree that the problem is minor. > > Regards, > Valery. > > > > From: Vittorio Bertocci [mailto:vitto...@auth0.com] > Sent: Thursday, March 02, 2023 11:00 AM > To: Valery Smyslov > Cc: sec...@ietf.org; draft-ietf-oauth-step-up-authn-challenge....@ietf.org; > last-c...@ietf.org; oauth@ietf.org > Subject: Re: Secdir last call review of > draft-ietf-oauth-step-up-authn-challenge-12 > > Thanks for clarifying, I was indeed addressing the comment using DoS in its > canonical meaning. > The possibility of bad user experience is indeed present, and it is more > general than just freshness: we do tackle that explicitly in the deployment > considerations section. Did you have a chance to read it? Is there anything > you would add to what we say there? > thanks > V. > > On Wed, Mar 1, 2023 at 10:34 PM Valery Smyslov <val...@smyslov.net > <mailto:val...@smyslov.net>> wrote: >> This message originated outside your organization. >> >> >> >> Hi Vittorio, >> >> when I used the term “DoS”, I was not thinking only about real DoS attacks >> (on computers), >> but also about “DoS” attacks on humans. Consider the situation when the >> resource >> server doesn’t accept *any* presented token asking for a fresher one. So, >> each time the client >> attempts to get access to the resource, it have to contact the authorization >> server which may >> require user interaction, which may be very annoying for the user if it >> happens constantly. >> Am I missing something? >> >> Regards, >> Valery. >> >> >> Thank you Valery for the review! >> The possibility of DOS is interesting. Here's the reasoning we followed when >> we opted not to mention it in the security considerations: >> - The client going back to the AS isn't a new thing introduced by the step >> up spec, given that it's the expected behavior for insufficient_scope. >> - if anything, step up might make it even harder to mount a DOS: the >> challenge presented by the client to the AS either results in user >> interaction, negating the possibility of using it as a component of a DOS >> attack, or results in an error, leaving the client unable to call the API >> and get any new challenges >> What do you think? >> Thanks >> V. >> >> On Wed, Mar 1, 2023 at 2:05 AM Valery Smyslov via Datatracker >> <nore...@ietf.org <mailto:nore...@ietf.org>> wrote: >>> >>> This message originated outside your organization. >>> >>> >>> Reviewer: Valery Smyslov >>> Review result: Has Issues >>> >>> I have reviewed this document as part of the security directorate's ongoing >>> effort to review all IETF documents being processed by the IESG. These >>> comments were written primarily for the benefit of the security area >>> directors. >>> Document editors and WG chairs should treat these comments just like any >>> other >>> last call comments. >>> >>> The document introduces an extension to the OAuth protocol that allows >>> resource >>> servers to signal to a client that the authentication event associated with >>> the >>> access token of the current request does not meet its authentication >>> requirements >>> and specify how to meet them. >>> >>> The document is well written and easy to understand. >>> >>> The Security Considerations section looks comprehensive. However, I think >>> that >>> one potential issue is not discussed - the possibility of DoS attacks. >>> The protocol allows the resource server to send the client back to the >>> authorization >>> server for a "better" authentication token. In my opinion it opens a >>> possibility >>> for rogue resource servers to mount a DoS attack by constantly requesting >>> a "better" token. In my understanding a client should respect these replies >>> and each time should ask the authorization server for a "better" (e.g. >>> fresher) token. >>> Depending on the authentication mechanism involved this may be annoying for >>> the user >>> and put an additional load on both the client and the authorization server. >>> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
