4 ms·
> The single biggest pain point in deployed systems in the 90s: lack of reliable system time on authenticated clients (mostly PCs), leading to clock_skew errors
by cryptonector 3y ago
> The single biggest pain point in deployed systems in the 90s: lack of reliable system time on authenticated clients (mostly PCs), leading to clock_skew errors.
Kerberos can be used to get time from the KDCs though! Sure, MIT's grad students didn't build a program for doing that, but they could (and should) have. Say you send an AS-REQ or TGS-REQ w/ incorrect time to the AS/TGS, so you get back a KRB-ERROR telling you that your time is wrong, but also telling you the KDC's time. Well, ok, the KDC's time would not be authenticated, but you'd first get an initial ticket (AS) then you'd do this again using a TGS exchange, and if it works then you know you got a KDC time reading that's good enough. (You'd want to do this mainly with randomly-generated service keys, not with user passwords.) Now with the FAST extensions you get authenticated time.
Microsoft had a wonky, crappy NTP-secured-with-Kerberos, too.
- lukeh 3y agoWell, secured with the machine secret (which happened to be also the Kerberos long-term key). There was no Kerberos in their SNTP protocol extension, at least when I last looked at it.
- cryptonector 3y agoThere was Kerberos in their SNTP! It was just NTP with 1DES auth keys. Which 1DES auth keys? The ones derived from the machine account password for this purpose.
- lukeh 3y ago[MS-SNTP] specifies the signature as the MD5 hash of the machine key and the message to be protected.
- shermantanktop 3y agoWe 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 agoThe 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 agoHaving single-ended private channels trivially available makes the simplicity of JWT possible. That wasn’t present in the days of Kerberos.
- eichin 3y agoThe VXWorks port I did (as a Cygnus contract to some part of NASA that had gotten hit with a "security mandate" used basically that trick, because we couldn't assume the hardware had any realtime clock at all, so we had to stash something and work with a tick counter.) Hmm, https://web.mit.edu/eichin/www/embedded-kerberos.html https://web.mit.edu/eichin/www/embedded-kerberos.html mostly talked about porting, and doesn't mention the clock problem - that was the right project though.