
A Child’s Garden of Inter-Service Authentication Schemes - russjones
https://latacora.singles/2018/06/12/a-childs-garden.html
======
sarcasmic
If you're like me and are wondering what Macaroons are, some searching
revealed to me that this is the 2014 paper [1] that introduced them to the
public. It's a nested, chained HMAC construction that's useful for delegation,
and here's a library and some code examples [2] that one can play with to get
a feel for what they do and how.

No wonder it's not well known: it hasn't been picked up by the blog treadmill
where dudes on Medium post half-baked info they just found out about, and
isn't being pushed by commercial auth proxies.

On that note, posts by Latacora or affiliated persons, there and here, seem to
mix well-researched opinions and advice with in-jokes that are lost on all but
other experts, assumptions of an inconsistent amount of domain expertise, and
quips that muddy some topics more than a bystander would reasonably expect.
Why not be more dry and less wry, include links, and morph the FUD around JWT
to something real?

[1]
[https://static.googleusercontent.com/media/research.google.c...](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf)
[2]
[https://github.com/rescrv/libmacaroons](https://github.com/rescrv/libmacaroons)

~~~
tptacek
Mail us any time for a refund. :)

I'm fucking around, but really the answer is: if we didn't have the
presumptive informality of a "blog" or some-such, we just wouldn't write; we'd
get 20% of the way through a draft and just pick at it, hoping to make it more
correct and authoritative, until our will to keep going evaporated. I have a
whole folder full of things I started doing that with.

The in-jokes and snark are what trick us into writing in the first place.
There's no getting rid of it.

I'm hopeful that people can at least appreciate that we aren't confining this
stuff to Twitter threads anymore.

~~~
Robin_Message
The jokes make it readable as well as writeable. Keep them.

------
jameshart
Is this _finally_ the more expansive statement from tptacek than just "Don't
use JWTs" that I've been waiting for?

Still feels like we're waiting for another shoe to drop in this space - maybe
it really is Macaroons?

But since container-driven microservice orchestration is ultimately destined
to recapitulate the whole of CORBA and DCOM and therefore probably kerberos
and every flavor of PKI ever attempted before it gets blown up and replaced
with something leaner and simpler and based on shared secrets again, I don't
hold out much hope.

~~~
dward
The published asymmetric macaroon constructions were pretty gross last time I
looked. We were missing a practical asymmetrically verifiable append only
signature. This deficiency rules macaroons out of numerous use cases (namely
where the relying party is separate from and untrusted by the issuing party).

~~~
evancordell
I implemented publicly-verifiable macaroons as a PoC and found them reasonably
ergonomic:
[https://github.com/ecordell/watchstander](https://github.com/ecordell/watchstander)

(docs are sparse, I wrote an accompanying doc that might help:
[https://docs.google.com/document/d/1AU9bwpMYlnWBlwSIiwNyse0N...](https://docs.google.com/document/d/1AU9bwpMYlnWBlwSIiwNyse0NiMaGuM-r4hZGYEsHFcA/edit?usp=sharing))

The basic idea is what you described: append only asymmetrically verifiable
signatures.

As with most things Macaroons, the harder part is developing a caveat language
and verifiers that actually meet your needs. And convincing people that
they're a good idea.

~~~
lvh
I think there are a few weird incompatibilities between libraries that are
likely to bite you unless you have 1 library you use, but generally speaking:
yes, figuring out how to structure your claims is the hard part. Most claims
are really quite simple, which is why I’m bullish on most tiny startups just
sticking a random token in a database and calling it a day.

------
shkkmo
I don't understand the condemnation of JWTs, this article doesn't seem to
explain the condemnation other than saying that "It is extraordinarily easy to
screw up JWT." and not to use them.

We use JWTs to provide SSO authentication functionality to partners who wish
to take on the responsibility for authenticating their users. I still feel
like JWT was the correct choice but I'd really like to know what alluded
potential pit falls are.

They provide us with the public key of a asymmetric key pair and we provide
them with a key ID to use to identify this key a pair. On our side we
associate their key ID(s) with the users they are allowed to authenticate.

When they wish to authenticate a user, they generate a JWT with a user
identifier, the client IP address, the Key ID , and the "issued at time". This
is then signed using their private key associated with the Key ID. They then
provide this to to user's client who then send it us.

We then verify the recency of the JWT, that the JWT is indeed signed by the
private key associated with the key id provided, that the IP address matches
the client and that the key ID is valid for authenticating the user associated
with the user identifier. If all this checks out, we can create a session for
the client (using the standard cookie bearer token model).

The reasons we picked JWT are:

1) We aren't responsible for securing their secret(s) (since we never know
them) and they can easily send our their public keys to us via less secure
channels. If we get a correctly signed JWT, this proves that either the
partner approves the authentication or that they have lost control of their
private key (in either case, the responsibility is theirs since we have no
ability to generate a JWT signed by their private key). This seems like a big
improvement over using a shared secret.

2) There are existing libraries for most languages to generate and sign a JWT
when provided with a few parameters, this decreases the likely hood that our
partners will try to roll their own buggy authentication implementation.

Aside from the issue of trusting our partners not to expose their private key,
I'm not sure what the foot-guns are here? (although I am admittedly not an
expert)

