Chapter 4 Using SEAM (Tasks)

This chapter is intended for anyone on a system with SEAM installed on it. This chapter explains how to use the "Kerberized" commands that are provided by SEAM: ftp, rcp, rlogin, rsh, and telnet. You should already be familiar with these commands (in their non-Kerberized versions) before you read about them here.

You'll find that the Kerberized and non-Kerberized versions are substantially the same. In many cases, you can use these commands without ever knowing or caring that they are Kerberized. The differences result from the features that take advantage of Kerberos (for example, the ability to forward a ticket when you use rlogin).

Because this chapter is intended for the general reader, it includes information on tickets: obtaining, viewing, and destroying them. This chapter also includes information on choosing or changing a Kerberos password.

This is a list of the information in this chapter:

• "Overview of Kerberized Commands"

• "Examples -- Using Kerberized Commands"

For an overview of SEAM, see Chapter 1, Introduction to SEAM.

SEAM Commands

Kerberos V5 is a single-sign-on system. This means that you only have to type your password once, and 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 the 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 the Kerberos command man pages for more detailed information.

Overview of Kerberized Commands

The Kerberized network services are those programs that connect to another machine somewhere on the Internet. These programs are located in /usr/krb5/bin; set your PATH variable so that these come before non-Kerberos versions. These programs are:

• ftp

• rcp

• rlogin

• rsh

• telnet

These programs have all of the original features of the corresponding non-Kerberos equivalents. They also have additional 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 allow you the options of:

• Forwarding your tickets to the another host (if you initially obtained forwardable tickets)

• Encrypting data transmitted between you and the remote host

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 man pages.

The following Kerberos options have been added to ftp, rcp, rlogin, rsh, and telnet:

-a

Attempt automatic login using your existing tickets. Uses the username as returned by getlogin(), unless this is different from the current user ID. (See the telnet(1) man page for details.)

-f

Forward a non-reforwardable ticket to a remote host. This option is mutually exclusive with the -F (see below); they cannot be used together in the same command.

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, if you want to rlogin to another machine and then rlogin 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 Kerberos V5; otherwise, you won't be able to access your home directory. (That is, suppose you initially log into System 1. From System 1 you rlogin into 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 SEAM configuration may differ in this respect.

For more on forwarding tickets, see "Forwarding Tickets with -f and -F".

-F

Forward a reforwardable copy of your ticket-granting ticket to a remote system. It is similar to -f (see above), 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 on forwarding tickets, see "Forwarding Tickets with -f and -F".

-k realm

Request tickets for the remote host in the specified realm, instead of determining the realm itself using the krb5.conf file.

-K

Use your tickets to authenticate to the remote host, but do not automatically log in.

-m mechanism

Specify the GSS-API security mechanism to use, as listed in the /etc/gss/mech file. Defaults to kerberos_v5.

-x

Encrypt this session.

-X auth_type

Disable the auth_type type of authentication.

Table 4-1, shows which commands have specific options (an "X" indicates that the command has that option).

Additionally, ftp allows the protection level for a session to be set at its prompt:

clear

Set the protection level to "clear" (no protection). This is the default.

private

Set the protection level to "private." Data transmissions are confidentiality- and integrity-protected by encryption. The privacy service may not be available to all SEAM users, however.

safe

Set the protection level to "safe." Data transmissions are integrity-protected by cryptographic checksum.

You can also set the protection level at the ftp prompt by entering protect followed by any of the protection levels shown above (clear, private, or safe).

Forwarding Tickets with -f and -F

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, rlogin to one machine and then rlogin from it to another. The -f option allows you to forward a ticket, while the -F option allows you to reforward a forwarded ticket.

In Figure 4-1, the user david obtains a non-forwardable ticket-granting ticket (TGT) with kinit. (It is non-forwardable because he did not specify the -f option.) In scenario 1, he is able to rlogin 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 which is non-forwardable.

Figure 4-1 Using Non-Forwardable Tickets

In actuality, SEAM configuration files are set up so that kinit obtains forwardable tickets by default. However, your configuration may differ. For the sake of explanation we have assumed 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 4-2, 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 4-2 Using Forwardable Tickets

Examples -- Using Kerberized Commands

The following examples give an idea of how the options to the Kerberized commands work.

Example -- 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 128.0.0.5... 
Connected to denver.example.com. Escape character is '^]'. 
[ Kerberos V5 accepts you as "david@eng.example.com" ] 
[ Kerberos V5 accepted forwarded credentials ] 
SunOS 5.7: Tue May 21 00:31:42 EDT 1998  Welcome to SunOS 
%

Notice that david's machine used Kerberos to authenticate him to denver.example.com, and logged him 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 were 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 -- 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 -F, and encrypts the session with -x. She chooses -F rather than -f because after she's 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 DES encryption for all transmissions.
Last login Mon May 19 15:19:49 from daffodil 
SunOS Release 5.7 (GENERIC) #2 Tue Nov 14 18:09:3 EST 1998 
%

Example -- Setting Protection Level in ftp

Now 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 this:

% 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.