geal

Biscuit maintainer here o/

There's definitelt some cool use cases we could collaborate on. One thing I'm looking at more deeply right now is tokens carrying the necessary data as they go through the system,to make sure one call does not see some of it rights change dynamically when going from service to service

(biscuit author here) I tried a lot of different formats, especially looking for something that generated small tokens, that could have a canonical form, and that was supported in a lot of languages. The canonical part was a dead end as most formats did not support that well. Protobuf ended up being the one which generated the smallest tokens, and was easily supported in most languages, even if, like you, I don't agree with everything in the way it's serialized. Self describing formats were a dead end as well because it grows the token size

check if: if any one of those fails, the entire authorization fails allow if/deny if: they are tried in order, we stop at the first that matches. If an allow if matches and all checks passed, then the request is authorized

oh and for OAuth, it can integrate well with it: https://www.biscuitsec.org/blog/oauth-oidc/

(biscuit author here) you caught me, I can't help getting excited about the project XD

Given a long-term token, can I create short-term, auto-expiring tokens?

yes, with attenuation: https://doc.biscuitsec.org/recipes/common-patterns#expiratio...

Is there some revocation mechanism?

In a token, each block has a revocation id, so if you revoke a token, all the tokens derived from that one will be revoked as well. As for how to handle those revocation ids, it's the same strategies as in other systems, reintroducing some state to check revocation lists: https://www.biscuitsec.org/docs/guides/revocation/

How do these things line up against JWT or OAuth? When should I prefer this, but also when should I NOT prefer this?

JWT has a lot of footguns, especially in the way it handles the list of algorithms, and libraries tend to all go through the same set of mistakes (a lot of them are stable now though). JWT are good to transmit a small amount of data, and are overall well supported. JWTs do not enforce any authorization system, you have to add one yourself. Biscuit is very strict in how it deserializes and verifies tokens, so it avoids the usual JWT issues (partly by its spec, partly by an extensive test suite). Biscuits can be larger than JWTs, and can take longer to verify (one signature verification per block). Biscuit comes with its own authorization, based on a logic language, that can be both carried by the token and provided by the verifier. It has implementations in a lot of languages but is not as widely supported as JWT yet.

I'd say if you can live with JWTs containing a little data (like a sub to look up in DB) and a simple authz system like a RBAC, keep using it, that will work well. But if you can benefit from attenuation (ex: per request attenuation https://doc.biscuitsec.org/recipes/per-request-attenuation and delegation https://www.biscuitsec.org/docs/guides/microservices/ ), then look into Biscuit, it can help

(Biscuit author here) there is some support for revocation with the way revocation ids are implemented: there's one generated for each block of a token, so if you add the token's last block's revocation id to the revocation list, then all tokens derived from that one will be revoked as well. We outline the strategies to manage revocation in https://www.biscuitsec.org/docs/guides/revocation/ but as you said, there is no magic here, adding revocation reintroduces state in the system. As for why you would use this over JWTs: Biscuit avoids JWT's usual footguns, specifies an authorization language where checks can be carred by the token, it adds attenuation and third party blocks. You can build a lot more with those tokens

there's a siimilar concept in Biscuit, the 3rd party block: https://www.biscuitsec.org/blog/third-party-blocks-why-how-w... It's not advertised a lot right now because it's not supported by all libraries yet

It is very much intended :D

No standardization for now, as we were still exploring the model. The spec is carefully built for evolution though, providing backwards compatibility where possible. The main developers are Clément Delafargue, maintainer of the Haskell version, now employed full time at Outscale to work on Biscuit, and me, Geoffroy Couprie, original designer of the token and maintainer of the Rust version, working at Apollo GraphQL (unfortunately not on Biscuit yet)

This is not a cryptocurrency technology,it was designed with microservices authorization in mind, inspired from JWT and macaroons. I have looked at cryptocurrency related tech earlier though (pairing libs from zcash, gamma signatures), because it could be a good basis for attenuation, but moved to simpler solutions lately

PASETO is great! It's way better than JWT, for the use cases targeted by JWT. Biscuit explores other use cases, like attenuation

Right, we forgot to add the context on this release, thank you for the feedback!

(biscuit author here) I like how that post points a crucial issue in authorization systems: how powerful and flexible should we make them?

If you go towards flexibility, you get more complexity and possibly unexpected results. And they become hard to audit and explain.

You can choose simple, single purpose systems, like a RBAC only authz backed by a SQL database. You write tight, easy to understand policies. But systems always grow beyond the bounds of those rules, and you end up with a lot of ad hoc rules, or role explosion.

