Hi all, thanks for the discussion here! We'll add in the security considerations the following clarification:
“As this specification provides a mechanism for the RS to trigger user interaction, it’s important for clients and AS to consider that a malicious RS might abuse of that feature” Valery, does this address your concern? On Thu, Mar 2, 2023 at 4:13 AM Uri Blumenthal <u...@mit.edu> wrote: > *This message originated outside your organization.* > > ------------------------------ > > > Surely "rogue" resource servers already have a lot of ways they can > annoy their own users? Is this a realistic threat? > > Yes, this is a realistic threat, and I'm aware of at least one example of > it actually being used (successfully!) to penetrate a corporate network. > > > On Mar 2, 2023, at 07:07, Valery Smyslov <val...@smyslov.net> wrote: > > > > 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 <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 <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> 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 > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!68yTrqJBjXNZmWtNG2vqvYRrR6JtX0836ola7TGVI-_mgm6ol0nCNpUTRPDoZ50fCxLYanBBpg$> > > > _______________________________________________ > secdir mailing list > sec...@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/secdir__;!!PwKahg!68yTrqJBjXNZmWtNG2vqvYRrR6JtX0836ola7TGVI-_mgm6ol0nCNpUTRPDoZ50fCxLKVKPZ1g$> > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview > <https://urldefense.com/v3/__https://trac.ietf.org/trac/sec/wiki/SecDirReview__;!!PwKahg!68yTrqJBjXNZmWtNG2vqvYRrR6JtX0836ola7TGVI-_mgm6ol0nCNpUTRPDoZ50fCxIPkLwdhw$> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
