[langsec-discuss] RFC on Boulangerie Macaroons

Tony Arcieri bascule at gmail.com
Sun Jan 31 23:50:18 UTC 2016


Macaroons are a bearer credential format:

http://theory.stanford.edu/~ataly/Papers/macaroons.pdf

I think the Macaroons format is in general rather LANGSEC friendly: it uses
git pkt-lines, which have a 4-byte hexadecimal length prefix followed by a
"binary-safe" line of data. I believe this qualifies as context-free?

There are interoperable libraries for many programming languages which
implement the format, but I've felt the APIs provided by these libraries
are fairly low-level, and have been trying to expose a higher-level API
which handles type coercion and serialization.

The main thing I've being trying to add in Boulangerie, my high-level
"opinionated" Macaroons library, is a schema language and a set of types
used to represent serialized data:

https://github.com/cryptosphere/boulangerie/wiki/Types

tl;dr: somewhat like an S-expression per git pkt-line, but where nested
lists are not allowed.

In defining these I've generally tried to restrict expressive power. The
resulting language has no way to represent nested lists, for example. It
might seem rather tempting to add "(" ")" and allow nested lists (and the
existing syntax is amenable to that), perhaps even throwing out the git
pkt-line part of it and representing the entire Macaroon with
S-expressions, but at least for now I'm specifically trying to avoid that.
Likewise there is (not yet) any string type and therefore no potential for
string escaping vulnerabilities.

I think overly expressive language formats have been a big problem with
bearer credential formats in the past. The worst offender is probably SAML,
with repeated XXE remote code execution vulnerabilities due to the use of
XML. But I can see how the absence of certain features could simply lead
people to create bad ad hoc solutions which would limit interoperability
and also add potential for people to reintroduce the classes of
vulnerabilities I'm trying to avoid.

I'm working within the constraints of pkt-lines and trying to find the
minimum amount of expressive power needed to cover the majority of use
cases (i.e. finding the sweet spot between security and expressiveness)

I think elsewhere there's a push to revive a (previously defunct)
alternative version of the format which used JSON instead of pkt-lines to
handle similar use cases.

Anyway, thoughts?

--

Example schema file (I'm using YAML for describing schemas for now, and
supporting extensible versioned schemas):

schema-id: ee6da70e5ba01fec
predicates:
  v0:
    not-before: DateTime
    expires: DateTime
    blobby: Binary
    booleany: Boolean
    boolean-list: List(Boolean)
    datetime-list: List(DateTime)
  v1:
    another-booleany: Boolean
  v2:
    decimal-list: List(Decimal)
    atom-list: List(Atom)
  v3:
    uri-list: List(URI)

--

Example serialized Macaroon:

0029location https://mysupercoolsite.com
0076identifier v:0 uuid:4213ce9f-1149-44e8-a8cb-ff47d8aff25c kid:key1
sch:7dc57277e5b399ac at 0 iat:2016-01-09T23:52:16Z
0026cid expires: 2016-01-09T23:52:21Z
0029cid not-before: 2016-01-09T23:52:16Z
002fsignature [...]

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20160131/c98f1e72/attachment.html>


More information about the langsec-discuss mailing list