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

[Seitz Ludwig <[e-mail]>]

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 <[e-mail]>
> Sent: den 7 september 2020 14:11
> To: [e-mail]; Seitz Ludwig <[e-mail]>
> 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 <[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
> 
> -----Original Message-----
> From: Seitz Ludwig <[e-mail]>
> Date: Monday, 7 September 2020 at 08:28
> To: John Mattsson <[e-mail]>, "[e-mail]"
> <[e-mail]>
> Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35
> 
> Hi John,
> 
> Replies inline
> 
> /Ludwig
> 
> > -----Original Message-----
> > From: Ace <[e-mail]> On Behalf Of John Mattsson
> > Sent: den 5 september 2020 14:53
> > To: [e-mail]
> > 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.
> 
>