3 ms·
> The paradigm was that systems were large and reasonably well administered, basic trust was established at the host level, and the real problem was users. Wel
by cryptonector 3y ago
> The paradigm was that systems were large and reasonably well administered, basic trust was established at the host level, and the real problem was users.
Well, not quite. The problem was that all the orchestration code ("domain joining", etc.) just wasn't written in the 90s at all. Eventually several orchestration systems were written, with varying levels of functionality:
- Windows 2000 (orchestrates only machine account and SPN credentials)
- OSKT (https://github.com/elric1)
- Wallet (https://www.eyrie.org/~eagle/software/wallet/readme.html)
- FreeIPA
A proprietary implementation I'm familiar with uses Heimdal's "virtual service principal namespaces" to orchestrate service credentials with no KDC writes, making "Negotiate" Kerberos operationally indistinguishable from JWT bearer tokens in that system.
JWTs don't require a library or API, while Kerberos does. JWT is easy enough to implement using only a straightforward crypto library (though one should be super careful as it's very easy to accidentally not validate a JWT's signature!). Kerberos is not. Validated JWT claims are just JSON, and it's trivial enough to stuff extensions in there. Kerberos tickets are extensible enough, but getting at those extensions is a bear.
- shermantanktop 3y agoHaving single-ended private channels trivially available makes the simplicity of JWT possible. That wasn’t present in the days of Kerberos.