Macaroons: capabilities vs credentials

I've been looking a lot at Macaroons lately:

http://macaroons.io/
http://research.google.com/pubs/pub41892.html

The way I've been describing Macaroons lately is a length extension attack
on a cookie, but one that hopefully always attenuates authority but never
amplifies it. They allow any bearer of a Macaroon to magically chain what
they call "caveats" onto the Macaroon they currently hold using one weird
HMAC trick.

Macaroons start their lives as something akin to a pure capability, but the
paper's authors call it a credential because it gives you the power to bind
it to a specific bearer in various ways, for example by IP address or TLS
channel ID.

Macaroons also provide a rather sophisticated mechanism called "third-party
caveats" where you must go get a second bearer token (or third, or nth)
known as a "discharge macaroon" for your current macaroon to be valid. This
might involve authenticating against a service via whatever mechanism,
presenting a macaroon with an embedded third party caveat, and obtaining an
additional credential known as a "discharge macaroon" which is necessary
for the first to be considered valid.

I know the term "capability" is a bit sacred, and the authors of the paper
call Macaroons a credential instead of a capability. However, do Macaroons
fulfill the general ideals of capabilities?

The distinguishing characteristic, as they describe in the paper, is what
they call "contextual caveats", the ones that limit the scope in which a
Macaroon holds power, like binding it to an IP address or TLS channel ID
(or public key, subject, etc). When a contextual caveat is added, a
Macaroon alone (or chain of them) ceases to be "necessary and sufficient"
to gain access.

Does a capability cease to be a capability (and become a "credential") if
bound to an authentication mechanism like a TLS client certificate?

Are "contextual caveats" a good idea?

-- 
Tony Arcieri

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