Kerberos V5 product is a single-sign-on system, which means that you only have to type your password once. The Kerberos V5 programs do the authenticating (and optional encrypting) for you, because Kerberos has been built into each of a suite of existing, familiar network programs. The Kerberos V5 applications are versions of existing UNIX network programs with Kerberos features added.
For example, when you use a Kerberized program to connect to a remote host, the program, the KDC, and the remote host perform a set of rapid negotiations. When these negotiations are completed, your program has proven your identity on your behalf to the remote host, and the remote host has granted you access.
Note that Kerberized commands try to authenticate with Kerberos first. If Kerberos authentication fails, an error occurs or UNIX authentication is attempted, depending on what options were used with the command. Refer to the Kerberos Security section in each Kerberos command man page for more detailed information.
The Kerberized network services are programs that connect to another machine somewhere on the Internet. These programs are the following:
These programs have features that transparently use your Kerberos tickets for negotiating authentication and optional encryption with the remote host. In most cases, you'll notice only that you no longer have to type your password to use them, because Kerberos will provide proof of your identity for you.
The Kerberos V5 network programs include options that enable you to do the following:
Forward your tickets to the another host (if you initially obtained forwardable tickets).
Encrypt data transmitted between you and the remote host.
Note - This section assumes you are already familiar with the non-Kerberos versions of these programs, and highlights the Kerberos functionality added by the Kerberos V5 package. For detailed descriptions of the commands described here, see their respective man pages.
You'll want to forward a ticket if you have reason to believe you'll need to authenticate yourself to other Kerberos-based services on a third host. For example, you might want to remotely log in to another machine and then remotely log in from it to a third machine.
You should definitely use a forwardable ticket if your home directory on the remote host is NFS-mounted using the Kerberos V5 mechanism. Otherwise, you won't be able to access your home directory. That is, suppose you initially log in to System 1. From System 1, you remotely log in to your home machine, System 2, which mounts your home directory from System 3. Unless you've used the -f or -F option with rlogin, you won't be able to get to your home directory because your ticket can't be forwarded to System 3.
By default, kinit obtains forwardable ticket-granting tickets (TGTs). However, your configuration might differ in this respect.
For more information on forwarding tickets, see Forwarding Kerberos Tickets.
Forwards a reforwardable copy of your TGT to a remote system. It is similar to -f, but it allows for access to a further (say, fourth or fifth) machine. The -F option can therefore be regarded as being a superset of the -f option. The -F option is mutually exclusive with the -f option. They cannot be used together in the same command.
For more information on forwarding tickets, see Forwarding Kerberos Tickets.
Table 26-1 Kerberos Options for Network Commands
Sets the protection level to “private.” Data transmissions are confidentiality-protected and integrity-protected by encryption. The privacy service might not be available to all Kerberos users, however.
You can also set the protection level at the ftp prompt by typing protect followed by any of the protection levels shown above (clear, private, or safe).
As described in Overview of Kerberized Commands, some commands allow you to forward tickets with either the -f or -F option. Forwarding tickets allows you to “chain” your network transactions. You can, for example, remotely log in to one machine and then remotely log in from it to another machine. The -f option allows you to forward a ticket, while the -F option allows you to reforward a forwarded ticket.
In Figure 26-2, the user david obtains a non-forwardable ticket-granting ticket (TGT) with kinit. The ticket is non-forwardable because he did not specify the -f option. In scenario 1, he is able to remotely log in to machine B, but he can go no further. In scenario 2, the rlogin -f command fails because he is attempting to forward a ticket that is non-forwardable.
Figure 26-2 Using Non-Forwardable Tickets
In actuality, Kerberos configuration files are set up so that kinit obtains forwardable tickets by default. However, your configuration might differ. For the sake of explanation, assume that kinit does not obtain forwardable TGTs unless it is invoked with kinit -f. Notice, by the way, that kinit does not have a -F option. TGTs are either forwardable or not.
In Figure 26-3, the user david obtains forwardable TGTs with kinit -f. In scenario 3, he is able to reach machine C because he uses a forwardable ticket with rlogin. In scenario 4, the second rlogin fails because the ticket is not reforwardable. By using the -F option instead, as in scenario 5, the second rlogin succeeds and the ticket can be reforwarded on to machine D.
Figure 26-3 Using Forwardable Tickets
The following examples show how the options to the Kerberized commands work.
Example 26-5 Using the -a, -f, and -x Options With telnet
In this example, the user david has already logged in, and wants to telnet to the machine denver.example.com. He uses the -f option to forward his existing tickets, the -x option to encrypt the session, and the -a option to perform the login automatically. Because he does not plan to use the services of a third host, he can use -f instead of -F.
% telnet -a -f -x denver.example.com Trying 18.104.22.168... Connected to denver.example.com. Escape character is '^]'. [ Kerberos V5 accepts you as "firstname.lastname@example.org" ] [ Kerberos V5 accepted forwarded credentials ] SunOS 5.9: Tue May 21 00:31:42 EDT 2004 Welcome to SunOS %
Notice that david's machine used Kerberos to authenticate him to denver.example.com, and logged him in automatically as himself. He had an encrypted session, a copy of his tickets already waiting for him, and he never had to type his password. If he had used a non-Kerberos version of telnet, he would have been prompted for his password, and it would have been sent over the network unencrypted. If an intruder had been watching network traffic at the time, the intruder would have known david's password.
If you forward your Kerberos tickets, telnet (as well as the other commands discussed here) destroys them when it exits.
Example 26-6 Using rlogin With the -F Option
Here, the user jennifer wants to log in to her own machine, boston.example.com. She forwards her existing tickets with the -F option, and encrypts the session with the -x option. She chooses -F rather than -f because after she is logged in to boston, she might want to perform other network transactions requiring tickets to be reforwarded. Also, because she is forwarding her existing tickets, she does not have to type her password.
% rlogin boston.example.com -F -x This rlogin session is using encryption for all transmissions. Last login Mon May 19 15:19:49 from daffodil SunOS Release 5.9 (GENERIC) #2 Tue Nov 14 18:09:3 EST 2003 %
Example 26-7 Setting the Protection Level in ftp
Suppose that joe wants to use ftp to get his mail from the directory ~joe/MAIL from the machine denver.example.com, encrypting the session. The exchange would look like the following:
% ftp -f denver.example.com Connected to denver.example.com 220 denver.example.org FTP server (Version 6.0) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI authentication succeeded Name (daffodil.example.org:joe) 232 GSSAPI user joe@MELPOMENE.EXAMPLE.COM is authorized as joe 230 User joe logged in. Remote system type is UNIX. Using BINARY mode to transfer files. ftp> protect private 200 Protection level set to Private ftp> cd ~joe/MAIL 250 CWD command successful. ftp> get RMAIL 227 Entering Passive Mode (128,0,0,5,16,49) 150 Opening BINARY mode data connection for RMAIL (158336 bytes). 226 Transfer complete. 158336 bytes received in 1.9 seconds (1.4e+02 Kbytes/s) ftp> quit %
To encrypt the session, joe sets the protection level to private.