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)
- CIFS/SMB (Samba, Windows, Netapp)
- Database (SQL Server, Postgres, jTDS, FreeTDS)
- HTTP (Apache, nginx, all major web browsers, curl, client HTTP libraries
- DNS (authentication for dynamic update, implemented by both Windows and BIND)
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.
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.