~~~
tptacek
So what you're saying is that you re-invented SAML, but with JWT? What you're
describing is SAML; every commercial SSO system on the market offers it
natively.

~~~
shkkmo
Our partners are not commercial SSO systems, nor do they all use commercial
SSO systems.

We looked at SAML and it didn't seem to be a good fit for our use case. It is
overly complex for our needs.

Instead we built a very small subset of what SAML allows, that is very easy to
understand and allows our partners to use lightweight JWT libraries with
simple APIs instead of trying to figure out how to get a complex SAML
implementation to work with our flow.

We didn't re-invent anything. We used an existing, simpler standard for one of
it's intended use cases. Our implentation is < 100 lines of code (not
including the JWT library which implements the standard).

Edit:

The relevant SAML flow is this:

[http://docs.oasis-open.org/security/saml/Post2.0/sstc-
saml-t...](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-
overview-2.0-cd-02.html#5.1.4.IdP-
Initiated%20SSO:%20%20POST%20Binding|outline)

But good luck finding good documentation on it.

~~~
tptacek
The model that you described is, verbatim, the bearer model of SAML that
everybody uses. SAML in theory does more than just that, but the flow you just
described is the subset of SAML that every open source SAML library
implements. Apart from some minor security controls that you didn't describe
and that SAML implements, the only difference is that you built your ad hoc
system using JWE, and SAML is built with XMLDSIG.

(Responding to edit)

I can only assume that the most widely-used flow in SAML, the dominant SSO
protocol on the Internet, is better documented than the ad-hoc custom version
of SAML you reimplemented with JWT. :)

I don't _like_ SAML (I in fact hate it), but the problems I have with SAML are
all shared by JWE/JWT! You are describing perhaps the one scenario in all of
human experience where I might recommend that someone adopt an XMLDSIG
protocol.

~~~
shkkmo
> I can only assume that the most widely-used flow in SAML, the dominant SSO
> protocol on the Internet, is better documented than the ad-hoc custom
> version of SAML you reimplemented with JWT. :)

JWT has much better documentation than anything I was able to find on SAML,
but this may be due to my lack of experience with the domain. I had trouble
even finding clear documentation on what the basic structure of a SAML
assertion should be. As a developer with limited knowledge of the domain, when
picking a tool to solve my problem I default to the simpler tool with more
accessible documentation.

The documentation for utilizing our JWT implementation is simpler and more
straightforward than what Salesforce provides for it's similar flow
implemented with SAML.

> the problems I have with SAML are all shared by JWE/JWT!

And what are those? This was my original question.

------
beeknuckle
If this is a reference to Maslanka's "A Child's Garden of Dreams", I like it.
One of my favorite pieces for wind ensemble.

~~~
my_first_acct
Or perhaps "A Child's Garden of Verses" [1] by Robert Louis Stevenson.

