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 On Wed, Mar 1, 2023 at 2:05 AM Valery Smyslov via Datatracker <noreply@xxxxxxxx> 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.
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
