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
