how does it work?
Closed this issue · 7 comments
But handling things this way completely
sidesteps all the crypto-goodness that macaroons are built upon.
what is this crypto-goodness? I see hmac and secretbox in the code, but how it is actually applied to the caveats is not obvious (from glancing at the code)
my guess something like you hmac the secret, then hmac each caveat in turn (which would mean you could never remove a caveat but you could add one)? Is this the correct basic idea? is there any documentation about how it works?
Read through the README for a documentation of how the code can be applied.
Read the Google paper for the theory and proof of why it works: http://research.google.com/pubs/pub41892.html
I did read the readme. My question is not how to use the code (which is answered in the readme) my question is how do macaroons work.
fobbing someone off to read the 16 page paper does not make your project accessable.
for any other curious readers, here is the relavant section:
Fundamental to macaroons is how this chain of keyed
HMAC values is constructed, in a nested fashion, along the
sequence of messages in a macaroon—of which, all but the
first are caveats. The first message in a macaroon is required
to be a public, opaque key identifier that maps to a secret root key known only to the target service. (Such key identifiers
can be implemented, e.g., using random nonces, indices into a
database at the target service, keyed HMACs, or using public-
key or secret-key encryption; see [37, Sections 4.2 and 4.3]
for a discussion.) Starting with this root key, a macaroon’s
chain of HMAC values is derived by computing, for each
message, a keyed HMAC value, nested so that each such value
itself is used as the HMAC key for the next message. Thus, a
macaroon with two messages MsgId and MsgCav and root key KR could have the signature HMAC(K_tmp;MsgCav), where K_tmp is HMAC(KR;MsgId).
so yes, it's just a chain of hmacs, where each caveat added uses the previous macaroon's signature as the key.
Citing the paper is not "fobbing" you off. How to use the code is addressed in the README, and that gives you an idea of the applications you can use it for. You don't need to know the implementation to understand and use the abstraction.
If knowing how it works is important, the paper is the best place to start learning about macaroons. The paper itself is quite accessible and addresses how they work. When you read the paper, you'll see that the construction is more than just a chain of HMACs because the idea of third-party macaroons is central to the idea, and is not described by a "chain of HMACs."
Simplifying how something works to the point where you lose the key idea is dangerous, and I would recommend against it.
Making a short response and then closing the issue without taking the time to understand what is being asked, does feel like being "fobbed off". I agree it's possible to use something without understanding exactly how it works, but to evaluate whether something is worth using (or recommending etc) then it's necessary to have some understanding of how it achieves the properties it claims. Especially, since this is a security context. I ended up here because someone asked me what I thought of macaroons, and I read the readme, but was put off by phrases alluding to "crypto goodness" without actually explaining what that is.
It's great there is a paper, but it's a significant effort to read a whole paper when I'm pretty sure the core of the idea could be explained in a few paragraphs. A paper is full detail, what is missing is something in between.
I was able to guess that it involved hmacing each caveat, which strongly suggests that it could be explained fairly simply. (maybe adding detail about the difference between a first and third party caveat, which I am unsure of right now - are these different, or is it just who creates them? is the first party the user and the third the delegate?)
Here's a video from the author of the paper: https://air.mozilla.org/macaroons-cookies-with-contextual-caveats-for-decentralized-authorization-in-the-cloud/
Hi, paper author here (I'm not affiliated with this github project).
There are some very good introductions to macaroons online, e.g.: https://evancordell.com/2015/09/27/macaroons-101-contextual-confinement.html
The construction is deliberately simple, and we don't claim any novel crypto fanciness (and that's the point). Rather, adapting the general framework for bearer-tokens brings several benefits. In particular, we see the easy contextual confinement as a huge step towards limiting the power of bearer tokens, and third-party caveats allow for distributing an authorization decision. The attenuated delegation falls out as a nice extra bonus.
hi @arnar,
I am trying to figure out if the following functionality is possible:
- a Token Server generates a macaroon for a new user (UserRootMacaroon) with some predefined caveats.
- the user issues their own macaroons based on this UserRootMacaroon