Managing NFS and NIS, 2nd Edition - Mike Eisler [165]
Solaris (2.6, 7, and 8) was the only known Unix operating system offering an NFS implementation that supported Kerberos V5 security.
At least two PC/NFS implementations—Hummingbird's Maestro, and Netmanage's Interdrive—supported Kerberos V5 security.
Kerberos V5
The Kerberos V5 system was developed at the Massachusetts Institute of Technology. It is another mechanism for enforcing security within a service, but it differs from RPC/DH in several ways:
Kerberos uses multiple levels of DES encryption to exchange keys and passwords. No public key encryption is used.
A Key Distribution Center (KDC ) is required to maintain Kerberos V5 service passwords; this server must be kept safe from attack to preserve the integrity of the Kerberos system. RPC/DH uses the publickey map, which is available to all NIS clients. The data in the publickey map is encrypted using user's login passwords, not an additional RPC/DH password.
Kerberos V5 authentication is built into the entire service, or application, not just into the session layer. For example, you can use Kerberos to make the line printer spooling daemon secure. Doing so, however, requires the source code to the line printer software.
Kerberos V5 has the notion of forwardable credentials. Think back to earlier in this chapter (see Section 12.5.4.8) when we talked about rlogin, transparent access, and the fact that when using NFS/dh, you still had to provide a password to keylogin even though (or rather, because) rlogin didn't prompt for one. Kerberos V5 has replacements for programs like rlogin and telnet that work like that which they replace, but also support some extra features: Kerberos V5 is used to authenticate the user, not passwords.
Traffic between the client and server is optionally encrypted as a way to provide privacy protection.
Credentials can be forwarded from the client to the server. This feature, known as a forwardable ticket granting ticket, allows the following sequence of events: The user logs into his desktop machine. He is prompted for his Unix login password, which also happens to be his Kerberos V5 password. This results in a ticket granting ticket (TGT) being sent from the KDC to his desktop. His home directory is NFS-mounted but exported with Kerberos V5 security (sec=krb5).
The NFS filesystem uses the TGT to get an NFS service ticket from the KDC, which allows the user to be authenticated to the NFS server. The service ticket is encrypted with the NFS server's key, which both the KDC and the NFS server know about. The NFS server can decrypt the service ticket from the client because the server stores the server's key in its /etc/krb5/krb5.keytab file, which is analogous to RPC/DH's /etc/.rootkey file.
The user now wishes to log onto a remote system. He uses a Kerberized version of rlogin to do so, passing a command-line option that indicates that he wants his TGT to be forwarded.
The NFS filesystem on the remote system must do an NFS mount of the user's home directory, which is still exported with sec=krb5. It needs an NFS service ticket to authenticate the user to the NFS server. Because the TGT has been forwarded, no password prompt to the user is necessary.
Thus the user, having authenticated himself once when he logged into his desktop, can roam freely and securely among the network, as he did in the days when the network was using simple host-based trust for rlogin and NFS.
SEAM: Kerberos V5 for Solaris
Sun's Kerberos V5 implementation is called Sun Enterprise Authentication Mechanism (SEAM).
For this chapter to completely explain how to set up SEAM for running Kerberos V5 and NFS secured with Kerberos V5, it would have to include as much material as was written in this chapter about NIS and NFS/dh, and all the chapters leading up to it. In other words, the title of this book would be Managing NIS, Kerberos V5, and NFS. Fortunately, the SEAM documentation is well-written, and the installation fairly turnkey.[6] Thus it is not clear that much value could be added in this book