[1]
[https://en.wikipedia.org/wiki/A_Child%27s_Garden_of_Verses](https://en.wikipedia.org/wiki/A_Child%27s_Garden_of_Verses)

------
dward
A couple corrections to the section on token binding:

1\. It works on all TLS connections, not just mTLS connections. It even works
on unauthenticated TLS (although I wouldn't advise forgoing server
authentication). That's the beauty of key binding the token. It's useless
without the key.

2\. It's unclear what the tokbind noun refers to in this paragraph. I'm going
to assume that you are just referring to the token binding. A token binding
lasts for the duration of a TLS connection (sans renegotiation and resumption
which complicate things) and is derived from the
[clientrandom,serverrandom,mastersecret] of the connection. The token binding
secret is just an RSA or ECDSA keypair, independent of client or server
certificates, that is generated when the token is issued. The token is bound
to the keypair (e.g. by a hash of the public key that's stored in a JWT claim
or stored in a database table keyed by an opaque oauth token).

3\. Anyone can use token binding, not just members of the IETF TLS working
group :)

~~~
tptacek
I'm fuzzy on token binding versus channel ID, the preceding (and, to my eyes,
more useful) extension. In neither case do I anticipate widespread use. But
it's good to know that it's there.

~~~
dward
Token binding changed a few things as it evolved from origin bound
certificates, notably:

* moving from using client certs to signing exported keying material[0] to prove key possession

* adding support for RSA keys

* adding support for multiple token bindings on a single connection (see referred token binding)

Fundamentally the two are very similar. I'm curious as to why you think origin
bound certificates are more useful.

> In neither case do I anticipate widespread use

For the browser case:

* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).

* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to slow to be used practically.

* Many compromises happen in the browser so token binding only marginally improves the security of cookies.

I think it will fall out of favor there. The service to service use case is an
interesting one. If you turn off 0-RTT and session resumption, and bind tokens
to hardware, the security properties start to look a lot like hardware bound
mTLS. If the tooling ever gets developed, it might turn out to be a leaner
alternative to a full blown PKI.

[0]:
[https://tools.ietf.org/html/rfc5705](https://tools.ietf.org/html/rfc5705)

------
HurrdurrHodor
I am somewhat surprised by the statements about asymmetric crypto algorithms.
Given a good library they don't seem more error prone and given many common
use-cases they are not significantly slower.

~~~
lvh
Securealpolitik: saying there are safe asymmetric primitives doesn’t mean
that’s what’s actually deployed. As long as the spec says is P256 ECDSA it’s a
pretty reasonable assumption someone is going to screw up nonce handling.

(Incidentally ECDSA really is that much slower, but I appreciate that could be
seen as cherry picking because ECDSA is slow even for an asymmetric
algorithm.)

I don’t think the argument we’re trying to make is that asymmetric crypto
definitionally can’t work. I’m pretty happy TLS exists. Just skeptical that
you want to build your s2s auth on it.

------
mlakewood
FYI: The article seems to make a comment that implies that SPIFFE is only
available to Kubernetes, this isnt the case and SPIFFE is explicitly designed
for heterogenous environments.

~~~
tptacek
It’s a snide comment, meant to imply that there isn’t much to SPIFFE outside
of MTLS (it’s not a fair dig, but not meant to be one).

------
bullen
I just use hashing with single use server salt, why is that not mentioned
here. It's secure and simpler than everything else.

~~~
jameshart
Hashing or HMACing? How is ‘single use’ of the salt enforced?

~~~
bullen
Just hash = hash(secret + salt) and the server enforces the single use by
generating and sending one for each authentication, so you need double
handshake:

client ----- server

req salt -> gen salt

hash sec. <\- reply salt

send hash -> remove salt

all good? <\- verify hash

~~~
jameshart
How does the server verify that the salt it receives in the second request is
the same salt it generated in the first response? Does the server have to
retain state?

Also you should maybe read [https://benlog.com/2008/06/19/dont-hash-
secrets/](https://benlog.com/2008/06/19/dont-hash-secrets/)

~~~
bullen
Servers are stateful.

