Hi ACE, Sadly I couldn't attend the interim meeting yesterday. Did the WG decide on how to proceed with regard to John's comment?
/Ludwig > -----Original Message----- > From: John Mattsson <[email protected]> > Sent: den 7 september 2020 14:11 > To: [email protected]; Seitz Ludwig <[email protected]> > Subject: Re: AS discovery in draft-ietf-ace-oauth-authz-35 > > 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 <[email protected]> > Date: Monday, 7 September 2020 at 12:45 > To: Seitz Ludwig <[email protected]>, "[email protected]" > <[email protected]> > 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 <[email protected]> > Date: Monday, 7 September 2020 at 08:28 > To: John Mattsson <[email protected]>, "[email protected]" > <[email protected]> > Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35 > > Hi John, > > Replies inline > > /Ludwig > > > -----Original Message----- > > From: Ace <[email protected]> On Behalf Of John Mattsson > > Sent: den 5 september 2020 14:53 > > To: [email protected] > > 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 [email protected] https://www.ietf.org/mailman/listinfo/ace
