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