Slashdot Mirror


Kerberos: The Definitive Guide

nazarijo (Jose Nazario) writes "Everyone knows that Kerberos is the biggest solution to the single sign-on dilemma. How can you get everyone using one bank of accounts on loads of machines, from UNIX, OS X, and Windows environments, and do so securely? You can shoehorn in a variety of mechanisms, or you can adopt Kerberos. However, Kerberos intimidates a lot of people, somewhat deservedly so, but also somewhat needlessly. Enter Kerberos: The Definitive Guide, one of the latest 'definitive guides' from O'Reilly." Read on for the rest of Nazario's review. Kerberos: The Definitive Guide author Jason Garman pages 272 publisher O'Reilly and Associates rating 7/10 reviewer Jose Nazario ISBN 0596004036 summary A comprehensive, cross platform guide to Kerberos

I got started using Kerberos many moons ago, at my university. This is probably how many people got to know about it. While I didn't use it very much, it's there that I learned the basics and experimented a bit with Kerberos. Interest in it took off after Microsoft incorporated Kerberos authentication mechanisms into Windows 2000. Suddenly it wasn't such arcane knowledge.

Two open source Kerberos implementations exist, the MIT reference implementation, and the Heimdal Kerberos implementation. Even then, there are two main versions which you can find, Kerberos IV and Kerberos V. Kerberos IV went away for most environments with the passing of the Y2K mark, but some legacy apps need support. So, you still have to deal with it on occasion.

In writing Secure Architectures with OpenBSD, I got a lot more intimate with Kerberos, and even set up a decently sized realm in my house. Hence, I got to experience the turmoil of setup and debugging. A book like Kerberos: The Definitive Guide (K:TDG) would have been very welcome. Instead, I slogged my way through it, and got it to work for the most part.

K:TDG will help you set up your Kerberos world by introducing you to the complex subject, terminology, and the pieces. Once you learn the basics, you recognize that a simple realm is actually somewhat easy to set up. The author, Jason Garman, uses a mixed Mac OS X, UNIX, and Windows environment, focusing on UNIX most of the time. The bulk of the examples deal with MIT Kerberos 5 version 1.3 (krb5-1.3) but should work for most versions. Some attention is given to the Heimdal implementation (which is integrated with BSD, for example), and for the most part you'll be OK. Windows examples are also pretty copious but always come second. If you're comfortable with UNIX, you'll easily be able to translate these into Windows examples to help bridge the Windows gaps.

Chapter 1 is an obligatory Introduction, a short chapter that introduces the key concepts of Kerberos and what the book will cover. A very quick comparison of Kerberos to DCE, SESAME, and earlier versions of Kerberos is given. This chapter serves as a nice selling point for the book, it's the type of thing you'd flip through in the book store to decide if you should buy the book or not.

Chapter 2 is a decent overview for the new user of Kerberos to the system and how it works. Kerberos is placed into its role in a AAA infrastructure - authentication, authorization, and accounting - as well as some caveats that are commonly made. You'll learn about core Kerberos features like tickets, realms, principles, instances, ticket granting tickets, and the ticket cache. A decent overview for practical purposes is given, but you will definitely want another resource if you're interested in diving headlong into Kerberos.

These pieces come together in Chapter 3, where the actual protocols are described. They're laid out for a non-cryptographer, so go elsewhere if you want to learn the real formal material behind the system. Understanding the protocols is important to understanding the service as a whole. For someone new to Kerberos, you'll probably want to spend a little more time reading this to get oriented in the Kerberos world. The chapter doesn't mess around too much and delivers a fair treatment of the material.

Chapter 4 is the meat of the book's material, setting up your implementation. It all starts with the KDC (key distribution center) and realm initialization. Again, the bulk of the treatment is on the MIT implementation on UNIX, with the Heimdal and then Windows sections following next. Slave KDCs are also introduced, which is useful for large environments. An OS X server is missing, but Kerberos clients for all three (UNIX, Windows and OS X) is given. The role of DNS is also explained well, a useful touch that's missing in some Kerberos documents I've used in the past. This chapter will get you started, and with some of the supplied documentation you should be up and running in no time.

Chapter 5 is devoted to troubleshooting, an all too familiar task for a new Kerberos administrator. Common problems, their diagnosis, and resolution are discussed. I like the presentation of this chapter and think it will be useful for most real-world situations you'll encounter.

Security concerns with Kerberos are covered in Chapter 6, which discusses concrete and abstract attacks on the Kerberos scheme. Since all of the security in Kerberos resides in your KDC hosts, obviously this covers some of the material. However, the clients can exposes your Kerberos realm to attacks, as well, and how to circumvent these problems is covered. A decent and practical chapter, and covered on both UNIX and Windows.

In Chapter 7 a number of Kerberos enabled applications are discussed. After all, you can do more than just log on locally with Kerberos, you can use remote login programs like SSH, remote access scenarios like printing, and even control X via Kerberos. While not every application that I would have liked was covered, the treatment was fair and should get you started with a number of Kerberos enabled tools in your new realm.

