3 ms·

We had a ticket replay cache built around comparing times. I cannot recall whether the client time was a part of it. But the reason I bring it up is while Kerb

We had a ticket replay cache built around comparing times. I cannot recall whether the client time was a part of it. But the reason I bring it up is while Kerberos could be (and was) extended to the internet and trash PCs, it came from the same era as X-Windows and LDAP. 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.

cryptonector 3y ago
The ticket replay cache does not apply on the TGS side.
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 ago
  Having single-ended private channels trivially available makes the simplicity of JWT possible. That wasn’t present in the days of Kerberos.

cryptonector 3y ago

The ticket replay cache does not apply on the TGS side.

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 ago
Having single-ended private channels trivially available makes the simplicity of JWT possible. That wasn’t present in the days of Kerberos.