A Child’s Garden of Inter-Service Authentication Schemes
latacora.singles
A Child’s Garden of Inter-Service Authentication Schemes
1–10 of 54 posts
Re: A Child’s Garden of Inter-Service Authentication Schemes
#2Re: A Child’s Garden of Inter-Service Authentication Schemes
#3FYI: 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.
Re: A Child’s Garden of Inter-Service Authentication Schemes
#4Still 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
#5Re: A Child’s Garden of Inter-Service Authentication Schemes
#6If this is a reference to Maslanka's "A Child's Garden of Dreams", I like it. One of my favorite pieces for wind ensemble.
[1] https://en.wikipedia.org/wiki/A_Child%27s_Garden_of_Verses
Re: A Child’s Garden of Inter-Service Authentication Schemes
#71. 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
#8Is 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…
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
#9A 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…
Re: A Child’s Garden of Inter-Service Authentication Schemes
#10Is 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[*]…
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.