A strong selling point of the book is given in Chapter 8, titled Advanced Topics. Three main topics are discussed. The first is cross-realm authentication, where you have more than one separate Kerberos realm on your network but you want to have users switch between the two without creating accounts in the other. This can get tricky, and the book does a decent job of introducing it, but it's not as complete as it could be. The second main topic in this chapter is Kerberos 4 and 5 interoperability, which is relatively straightforward. Most Kerberos 5 implementations come with tools to process Kerberos 4 ticket scenarios to handle legacy applications. And finally, a really valuable section covers UNIX and Windows Kerberos interoperability, a hairy issue. Again, incomplete but strong enough that you should be able to get it working with some elbow grease. This is probably the most valuable chapter of the book, which does a decent job at the introductory level, but you'll be left to tie up a few loose ends on your own.

An obligatory case study is given in Chapter 9, where you can see a number of configuration samples and even a mixed Windows-UNIX environment. Not terribly useful when compared to chapters 4 and 8, but overall worthwhile. It may answer some of your questions, even. Chapter 10 wraps up the book with looking at Kerberos futures, which isn't all that useful, honestly. What gets more useful is the appendix, which gives an administration reference. Lots of commands are given for MIT, Heimdal and even for Windows, so you can quickly jump there to refresh your memory on a topic.

Overall this book is recommended if you need a place to start working on Kerberos, especially in a mixed environment. The MIT and Heimdal documents are a fair place to start for a UNIX only Kerberos realm, but if you find they aren't enough, this is probably the right book for you. The book's main strength is that it covers Kerberos on the three main platforms in use (Windows, OS X, and UNIX), although it could provide a deeper treatment to the mixed environment than it gives. Still, you should be able to use this as a starting point, and it's probably the best treatment I've seen so far on Kerberos setup and administration.

You can purchase Kerberos: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page

