Live data from Hacker News

A Child’s Garden of Inter-Service Authentication Schemes

latacora.singles

1–10 of 54 posts

Re: A Child’s Garden of Inter-Service Authentication Schemes

#3

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.

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).

Re: A Child’s Garden of Inter-Service Authentication Schemes

#4
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.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#6

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.

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

Re: A Child’s Garden of Inter-Service Authentication Schemes

#7
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 :)

Re: A Child’s Garden of Inter-Service Authentication Schemes

#8

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 get…

I’m not ‘tptacek but I am a Latacora principal.

It is partially. The problem with the question of what you should use instead of JWT is that it presupposes a usually-wrong assumption that you actually want something of the same shape as JWT, which is usually not true. JWT is a bad answer to the wrong problem: addressing the bad answer part doesn’t address the wrong problem part.

To riff off of jackhammer questions[*], just because chainsaws like PASETO exist and a chainsaw is more effective than a jackhammer at a specific task, doesn’t mean you really wanted a chainsaw.

We will be following up :)

[jackhammers]:

Re: A Child’s Garden of Inter-Service Authentication Schemes

#9
post #7

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 bin…

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.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#10
post #8

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 get…

I’m not ‘tptacek but I am a Latacora principal. It is partially. The problem with the question of what you should use instead of JWT is that it presupposes a usually-wrong assumption that you actually want something of the same shape as JWT, which is usually not true. JWT is a bad answer to the wrong problem: addressing the bad answer part doesn’t address the wrong problem part. To riff off of jackhammer questions[*]…

Apologies for misattribution :)

So yes, this is precisely the problem with sending the message 'JWT is bad' when what you really want to send is 'bearer tokens are bad (and JWT is a badly designed bearer token)'.

I am reminded of the situation a few years ago where the message 'stop hashing/salting passwords with SHA1' got widely interpreted as 'Okay, I'll salt and hash with SHA256', when the real message that was needed was to use bcrypt.

But this time I'm not sure there's a bcrypt, yet.

Post reply on HN