Hi Neil,
Surely "rogue" resource servers already have a lot of ways they can annoy their
own users?
I agree.
Is this a realistic threat?
I don’t know. Probably not. But I see that this protocol adds one more
possibility for “rogue” resource servers to misbehave.
I think it’s worth to document this possibility (even if it is a
minor threat).
Regards,
Valery.
-- Neil
On 2 Mar 2023, at 08:23, Valery Smyslov < <mailto:[email protected]>
[email protected]> 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:[email protected]]
Sent: Thursday, March 02, 2023 11:00 AM
To: Valery Smyslov
Cc: [email protected]; [email protected];
[email protected]; [email protected]
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 < <mailto:[email protected]>
[email protected]> 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 <
<mailto:[email protected]> [email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
