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 -----Original Message----- From: Seitz Ludwig <ludwig.se...@combitech.se> Date: Monday, 7 September 2020 at 08:28 To: John Mattsson <john.matts...@ericsson.com>, "ace@ietf.org" <ace@ietf.org> Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35 Hi John, Replies inline /Ludwig > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of John Mattsson > Sent: den 5 september 2020 14:53 > To: ace@ietf.org > Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35 > > Hi, > > I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about > the AS discovery mechanism in the ACE framework. Why is this particular > discovery mechanism given so much attention? Of all possible discovery > mechanisms, this seems like one of the worst as: > > 1. It requires a round-trip over the C-RS path which is typically the most > constrained path in the architecture. > 2. The response would in many cases be unprotected, which means C > does not know if the response comes from RS or an attacker. > > A discovery mechanism using a non-contrained path (e.g. DNS, but could be > any type of look up service) would in many cases be much more efficient and > should be recommended. Such a mechanism might also be protected in > more cases and therefore rule out the possibility that the response came > from an attacker. > > I understand that the ACE framework draft does not want to specify any > other AS discovery mechanism, but at a minimum the severe limitations of > the current mechanism should be detailed. The limitations of this mechanism are detailed in section 6.4, do you think that there is some consideration missing from that section? > I my view the current mechanism > should be not recommended and only used as an error message when the > client in good faith try to access a resource believing that it might have the > right to access it. > It is indeed intended as an error message when the client in good faith tries to access a resource believing it might have the right to access it. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
