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

From: John Mattsson <[email-masked]>
Date: Sat, 5 Sep 2020 12:52:31 +0000

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. 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.

Cheers,
John

---

From: Seitz Ludwig <[email-masked]>
Date: Mon, 7 Sep 2020 06:27:43 +0000

Hi John,

Replies inline

/Ludwig

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of John Mattsson
> Sent: den 5 september 2020 14:53
> To: [email-masked]
> 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:
> 
> 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.

---

From: John Mattsson <[email-masked]>
Date: Mon, 7 Sep 2020 10:45:11 +0000

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-masked]>
Date: Monday, 7 September 2020 at 08:28
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35

Hi John,

Replies inline

/Ludwig

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 07 Sep 2020 12:56:57 +0200

Hi John,

please see inline for remarks in addition to Ludwig's response.

John Mattsson <john.mattsson=[email-masked]> writes:

> 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.

It is clear that the AS Creation Hints are just hints, and, as
documented, this information needs to be treated with utmost care. But I
do not see how we would justify to recommend a non-constrained path to
take for a potentially constrained client. A good solution to this
problem (DNS-SD being just one possibility, CoRE RD another) would be to
delegate AS discovery to a not-so-constrained entity in the same
security domain as the client.

Grüße
Olaf

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 7 Sep 2020 13:49:30 +0200

Hi John,

> 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 i…

Yes, the request and response are unauthorized. The client must
ascertain that the AS is authorized to provide access token and access
information to the client. Accordingly, section 6.5 states that "the
client MUST be able to determine whether an AS has the authority to
issue access tokens for a certain RS."

The information that is provided by RS helps C to find the respective
AS. If an attacker changed that information, C would still not
communicate with an unauthorized AS.

Viele Grüße
Steffi

---

From: John Mattsson <[email-masked]>
Date: Mon, 7 Sep 2020 12:11:29 +0000

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-masked]>
Date: Monday, 7 September 2020 at 12:45
To: Seitz Ludwig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: AS discovery in draft-ietf-ace-oauth-authz-35

Hi Ludwig,

Cheers,
John

-----Original Message-----
From: Seitz Ludwig <[email-masked]>
Date: Monday, 7 September 2020 at 08:28
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35

Hi John,

Replies inline

/Ludwig

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 7 Sep 2020 15:13:24 +0200

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

---

From: Seitz Ludwig <[email-masked]>
Date: Tue, 8 Sep 2020 06:50:58 +0000

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

> Sent: den 7 september 2020 14:11
> To: [email-masked]; Seitz Ludwig <[email-masked]>
> Rereading Section 6.4 again I think the discussion on Denial-of-Service /
> amplification attacks in Section 6.4 clearly needs more work.
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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.
> 
>    X.X BTW the error message could be used for AS discovery but has limited
> effeciency and security and is not recommended.
> 
> Cheers,
> John
> 
> > 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.
> >
> > 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?
> 
> > 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.
> 
>