Subject: [Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client

From: Christian Amsüss <[email-masked]>
Date: Mon, 13 Jul 2020 17:12:26 +0200

Hello ACE,

piecing together parts of the big picture of Resource Directory, CoRAL
forms and ACE, I was wondering where in the whole story the client
should tie its intention to the key material it uses to authorize an
action.

Take this -- admittedly contrived, but hopefully illustrative example:

* We have a device (C) inside example.com that coordinates a lot of
  actions (and thus has a good standing with the AS and gets almost all
  the tokens it asks for.

* The device would ike to register its management interface with the RD.

* A malicious attacker intercepts the discovery process, and tells C
  that there is an RD at
  `<coap://attack.example.com/launch-denial-of-service>;rt=core.rd`
  (which is a perfectly legitimate service we're running there for
  commercial purposes; its interface is that you submit POST a link
  there in link-format, and then it ties up the link target with endless
  requests).

* The device tries to register to the local RD by POSTing some data
  there, but as it has no token to the attack server, it receives a

  4.01 Unauthorized
  Get your token from coap://as.example.com, scope launch-attack,
  audience attack.example.com

* The client takes those pieces to the AS, which grants it a token
  (after all, C would be authorized to launch an attack, given it's
  known to be a coordinator -- it just doesn't mean to).

* C sends the token to the RS attack, and sends its POST again, with th
  link to its own management interface.

* The attack server brings C to a grinding halt, because it was tricked
  to shoot its own foot.

(Admittedly it's good practice for foot- and other guns to not just
silently ignore query parameters like ep=the-coordinator&lt=3600, but A)
other interfaces may be more accidentally-compatible, and B) CoRAL forms
would widen the range of craftable requests enormously).

My question here is: Where did this go wrong? Should C have verified
with attack.example.com that it really has the resource type core.rd?
Should it have understood the scope of the action? Should it have a
different security association with the AS for every action it asks
tokens for? And does the answer still hold if it has already obtained a
token to launch attacks (but just didn't notice that the RD it was sent
to happens to have the very URI its attack forces use)?

Kind regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 13 Jul 2020 18:08:53 +0200

Hi Christian,

>   there in link-format, and then it ties up the link target with endless

I would say that C would need to ascertain that C's owner allowed C to
communicate with this RD.

Viele Gruesse
Steffi

---

From: Jim Schaad <[email-masked]>
Date: Tue, 14 Jul 2020 09:53:14 -0700

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Christian Amsüss
> Sent: Monday, July 13, 2020 8:12 AM
> To: [email-masked]
> Subject: [Ace] 4.01 Get A Token From There, discovery-/form-driven
> applications and tokens opaque to the client
> 
> Hello ACE,
> 
forms
> and ACE, I was wondering where in the whole story the client should tie
its
> intention to the key material it uses to authorize an action.
> 
silently ignore
> query parameters like ep=the-coordinator&lt=3600, but A) other interfaces
> may be more accidentally-compatible, and B) CoRAL forms would widen the
> range of craftable requests enormously).
> 
> My question here is: Where did this go wrong? Should C have verified with
> attack.example.com that it really has the resource type core.rd?
different
> security association with the AS for every action it asks tokens for? And
does the
> answer still hold if it has already obtained a token to launch attacks
(but just
> didn't notice that the RD it was sent to happens to have the very URI its
attack
> forces use)?

I would have expected that the C would have two different keys to talk to
the AS.  One for dealing with any attack servers and one for dealing with
things inside the company.  I would also expect that C would know which of
those keys are to be used for any given operation.  Thus if it is doing
registration it will ask for a token using the inside key and not the attack
key.  This would then be denied by the AS.  In terms of an existing token,
the token should be associated with which key was used to obtain it and thus
an existing attacker token would not be used for talking to the RD.

That being said, we need to come up with some better answers for getting
information from the RS to the client in some type of protected manner.
Either that or we need to decide that the client is suddenly going to have
to understand everything.  At one point I was thinking that talking to an RD
over multicast should be done using group keying but I am not sure that is
reasonable.  However it could be reasonable that every C would know the
audience for the RD it wants to talk to.  The problem with that is that if
there are two of them then you would end up with needing to know either the
pattern for RD audience strings or all of the possible audience strings.
You do have the benefit that if you get the answer back from a specific
address, then you are going to talk to that address.  Which works great for
unicast but does not solve any problems with multicast discovery.  

One possible answer is that there needs to be some pre-configuration for
directory services.  It may be that one or more audiences are needed to be
known to the end entity so that it can talk securely to an directory and
thus the first step would not be possible.

Jim