Datalog was a good tradeoff for Biscuit (https://www.biscuitsec.org): powerful enough to cover a lot of use cases, simple enough to be implemented the same way in multiple languages

We in fact tested multiple languages. I can even point you to various works done at the ANSSI like https://github.com/ANSSI-FR/bootcode_parser (python) or https://github.com/ANSSI-FR/caradoc (OCaml). I tried Haskell for VLC and it was not really suited for it (GC pauses in a synchronized media pipepline, and not meant to be called from C). But this was not a paper about comparing parser implementations.

Type-safety and lack of garbage collection are essential properties, could you tell me why you don't think that's the case?

Giving the reason for our language choice felt useful. Otherwise, it would have really looked like Rust developers steamrolling into projects :)

(one of the authors here): parser generators are generally good for one thing: parsing programming languages. For more complex formats, where you have to carry state around, or binary formats, they're extremely cumbersome to use. I often meet people that tell me they want the parser generator to end all parsers. But for most real world formats, you'll have to hack around the generator's limitations. Theoretically, parser combinators are less expressive, but they're just functions: you can write whatever you want inside a subparser, and integrate it with the rest. That approach works well, since we wrote a lot of complex parsers with nom.

thanks!

does it provide ordering and transcript verification, even in case of partition and resume? I know that XMPP is meant to handle that kind of stuff reliably, but a multiparty OTR or Axolotl ratchet should make sure that even if the transport is compromised, you can detect any message drop or tampering.

That new git server is so fast, it finished before you started it!

More seriously, the performance improvement here is really significant

That's nice to know, thanks!

Nom works on stable, but there are nice things you can do if you use the nightly, like matching on error codes with slice or box patterns ( https://github.com/Geal/nom/wiki/Error-management#with-slice... ) or use no_std to embed the parser as a C library ( https://github.com/Geal/nom_in_c ).

Parser combinators are recursive descent parsers, so they do not manage ambiguities at compile time. At runtime, the first parsing path that works will win.

Nom can handle easily regular, context-free and context sensitive grammars (a lot of binary formats are a bit context sensitive, so that was a requirement). I suspect it could do recursively enumerable too.

I have never used pyparsing, but the approach seems similar. Right now, the only real limitation is that I still have a few combinators to implement. Otherwise, anything complex you might want can be done by writing a simple function.

I do not know if it is faster, I should add it to the benchmarks :)

The biggest difference here is the use of a syntax extension to parse the grammar. This is something I would like to do at some point, because it can make the code nicer. Right now, macros are good, because you can use nom directly without Rust 1.0, no need for feature gates.

That's a fun numbering scheme, but it might be cumbersome in the long run, right?

It's named that way because a nom parser takes a byte of data ;)

yes, that's the plan! I had to take care of the basic tools and the plumbing first, but I'll add better algorithms.

The parser combinators are a common approach in functional languages. Basically, instead of generating the whole parser from a grammar, you assemble a lot of small functions, in other functions. The resulting code often ressembles the grammar very closely, and all of the intermediate parsers are very easy to test.

Proving with Coq the soundness of a parser compared to its grammar is a cool approach! The biggest problem one has when writing parsers in "safe" systems like parser generators or parser combinators, is the gaps between the input language intended by the designer, the input language described by the grammar and the input language described by the code. Anything that can reduce those gaps is welcome.

I shoul try at some point to use Coq or some SMT based system to hunt ambiguity in formats. That would make an interesting research ;)

I really like your approach with trait objects. This is something I would have liked in nom when I started it, but macros proved more useful for my experimentations (less types to rewrite when I change something).

For the streaming part, it is still a work in progress. I need a way to better represent input enabled state machines, otherwise we'll end up with streaming switch based state machines, and they are a security nigtmare.

Hi all, Nom's author here.

I wrote this paper in January 2015, so some things changed in the meantime:

- the benchmarks have been optimized a bit, and someone contributed a cereal parser that beats nom ( https://github.com/Geal/nom_benchmarks ). It's alright, I just wanted to estimate where it stands

- there is better error management: https://github.com/Geal/nom/wiki/Error-management

- the error management types give powerful debugging features: http://dev.unhandledexpression.com/slides/langsec-2015/img/c... (test code: https://github.com/Geal/nom_colored_hexdump )

- It is now easy to embed in C ( https://github.com/Geal/nom_in_c ). I plan to make API compatible versions of some C libs

- there are more example parsers now: https://github.com/Geal/nom/issues/14 feel free to pick one up!

Here are the slides for the conference at the IEEE Langsec workshop: http://dev.unhandledexpression.com/slides/langsec-2015/

Langsec is one of the most interesting approaches to follow in security, and the ideas presented this year were amazing (I'm especially fond of the heap exploitation algebra). I highly recommend watching the videos once they will be available.

Writing parsers with nom is easy and fun, please give it a try ;) https://github.com/Geal/nom

If you have any questions, feel free to poke me. This tutorial was fun to do :)

This is a really interesting perspective. THe most important secret you have to manage is often the private key used for TLS, but in usual architectures, it must be present on all of your front servers.

This is a good way to compartmentalize the system, for a very small cost in performance.