UNIX System Administration Handbook - Evi Nemeth [397]
Kerberos uses DES to construct nested sets of credentials called “tickets.” Tickets are passed around the network to certify your identity and to provide you with access to network services. Each Kerberos site must maintain at least one physically secure machine (called the authentication server) to run the Kerberos daemon. This daemon issues tickets to users or services that request authentication based on credentials they provide, such as passwords.
In essence, Kerberos improves upon traditional UNIX password security in only two ways: it never transmits unencrypted passwords on the network, and it relieves users from having to type passwords repeatedly, making password protection of network services somewhat more palatable.
Kerberos has been around for a long time, and many vendors support it in their standard releases. Systems with “Kerberos stubs” come ready to work with Kerberos if you have already set up an authentication server. But just as buying a cable-ready television doesn’t get you HBO, you must still obtain a copy of Kerberos from an outside source if you are starting from scratch (look on web.mit.edu/kerberos).
Among our example systems, Solaris and HP-UX include Kerberos stubs, and FreeBSD provides the entire Kerberos system. Cisco’s routers provide some support as well, although it has been buggy in the past. Microsoft has announced extensive support for Kerberos in Windows 2000, but it remains to be seen exactly how they plan to use it and how compliant their implementation will be.
The Kerberos community boasts one of the most lucid and enjoyable documents ever written about a cryptosystem, Bill Bryant’s “Designing an Authentication System: a Dialogue in Four Scenes.” It’s required reading for anyone interested in cryptography and is available at
http://web.mit.edu/kerberos/www/dialogue.html
There’s also a good FAQ:
http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
Kerberos offers a better network security model than the “ignoring network security entirely” model. However, it is neither perfectly secure nor painless to install and run. It does not supersede any of the other security measures described in this chapter. In our opinion, most sites are better off without it. Good system hygiene and a focused cryptographic solution for remote logins such as SSH or SRP (see pages 672–674) should provide a more-than-adequate level of security for your users.
PGP: Pretty Good Privacy
Philip Zimmermann’s PGP package provides a tool chest of bread-and-butter cryptographic utilities focused primarily on email security. It can be used to encrypt data, to generate signatures, and to verify the origin of files and messages.
Attempts to regulate or stop the distribution of PGP have given it a rather checkered history. It now exists in several versions, including a set of commercial products from Network Associates (www.nai.com). A governmentally vetted version of PGP is a available for use in the United States, and an international version with somewhat stronger and more varied encryption is available from www.pgpi.org. The international archive sites do not seem to screen out U.S. addresses, so American users must be very careful not to accidentally go to www.pgpi.org and download the full-featured version of PGP.
PGP is the most popular cryptographic software in common use. Unfortunately, the UNIX version is nuts-and-bolts enough that you have to understand a fair amount of cryptographic background in order to use it. Fortunately (?), PGP comes with an 88-page treatise on cryptography that can help to set the stage. While you may find PGP useful in your own work, we don’t recommend that you support it for users, as it has been known to spark many puzzled questions. We have found the Windows version of PGP to be considerably easier to use than the UNIX pgp command with its 38 different