13 of 177 comments (clear)

  1. But are people comfortable with SSO! by zyridium · · Score: 3, Insightful

    When are people going to realise that the problem with single sign on isn't a technical one....

    1. Re:But are people comfortable with SSO! by Feyr · · Score: 2, Insightful

      single sign on is a damn useful thing for an enterprise network. where you have direct control (as the administrator at least i do) over all the places your employees might ever log on. and where they should only log on for company-related stuff. privacy never enters the equation in those cases

      out of the enterprise, it's a whole different game

    2. Re:But are people comfortable with SSO! by Daedala · · Score: 3, Insightful

      Never.

      It is an article of faith that all technical problems have technical solutions. It is a further article of faith that if a problem can be called "technical" it will be -- no matter whether or not that's accurate. Because technical problems can by definition be solved by technology, and everyone wants problems to be solved, all problems are therefore technical.

      God forbid we have to change the way we do business to fix an issue. No! Just put a technical band-aid on it!

      --
      What I say does not represent the views of my employers, my friends, my cats, or myself.
    3. Re:But are people comfortable with SSO! by ergo98 · · Score: 2, Insightful

      I think you're confusing the single sign on presented here, which is an intra-enterprise sign-on, with universal single-sign on systems like Passport.

    4. Re:But are people comfortable with SSO! by slamb · · Score: 3, Insightful
      When are people going to realise that the problem with single sign on isn't a technical one....

      The biggest one I see is technical: there's no good single sign-on system designed for the Internet.

      Kerberos is the only widely implemented system I'm aware of that implements one key criterium: service providers can't use the credentials passed to them to log in to another service. With web-based single sign-on systems, the password you enter for webmail will also get you in to the billing system. So if the webmail system is compromised (and it's typically held to a much lower standard), so is the billing system. That's no good.[*]

      Kerberos isn't designed for the Internet. You need to set it up explicitly for each trust domain on each client computer. So users can't just pull out their personal laptops and use them to log in, unless you've instructed them on setting it up. And certainly not on whatever public computer they've run across.

      What we need is a single sign-on system with a different model. I think it would require:

      1. a cheap physical token that has public-key cryptography.
      2. a password entered directly into the token that you carry with you. You shouldn't have to trust the machine you're using to not capture your password. That model works for ATMs, but not for net cafes.
      3. no setup for each trust domain on each client machine. Presumably, it would authenticate the domain's keyserver using PKI. Either the existing system where you buy a certificate from Verisign on DNSsec.
      4. wide acceptance - the physical readers should be present on any random machine you stumble across, and so should supporting software.

      Certainly #2 and #3 are technical problems. #4 is not. #1 is arguable.

      [*] - Some web applications make some effort to avoid this problem. But they're not good enough. The University of Iowa has the HawkID system, which redirects all login requests to the hawkid one, and then back to the application. But you still enter the password into a web form given by the application, and there's no UI for seeing the destination of the form. When you enter it, you don't have a guarantee that the web application doesn't get the password. We need a new system just for authentication that makes potential security problems blindingly obvious.

    5. Re:But are people comfortable with SSO! by Anonymous Coward · · Score: 1, Insightful
      You started to say something interesting and useful, then your attention wandered. Inquiring minds want to know: if the problem with SSO isn't technical, what is it?

      No, he was never saying anything interesting. It's just a karma whore trick: state a bold conclusion some people will agree with. Don't provide an explanation. The people who agree will mentally fill in their own explanation where yours should be and mod up your post accordingly. No one else can say your argument is bad, because you haven't made one.

    6. Re:But are people comfortable with SSO! by hey! · · Score: 2, Insightful

      No, the original poster knows what he's talking about.

      The problem with an ATM card is that it is not cryptographically self contained. Because it has no processing power, it cannot computer message authenticators etc. on its own. Instead, it has to reveal its secrets to the machine it is inserted into so that machine can do the procedure for it. This is why the false front thing works. The card tells everything it knows.

      The poster is talking about something like an ibutton or smart card that has on-board computing power that can compute message digests etc. without using the computer it is connected to. That comptuer is just another part of the network so far as the device is concerned -- that is to say it is used to transmit the cryptographic proof that the transaction is authorized by the bearer without being privy to how that computation was performed.

      It would absolutely foil an attempt at password theft, although it possible that in such a system a man in the middle kind of attack could be performed, where the device told the user it was withdrawing $100 but it was withdrawing $500. Even that could potentially be addressed.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  2. AFS Coverage? by xlark · · Score: 4, Insightful

    Too bad there seems to be no coverage of AFS. I'd love to see a book documenting using Kerberos V with AFS.

  3. File that by mccrew · · Score: 4, Insightful
    I see OpenSSH as the best choice...

    File that one in the "When your only tool is a hammer everything looks like a nail" folder.

    --
    Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
  4. Re:OpenSSH ... by einhverfr · · Score: 3, Insightful

    I should not feed the trolls.... But oh well....

    OpenSSH is great for some things, but it does NOT do remote authentication for services, nor does it authenticate the service to the client. So it does not scale well.

    Kerberos scales better and is more secure than OpenSSH for most things, I think. You can even use it along with telnet to provide a single-sign on remote shell with an encrypted session (without the key management issues of OpenSSH). Of course you can also use OpenSSH with Kerberos (requires a patch I think) but then that negates your point.

    Also, it is *easy* to integrate Win2k and XP with Kerberos.

    --

    LedgerSMB: Open source Accounting/ERP
  5. Re:Bad editing by jayhawk88 · · Score: 2, Insightful

    I made a list of corrections that I sent to both O'Reilly and the author which were ignored.

    Perhaps the corrections you sent had already been caught by someone else (at O'Reilly or otherwise), only too late to fix before this publication, and will be corrected in any future publications. Granted I suppose a note of thanks from the author would have been nice, but what did you expect, Hallmark?

  6. Re:PKINIT by TheCabal · · Score: 2, Insightful

    Uh, Win2k's Kerberos implementation is suprisingly standards-compliant. I've had NO issues whatsoever getting my MIT Krb5 systems taking to Win2k and Win2k3 KDCs. Microsoft even has a simple step-by-step guide on how to export the account data to a Kerberos keytab. If your krb5.conf file is set up properly, it's less than 5 minutes to set up the user account, export the keytab and import it onto your system.

    Try harder.

  7. Re:OpenSSH ... by einhverfr · · Score: 3, Insightful


    If you store the keys you need to authenticate at other services in the .ssh directory of the server you log into first, then ssh authenticates you to other services..


    Not really. It authenticates you to *a user account* on the *host system.* This is very different from authenticating to, say, and LDAP service, an HTTPS application, or a database manager. OpenSSH cannot readily do this. Sure you can use it for mining expeditions (lots of tunnels) but this does not approach problem in a reasonable manner.

    Kerberos isn't particularly impressive at scaling, what with all those secret keys flying about.

    It seems to scale better than the alternatives. I assume that this is why Novell, IBM, and even Microsoft use it for their larger-scale AAA systems. The reason is simply central management. You could try to hack something together using LDAP and SSH but the same issues exist regarding the fact that it doesn't really have a way to authenticate you to a centrally managed account from an application server's perspective.

    Really, the only thing SSH doesn't do is authenticate the remote service to the extent that Kerberos would, although really the only benefit Kerberos brings is that it prevents some MITM attacks - it's still based on remote systems (working together) "proving" who they are by knowing a shared secret (your password).

    No, actually, it protects you against modified replay attacks. MITM is a problem which can occur with SSH, SSL, and even Kerberos on the first time a key for a PKI server is received. This can be a X509 CA, and SSH server, or a Kerberos KDC.

    OTOH, the fact that each ticket is signed and timestamped (and cached against playback), and each service (including the KDC) is authenticated to the client, there is no way to forge or replay the ticket unless the keys are compromised.

    I do agree with your points regarding PKI but I am not really sure that there is a secure way to do this. It is a difficult problem (i.e. login requires the key which either must be cashed and then decrypted with a passphrase or be carried on the person of the user). This has its own dangers and is far from being perfect.

    --

    LedgerSMB: Open source Accounting/ERP