6 ms·
A Child’s Garden of Inter-Service Authentication Schemes
- mlakewood 8y agoFYI: 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 8y agoIt’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).
- jameshart 8y agoIs 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.
- lvh 8y agoI’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]:
- jameshart 8y agoApologies 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.
- tptacek 8y agoThat argument doesn't work, because JWT isn't just a "bearer token". It's also potentially an asymmetric token, or any other mechanism someone tries to shoehorn into it next week. That's one of the problems with metaformats. This post isn't a comprehensive argument against JWTs and isn't intended to be. We can't have the conversation about JWT in earnest until we understand the problem domain.
- pvg 8y agoWe can't have the conversation about JWT in earnest until we understand the problem domain. That you're taking it from there is really interesting. Are you finding a lot of JWT use when there's also some S2S auth setup?
- sytringy05 8y agoEverybody is doing it (at least where I'm from). There's good framework/vendor support for OAuth 2 and JWT breaks the nexus between the services and the magic auth server that must be called on each and every request. Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.
- pvg 8y agoRight, but it sounds (if I'm understanding you right) like you're talking about JWT-and-things-as-a-way-for-your-services-to-talk-to-each-other-through-the-client. This is roughly analogous to Ruby cookies - save yourself a database read through the power of maths. But tptacek seems to be saying 'I want you to understand all this S2S stuff before I can begin to rant at you about JWT'. That's a bit different and I'd like to get the rest of this newsletter.
- dward 8y agoThe 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).
- ithkuil 8y agoI found this part to be one of the most common gotchas of macaroons. As often happens when everybody is "holding it wrong", users are not probably the only ones to be blamed. That said, macaroons (from what I understood) are meant to be a token that is only verifiable by the issuer. Third party caveats allow more complex scenarios, but they necessarily involve actual s2s communication to set up (as opposed to the "verification at a distance" allowed by pure asymmetrical crypto) For example: service A issues a macaroon to service B. Now imagine service B needs to talk to service C, which in turns needs to ensure that B can perform some action on service A. If C could verify A's public key signature, we could stop here. With macaroons, C needs to issue a macaroon to B, with a third party caveats that requires B to obtain a "discharge macaroon" from A. When B later performs the request on C, it brings both macaroons (the one issued by C with the 3rd party caveat, and the one issued by A, that proves that the caveat is discharged). C can verify such a macaroon. In particular it can cheaply verify that A is the source of the 3rd party verification.
- lvh 8y agoAre you thinking Vanadium or some other spec?
- dward 8y agoAlbeit this was years ago but I was referring to the construction linked from the original paper proposed in: https://cs.nyu.edu/media/publications/TR2013-962.pdf https://cs.nyu.edu/media/publications/TR2013-962.pdf It’s pretty unweildy compared to HMAC construction because: * each caveat addition requires local generation of a new asymmetric key pair * the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID. * it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender. It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.
- beeknuckle 8y agoIf 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 8y agoOr 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 8y agoA 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 8y agoI'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 8y agoToken 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
- sarcasmic 8y agoIf 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.com/en//pubs/archive/41892.pdf https://static.googleusercontent.com/media/research.google.c... [2] https://github.com/rescrv/libmacaroons https://github.com/rescrv/libmacaroons
- tptacek 8y agoMail 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.
- tango24 8y agoI, for one, appreciate it. Thanks for taking the time to publish!
- Robin_Message 8y agoThe jokes make it readable as well as writeable. Keep them.
- 8y ago
- shkkmo 8y agoI 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)
- bullen 8y agoI just use hashing with single use server salt, why is that not mentioned here. It's secure and simpler than everything else.
- jameshart 8y agoHashing or HMACing? How is ‘single use’ of the salt enforced?
- bullen 8y agoJust 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 8y agoHow 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 8y agoServers are stateful.
- jessaustin 8y agoWhich hash are you using? All this would be for naught if it's one of the many susceptible to length extension attacks; e.g. SHA2. This is the reason everyone uses HMAC now.
- bullen 8y agoThe salt is not attacker-controlled.
- HurrdurrHodor 8y agoI 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 8y agoSecurealpolitik: 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.