Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

[Stefanie Gerdes <[e-mail]>]

Hi John,

C must not communicate with an AS which it doesn't trust. As stated in
section 6.5, "the client MUST be able to determine whether an AS has the
authority to issue access tokens for a certain RS." The client would
therefore notice if RS or an attacker tries to trick C into
communicating with an AS that is not responsible for this RS. C then
must not communicate with this AS. I therefore do not understand how a
DDOS attack would work. Maybe section 6.4 was not changed after the
security requirements for the client in section 6.5 were defined.

I agree that a hard-coded list is not a good mechanism for realizing
authorization on the client-side. As an alternative, the client may have
an own authorization manager that helps the client with validating the
authorization of the AS. But as far as I know, an authorization
mechanism for the client side is not in scope for the ACE framework.

Viele Grüße
Steffi


On 09/07/2020 02:11 PM, John Mattsson wrote:
> Hi,
> 
> Rereading Section 6.4 again I think the discussion on Denial-of-Service / amplification attacks in Section 6.4 clearly needs more work.
> 
> - "However a compromised RS may use this to perform a denial of service against a specific AS"
> 
> Any attacker (not just a compromised RS) on the path beween C and RS can easily trick C into contacting any node S (not just an ACE AS). Such a forged message would be a denial-of-service attack on both C and N, not only on N.
> 
> - "It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers"
> 
> The list would need to be allowlist to have any effect. My understanding is that C could contact an AS it does not trust. Having an allowlist in C does not help in general. Even if C have a list stating that AS1, AS2, and AS3 is allowed, an attacker can impersonate RS3 (belonging to AS3) and fool C to contact AS1 or AS2. The attacker may even be able to get C to alternate between contacting AS1 and AS2.
> 
> Possible DDoS attacks in the IoT space is very serious. Recently, the lagest DDoS attacks have all been using IoT devices. New protocols should mitigate amlification and DDoS attacks.
> 
> Cheers,
> John
> 
> -----Original Message-----
> From: John Mattsson <[e-mail]>
> Date: Monday, 7 September 2020 at 12:45
> To: Seitz Ludwig <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: AS discovery in draft-ietf-ace-oauth-authz-35
> 
> Hi Ludwig,
> 
> The problem I have is that the current mechanism is presented as a generic discovery mechanism and that none of the disadvantages are mentioned in section 5.1.
> 
> "A generic procedure is described in Section 5.1"
> 
> The mechanism is not presented as an error message when the client in good faith tries to access a resource. It is presented as something C do intentionally to dicsover the AS. In the description in the draft, C is clearly aware that the request is unauthorized.
> 
> Section 6.4 describes the security properties quite well. But I cannot see any discusion about the inefficiency of doing discovery over the C-RS path, which in many cases is contrained.
> 
> The current presentation is:
> 
>    5.1 generic procedure to discover AS
> 
>    6.4 BTW this mechanism has some security limitation
> 
> My view would be that is should be more like:
> 
>    5.1 Error message with AS address
> 
>    X.X BTW the error message could be used for AS discovery but has limited effeciency and security and is not recommended.
> 
> Cheers,
> John
>