Continued Use of Kerberos

Question

I posted this question over on Crypto.SE, but didn't get any takers and thought it might be more suited for this site as it were, so I'm cross posting it here.

I was recently looking through the Mac OS X 10.10 source code and noticed that it has a Kerberos client, and in addition the bastion of all human knowledge that is Wikipedia notes that it is still a common component of most modern OSs. I was aware that the original MIT library was still under active development, but I was not aware that Kerberos' use was still so widespread.

Considering there are other SKDS that do not have its drawbacks (reliance on time synchronization and imperfect protection against replay-style attacks, unnecessary key confirmation, etc.), I was wondering why it is Kerberos has continued to be used in modern systems? Is it simply a matter of those drawbacks being sufficiently minor combined with the availability of a stable, well-tested and widely deployed library, or are there other reasons that make it more feasible and useful in practice than the other schemes that solve its issues on paper.

Answer 1

Kerberos has multiple mature, interoperable implementations on major platforms with active user communities and under continuous development (MIT Kerberos, Heimdal, Microsoft, Java), and through standard abstraction layers such as GSSAPI and SASL, it is easy to use Kerberos either directly or indirectly to secure many standard applications and protocols, including:

• SSH (OpenSSH, ssh.com, VanDyke VShell/SecureCRT)
• IMAP and SMTP (Cyrus, sendmail, postfix, Thunderbird, OS X Mail, Alpine)
• Subversion
• CIFS/SMB (Samba, Windows, Netapp)
• Database (SQL Server, Postgres, jTDS, FreeTDS)
• HTTP (Apache, nginx, all major web browsers, curl, client HTTP libraries in Perl/Python/Java/C/...)
• DNS (authentication for dynamic update, implemented by both Windows and BIND)
• NFS

All these protocols and implementations have built-in Kerberos support ready to be used, if only you provide the infrastructure and know how to do it. This is not just theoretical; where I work, I am in charge of the Kerberos infrastructure for my firm, and we have all these applications and more. They all interoperate seamlessly across both Windows and Unix; our users log into their Windows or Unix desktop, type their password once, and then never type it again while accessing all these services, both directly and after using SSH to log into other hosts (where their Kerberos credentials are automatically forwarded and used). Credential delegation in different flavors is available to allow authorized servers to access further services on a user’s behalf via controlled use of the user’s identity. We do not have the nightmare of managing SSH hostkeys across various platforms and clients (OpenSSH known-hosts files, PuTTY registry keys, etc.); Kerberos authenticates our SSH servers as well as their clients.

If you have narrowly defined needs, then you can get away with other systems. If all you want is single-signon to web applications from full web browsers, for example, then you can use any one of several schemes — but if you also want to access that web app programmatically from a simple program that doesn’t have a Javascript engine and a user to type in a password, you’re pretty much stuck. With Kerberos, the same credentials work the same way in both scenarios.

None of this is to say that Kerberos doesn’t have its weaknesses, or things which should be improved. The use of Kerberos in HTTP (“HTTP Negotiate”) is a hack with problems; really, what we need is pervasive implementation of Kerberos ciphersuites in TLS. Using Kerberos to secure data traffic lacks forward secrecy, which is increasingly important these days; we need a GSSAPI mechanism which combines Kerberos authentication with a Diffie-Hellman exchange, as the SSH GSSAPI key exchanges do; once that exists, it can work transparently with any correctly written SASL client that uses a security layer (as do several of the cases mentioned above). This avoids the combination of Kerberos and TLS in separate layers, which has too many round trips and requires PKI when Kerberos by itself is sufficient.

Also, much of this usefulness is due to the wide adoption of GSSAPI and SASL in protocols through which Kerberos is used, rather than specific properties of Kerberos itself; other mechanisms made usable as GSSAPI mechanisms might enjoy similar usability, and there is current work on doing this for OAuth, for example. Kerberos has the advantage of still allowing for simple password-based authentication, while allowing for stronger methods as well (public-key certificates via PKINIT and OTP schemes are both supported), whereas PKI is tied to needing a second factor of some kind to hold the user’s private key and trusted CA certificates, which has limited its adoption for user authentication for quite some time.

In any event: if you want single-signon today, with existing systems out of the box, across a wide variety of applications and protocols particularly in an open-systems environment, Kerberos is pretty much the only game in town: nothing else matches its pervasive availability, usability and support in existing products and protocols, both commercial and open source.

Answer 2

For old protocols to be replaced by newer ones, it is not sufficient that the old protocol is inefficient, clunky, complex, and has more holes than Emmental cheese. That the new protocol is shiny, fast, simple, fashionable and secure does not ensure upgrade either.

To really get rid of an old protocol, you must kill all the humans that have grown accustomed to it. Imagine a young student; we will call him Herbert. In the 1980s, Herbert learned about Kerberos and, in the folly of his youth, imagined it to be the peak of ingenuity and perfection in security. Fast-forward 30 years: it is now 2014. Herbert has married, divorced, fattened by 40 lbs, reached the fateful age of 50, and pursued a successful career as an IT professional. He is now a "senior architect" and gets to decide about technological orientations in a big organization (maybe a 10000+ government institution). He got there through the magic of time-based promotions, and remains in the nexus of decision-making circles because he is the best pal of some high-ranking manager.

Unfortunately, for all his skills at outmaneuvering competitors and killing reputations with some finely tuned rumours, Herbert has never found it fit to update his technological skills and, for instance, take time to really understand what that newfangled "Internet" thing could be. Therefore, Herbert still responds to all questions: "Kerberos. We need Kerberos.". And, in the land of triumphant capitalism, if Herbert wants Kerberos, he will find some people to sell him some Kerberos (in that case, Microsoft, who uses Kerberos preferentially for all things Active Directory).

Herbert will still be active for another 10 to 15 years. Worse, he is contagious: ambitious youngsters of about 35 years old navigate in his shadow and mimic his postures in the hope of reaching higher levels in the local hierarchy; and these too parrot the Kerberos stance, because it worked for Herbert, and they don't really grasp what this is all about. In 30 years these people will keep on being toxic.

On a similar note, meditate this excerpt of a Wikipedia page:

In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software. 36% of managers said they planned to migrate from COBOL and 25% said they would like to if it was cheaper. Instead, some businesses have migrated their systems from expensive mainframes to cheaper, more modern systems, while maintaining their COBOL programs.

If COBOL's corpse is still not only twitching, but actively walking and getting on its business, then you cannot expect Kerberos to disappear any time soon.