Mental model for caveats

[Jason Axley]

Caveats are great.  They make authorization validation simple via the verifiers and proof-carrying information.

However, all of the examples gloss over something that in practice I'm trying to wrap my head around:  How does the system verifying the macaroon to determine if you should have access to a resource know how to build the verifier, especially if caveats can be added by any intermediary along the way?  The examples all assume there is complete knowledge at Macaroon minting time and at verification time of all of the caveats that need verification.  But this is not guaranteed.  In some testing using the APIs, I've seen that not including a single satisfy_exact is enough to cause the whole proof chain to consider the macaroon invalid.

Furthermore, the examples all assume a simple case where all of the information necessary to build a verifier is readily at-hand in a request.  But that's not often the case.  You need some account information perhaps or some claims from elsewhere (session or account) to provide the *full* context since all information for a request is not necessarily in every request explicitly.  Or you may need to map request parameters to an internal domain model or identifiers in order to actually invoke the request.

Additionally, another pragmatic aspect I've been wondering about is the round-trip expectations in a networked application.  General examples of a filesystem where you get a token to access a single file are impractical in practice, unless you want to incur two requests for every operation:  1. to obtain a token to do the operation 2. to request the operation.  How are the caveats typically implemented to balance expressiveness with network chattiness?  What if you had a REST API?  Are there examples of how the operations and resources have been modeled in real applications, including how the macaroon is obtained?  Are there any examples, ideally even sequence diagrams, showing real-life implementations that handle these in a practical way?

-Jason

[Tony Arcieri]

Hi Jason,

As you've pointed out, the extant Macaroons implementations leave caveats as relatively unstructured / opaque data.

A decades old perpetual topic is using some sort of Prolog / Datalog-alike for this purpose. There are several people working on ways to write generalized verifiers based on these ideas. Geoffroy Couprie has been working on this as part of Biscuit, and I've been working on it in Clasp. There's ample prior art in the academic literature (e.g. Binder, PolicyMaker), and a popular modern tool for it is OpenPolicyAgent.

All that said, the sort of problems you're discussing are the sort of thing we're interested in on the FutureTokens list: https://groups.google.com/forum/#!forum/futuretokens

--
You received this message because you are subscribed to the Google Groups "Macaroons" group.
To unsubscribe from this group and stop receiving emails from it, send an email to macaroons+...@googlegroups.com.
To post to this group, send email to maca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macaroons/724e33ad-fa77-4123-a2c4-6388f91de9a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tony Arcieri

[Jason Axley]

It's been a bit quiet in that Google group ;-)

Seems like I've got some literature to catch up on to be of more assistance with these items.

The examples are too contrived so hope some of these ideas may be able to be tested against some known use-cases.

e.g. even https://github.com/rescrv/libmacaroons starts adding caveats about Alice's bank account -- how does it know what her bank account number is?  If she hasn't authenticated, then you can't very well leak her account number in a macaroon to someone who you don't know or trust (yet).  Would like to see the examples reflect the actual state of knowledge that each entity in the flow would have vs. the apparent Omniscient overlord.

Or perhaps the flow should be reversed and the authentication system can (after authenticating you) provide you with a macaroon containing these caveats (about accessible resources) and proving your identity so that you end up with a macaroon that binds you to that particular "resource".  Simply requiring authentication at a particular IdP without context of identity would not be secure.  e.g. anyone could create an arbitrary Google account so being able to authenticate to Google (as a type of third-party caveat in many examples) is of minimal practical value for authorization if you don't have the identity to determine authorization.

-Jason

[Robert Escriva]

Hi Jason,

I think a lot of trouble people have with using or applying macaroons
comes from trying to use them as a policy language for authentication
rather than as a means of proving authorization. If you think of
caveats as describing properties of the principal to be authorized---of
which authentication is a subset---, you're going to have a hard time;
if, instead, you consider them to be restrictions on when and how an
/already authorized principal/ may apply their authority, you'll
probably find they work well for your use case.

Macaroons are for proving authorization, not authentication.

At the core of each macaroon is a secret that's used to mint the root
macaroon. Think of this as the ultimate master key for the resource
associated with the secret. In the example you cite, this would be
Alice's bank account. Anyone in possession of this macaroon has total
authority over the bank account.

The natural remedy for this is to add caveats constraining when and how
the macaroon would be used. In the bank account example, we might only
give the macaroon to Alice after adding a caveat that the macaroon is
only valid with proper identification. Under the metaphor, this is a
form of a third-party caveat, where the macaroon requires a proof that
is filled in by some other macaroon. If Google were to put weight
behind standardizing macaroons (which would be awesome idea, by the
way), the bank could add the caveat requiring "Google says this is
al...@example.org", and Alice could authenticate to Google to receive a
discharge token that could be used for authorization at the bank.

Here's where the power of Macaroons comes in, if you work hard enough to
preserve the purity of the caveat verifiers: The bank teller (the
verifier under the metaphor) does not need to know a thing about how to
interpret this third party caveat or its discharge macaroon in order to
verify the proof tree end-to-end. With just a few standard caveats (the
only one you really need is something to capture and bound the passage
of time) you can build a verifier that can interoperate with arbitrarily
complex policies that may be piecewise enforced across a variety of
services, each embedding its own business logic for when authorization
is granted. Of course, I hope you don't build something that complex,
but the capability is there and will not complicate backend services.

Hope this helps!

-Robert

> --
> You received this message because you are subscribed to the Google Groups
> "Macaroons" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to macaroons+...@googlegroups.com.
> To post to this group, send email to maca...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/

> macaroons/cd6b5eb5-0120-4646-b44d-936b62664ff7%40googlegroups.com.

[Jason Axley]

Robert,

That helps to constrain the scope of applicability a bit.  I do like the idea of being able to chunk out the policy evaluations to external entities and carry along the proof and be able to just refresh those bits as needed rather than the entire macaroon.

The issue I have is still that such examples as below don't fit into the "macaroons help determine what a subject who is already authenticated can access" because there is an implicit assumption below that the system looking to enforce authorization *knows who you are* already in order to even craft the third party caveat that they want Google to validate.  That's backwards though.

One thing I'm looking to try to figure out for a realistic implementation would be:

• A subject has obtained a (discharge) macaroon from an authentication service proving their identity as authenticated by that service
  
• The subject can provide this macaroon when requesting an authorization macaroon from a target service.  That authorization macaroon would know then the user identity so that when it issues a macaroon, it would know how to construct the third party caveat requiring authentication as that identity as one of the conditions for access (to bind the authorization grant to that authenticated identity)
• The target service (knowing the claimed identity), would thus also be able to construct the other authorization claims that would be satisfied in future requests (in conjunction with the discharge macaroon for the third party caveat), knowing the identity to look up the authorization grants for that subject.
  

However, the shared secret model doesn't let this work because the flow is expected to be in reverse -- the target service chooses the caveat key for the third party caveat, so you can't bind the pre-existing authentication macaroon to the newly-minted authorization macacroon for the target service since that was likely created *before* knowledge of any caveat key.

I'm thinking that perhaps this flow could be made to work with a pubkey model though.  Playing around with it to explore some options.

-Jason

> to maca...@googlegroups.com.