Re: [Last-Call] [secdir] [OAUTH-WG] Secdir last call review of draft-ietf-oauth-step-up-authn-challenge-12

["Valery Smyslov" <valery@xxxxxxxxxxx>]

Hi Vittorio,

 

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?

 

          Absolutely, thank you.

 

          Regards,

          Valery.

 

 

On Thu, Mar 2, 2023 at 4:13 AM Uri Blumenthal <uri@xxxxxxx> 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 <valery@xxxxxxxxxxx> 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 <valery@xxxxxxxxxxx> 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:vittorio@xxxxxxxxx] 
Sent: Thursday, March 02, 2023 11:00 AM
To: Valery Smyslov
Cc: secdir@xxxxxxxx; draft-ietf-oauth-step-up-authn-challenge.all@xxxxxxxx; last-call@xxxxxxxx; oauth@xxxxxxxx
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 <valery@xxxxxxxxxxx> 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 <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. 

_______________________________________________
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
secdir mailing list
secdir@xxxxxxxx
https://www.ietf.org/mailman/listinfo/secdir
wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call