26 ms·
I’m not sure I follow: if the other party is allowed to create claims too, symmetric crypto seems more obvious. That’s what NS (and later KRBv5) did in the seve
by lvh 9y ago
I’m not sure I follow: if the other party is allowed to create claims too, symmetric crypto seems more obvious. That’s what NS (and later KRBv5) did in the seventies. Or is that precisely what you’re saying?
- WorldMaker 9y agoIn a stateless, negotiation-less flow where you have no pre-existing relationship with the other party? Isn't that exactly the bootstrap that PKI was built for?
- lvh 9y agoAha, I missed the stateless negotiation-less flow. But yes, that's basically TLS as deployed in browsers :)
- e12e 9y agoKerberos vouching hinges on "ticket-granting server says...", and you know that because the tgt shares a secret with every player. On the face of it, it'd be much easier to just demand everyone know the tgt's public key (no need for N keys on the tgt for N participants). I've long considered the merits of a kerberos-like system built on top of something like nacl... But without out-of-the-box support from all kinds of systems... It'd essentially build down to ssh+certificates with expiration dates... So i've gathered "better CA for ssh" is the better product. And there are thankfully a couple of projects in that vein (teleport, netflix/bless, others?). [ed: i should add: I think tptacek is absolutely right about public key systems being easier to get wrong; but part of that is also the problem domain: look at the history of security issues with Kerberos (both implementations and protocol evolution) for a great example. On the face of it NxN key exchange is "text book simple; should be easy to define, a little tricky to scale". Then there's replay, clock drift, (de)serialisation, nounces, large number of session keys (secure random numbers)...]