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 <john.matts...@ericsson.com> > Date: Monday, 7 September 2020 at 12:45 > To: Seitz Ludwig <ludwig.se...@combitech.se>, "ace@ietf.org" <ace@ietf.org> > 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 > _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
