> -----Original Message-----
> From: Ace <[email protected]> On Behalf Of Christian Amsüss
> Sent: Monday, July 13, 2020 8:12 AM
> To: [email protected]
> Subject: [Ace] 4.01 Get A Token From There, discovery-/form-driven
> applications and tokens opaque to the client
>
> 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<=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)?
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
>
> Kind regards
> Christian
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
powers.
> -- Bene Gesserit axiom
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
