Re: Macaroons: capabilities vs credentials

On Thu, Dec 11, 2014 at 12:17 AM, Tony Arcieri <[email protected]> wrote:

> On Wed, Dec 10, 2014 at 9:53 PM, David Barbour <[email protected]>
> wrote:
>
>> Based on your description, and skimming the paper, I think these bearer
>> credentials are not capabilities. They are, in principle, only weakly
>> coupled to the resource or action being performed. Are users/programmers
>> precisely selecting which credentials they use for each action? I suspect
>> not.
>>
>
> Macaroons make minting a unique credential which precisely authorizes a
> particular request easy
>

Hmm. I think I didn't properly communicate my thoughts.

The idea of choosing which authorities we use for an action is
fundamentally built into the object capability model: designation of
resource is tightly coupled with the selection of authority. This tight
coupling is important. It's how we resist the confused deputy problem. It's
how we keep the model simple and efficient.

Relative to capabilities, macaroons are weakly coupled to resources.

Macaroons are fundamentally based on proving something about the actor. We
prove the actor has the right credentials or keys, or meets some
condition/caveat. It is difficult for the actor to select exactly which
authorities will be used for an action. Due to caveats, it can also be
difficult to precisely grant authority to a resource.

For example, let's say I want to grant you delegable access to a
hypothetical file xyzzy on my system, but only if you also have access to
the 'adventure' database. So I give you a token that says: "bearer has
access to xyzzy; caveat: bearer can prove access to 'adventure'". I think,
hey, it isn't tied to your identity.

If you want to later access xyzzy, you'll also need to fish around in a
'pool' of authorities to find one that grants access to adventure. If your
access to adventure is similarly conditional, you might need to fish more.
Thus, it is difficult for you to precisely select a particular bearer token
to perform the action of accessing xyzzy; you need to throw a pool of
authorities at the problem. Similarly, if you want to grant access to xyzzy
to someone else, you can't do so without granting them access to
'adventure' and every other resource in that chain.

I think these bearer credentials are not capabilities.



Macaroons enable any bearer of a token to add caveats
>

We should separate the concepts involved here.

1) The ability to support offline, decentralized attenuation.
2) The idea of bearer tokens with contextual caveats.

The first feature is very nice for scalability and adoptability. But it
isn't a security feature, and (beyond validating that the scheme works) we
can disregard it when evaluating Macaroons from a security perspective.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk