3 ms·

I worked at a commercial Kerberos vendor in the 90s. We had a lot of work to do to clean up after the various student projects and partial refactors that inhab

I worked at a commercial Kerberos vendor in the 90s. We had a lot of work to do to clean up after the various student projects and partial refactors that inhabited the codebase. 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 was clearly built for organization networks with multi-user Unix hosts running software built from source and a willingness to customize their services. The inbuilt support for major packages was often stuck on v4 even though v5 had been out for a while. Kerberos was not built for the internet, or poorly-administered PCs, or closed-source commercial software services (which required painful kerberization).

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 ago
  Well, 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 ago
    There 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 ago
  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.
- eichin 3y ago
  The 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.
jakupovic 3y ago
I remember connecting my Linux Kerberos client and having issues with clock skew, anything over 5 minutes would stop the client from working. But I did have a Linux machine which would connect to the school Kerberos and access network from my house instead of having to go to MU3NE, media unit 3 floor north-east. This brings back a lot of memories. I did still go, but mostly to hang out. Kinda similar thing people that go to the office do these days. I guess things don't change.

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 ago
Well, 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 ago
  There 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 ago
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.
eichin 3y ago
The 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.

jakupovic 3y ago

I remember connecting my Linux Kerberos client and having issues with clock skew, anything over 5 minutes would stop the client from working. But I did have a Linux machine which would connect to the school Kerberos and access network from my house instead of having to go to MU3NE, media unit 3 floor north-east. This brings back a lot of memories. I did still go, but mostly to hang out. Kinda similar thing people that go to the office do these days. I guess things don't change.