pSeries or RS/6000 nodes that have network connections to the SP system.
This section provides detailed conceptual information regarding Kerberos V4. Some of the information might also apply, in a general sense, to DCE and Kerberos V5. For conceptual information regarding DCE specifically, see the appropriate DCE documentation.
Kerberos V4 uses a server to achieve mutual authentication between a client and a server in a client-server environment.
In general, Kerberos V4 consists of systems, objects, tickets, and keys.
The systems that make up a Kerberos V4 environment include a:
The objects that make up the Kerberos V4 environment include principals, instances, realms, tickets, and keys:
Kerberos V4 principals are either users who use authentication services to
run the Kerberos V4-authenticated applications supplied with the SP system or
the individual instances of the servers that run on SP nodes, the control
workstation, and on other |IBM pSeries or RS/6000 nodes that have network connections to the SP system.
User Principals for SP System Management - An implementation of the SP system must have at least one user principal defined. This user is the authentication database administrator, who must be defined first so that other principals can be added later. When AFS authentication servers are being used, the AFS administrator ID already exists when the SP authentication services are initialized. When PSSP authentication servers are being used, one of the steps included in setting up the authentication services is the creation of a principal whose identifier includes the admin instance. It is suggested, but not essential, that the first authentication administrator also be the root user. Various installation tasks performed by root, or other users with UID 0, require the Kerberos V4 authority to add service principals to the authentication database. At sometime prior to invoking the setup_server command to complete setup of the control workstation and boot server nodes, a user with UID 0 must be defined as a Kerberos V4 database administrator with authority to add other principals. This is because the service principals used by Kerberos V4-authenticated applications are all defined automatically by setup_server during installation and customization. Apart from this installation requirement, you may use other user principal identities to perform system administration (and authentication administration) tasks.
Service Principals Used by PSSP Components - Two service names are used by the Kerberos V4-authenticated applications in an SP system:
By convention, a Kerberos V4 server runs as a Kerberos V4 principal whose identifier is formed from the service name and the short host name of the node on which the server runs, converted to lowercase. Different principal identifiers thus indicate the target network address of the different providers of each service. The authentication support in the SP system expands the Kerberos V4 implementation to support workstations with multiple network interfaces as servers. This provides instances for all network interfaces rather than just the standard host name. Kerberos V4 works with the resolved network names, rather than any aliases you might use locally on your hosts.
The hardmon daemon runs only on the control workstation.
The SP logging daemon, splogd, can run on other |IBM pSeries or RS/6000 nodes. Therefore, for each (short) network interface name on these
workstations, a service principal is created with the name hardmon
and the network name as the instance.
The remote commands can be run from, or to, any |IBM pSeries or RS/6000 host on which the SP system authenticated client services
(ssp.clients) are |installed, unless the restricted root access option of PSSP is
|enabled. Therefore, for each (short) network interface name on all SP nodes,
the control workstation, and other client systems, a service principal is
created with the name rcmd and the network name as the
instance.
Instances can be on a client machine or on a server machine. An instance on a client machine is defined as the level of authorization the principal user has. An instance on a server machine is defined as the hostname of the server machine. Kerberos V4 uses the following notation to refer to principals and instances:
principal.instance
The authentication realm is the set of systems that is served by a single
logical authentication database. A realm can include any combination of
one or more SP systems, |IBM pSeries or RS/6000 nodes, and other systems or workstations. The authentication
database for a realm is administered as a single entity: principals are
defined across the systems within a realm and principal identifiers must be
unique within a realm.
There are options for defining authentication realms within a network of systems:
Generally, systems that are administered together, or by the same set of administrators, should be grouped into a single authentication realm. For example, one or more SP systems and their associated workstations could form a single authentication realm. Within an SP system, all SP nodes are automatically added to the control workstation's local realm during installation.
If multiple realms are configured within a network, the realm names should be unique. During setup of the SP authentication services, the name of the realm defaults to the local system's network domain name converted to uppercase. If a different realm name is going to be used, the local system's realm name must be supplied by the administrator in the /etc/krb.conf file. For information on the format of this file, see the PSSP: Command and Technical Reference.
If you are using AFS authentication servers, the entire SP system must be in the same cell. The authentication realm known to the SP authentication services is the local AFS cell. The realm name is set to the AFS cell name converted to uppercase.
Although a realm is served by a single logical authentication database, multiple copies of the database may exist on different workstations within a realm. One must be the primary database in a realm; others are secondary servers.
Kerberos V4 tickets are encrypted byte strings returned to clients by an authentication server. Tickets contain the client principal's identifier, a time-stamp and ticket lifetime used to determine the expiration time, the session key, and other information, all encrypted in the private key of the service instance with whom the client wishes to authenticate. The client cannot understand the key; it simply forwards it to the service with an authenticator in an internet protocol packet, using either UDP or TCP socket communications. In the case of a ticket-granting-ticket, that service is the Ticket Granting Service provided by the kerberos daemon. Other tickets are service-tickets, encrypted in the private key of one particular instance of an application service.
Obtained by the k4init or rcmdtgt command, which saves it by creating the current ticket cache file, over-writing one that already exists. As long as the current ticket cache file contains an unexpired ticket-granting-ticket, the owner of the file can invoke application client programs that require Kerberos V4 credentials.
Obtained by an application client, such as the sysctl command, which adds it to the current ticket cache file. As long as the current ticket cache file contains an unexpired ticket for a particular service instance, it can be used by any process that runs under the UID of the file owner to submit requests to that service instance.
The caching of tickets takes place automatically in disk files on the client system that is the workstation or SP node on which the client user is logged in. These files are created with UNIX permissions set so they can be accessed only by the owner, for they contain sensitive information. Any process using the tickets can authenticate as the owner of the file.
A user can have tickets cached in any number of files simultaneously, and may have reason to do so. If you have multiple logins, run background processes, or use a shared UID, you must do so to avoid destruction of tickets still in use by other processes. This is accomplished by setting the KRBTKFILE environment variable to the path name of a unique ticket cache file prior to using authentication services for each login session or background process. If you do not set KRBTKFILE, then your tickets will be cached in your default file: /tmp/tktuid.
The first ticket stored in the file is always the ticket-granting-ticket. The file is created by the k4init, ksrvtgt, or rcmdtgt command; and when the TGT is stored, all previously issued tickets in the file are deleted. The file contains, in addition to the TGT, any number of other tickets for application services. There will be one for each service instance with which you have communicated using that particular current ticket cache file. They are obtained by the client commands for the various Kerberos V4-authenticated services, such as rcp and rsh (and indirectly by SP system administration tools that invoke them).
Kerberos V4 does not automatically delete tickets after they expire. Users must either explicitly destroy their ticket cache files or replace them by re-authenticating (by obtaining a fresh TGT). Tickets are never removed individually from the ticket cache file. The k4destroy command eliminates the entire current ticket cache file. Ticket cache files other than the current file are untouched, however.
The tickets that you obtain when you issue the k4init command are valid only for a limited time. The same limit applies also to service tickets obtained by client programs that you execute. In most circumstances, you probably will not be concerned about how this limit is determined and applied. However, when you run k4init, you have the option of requesting a ticket with a specific lifetime. The maximum lifetime you may specify, which is also the default value, was assigned when your principal was registered in the authentication database, or it was changed subsequently by the database administrator. The minimum ticket lifetime is five minutes; the maximum lifetime can be set to one of several discrete values from five minutes to thirty days. The ticket lifetimes of service tickets are always the same as the lifetime of the ticket-granting-ticket used to obtain them. It is the TGT held in the current ticket cache file owned by the user who invokes the application client command.
The external representation of the ticket lifetime is rather inconsistent among the various user and administrator commands. Some commands represent the one-byte ticket lifetime value as a decimal integer between 0 and 255. This is the representation used by the administrator when creating or modifying a principal using the kdb_edit command. It is also the format of the ticket life field displayed by the get subcommand of kadmin. The output of the k4list command shows the actual ticket creation and expiration as standard date and time stamps. If you specify -l to request a specific ticket lifetime when you run k4init, you are prompted to enter the value as a number of minutes. The value you enter is then rounded up to the next higher discrete lifetime interval or the maximum ticket lifetime allowed for your principal, whichever is less, and then mapped to a one-byte value between 1 and 191.
The following table shows the ticket lifetimes that correspond to the encoding used internally by Kerberos V4. The values on the left of each column are the one-byte encoding; on the right, the lifetime interval in days, hours, and minutes.
Ticket lifetimes from 0 to 128 represent multiples of 5 minutes, for example:
0-1 00:05 12 01:00 24 02:00 36 03:00 48 04:00 60 05:00 72 06:00 84 07:00 96 08:00 108 09:00 120 10:00 125 10:25 126 10:30 127 10:35 128 10:40
Lifetimes from 129 to 255 represent intervals of from 11:24 to 30 days:
129 11:24 130 12:11 131 13:02 132 13:56 133 14:54 134 15:55 135 17:01 136 18:12 137 19:28 138 20:48 139 22:15 140 23:47 141 1d+01:26 142 1d+03:11 143 1d+05:04 144 1d+07:05 145 1d+09:14 146 1d+11:32 147 1d+13:59 148 1d+16:37 149 1d+19:25 150 1d+22:26 151 2d+01:38 152 2d+05:04 153 2d+08:44 154 2d+12:40 155 2d+16:51 156 2d+21:21 157 3d+02:08 158 3d+07:16 159 3d+12:45 160 3d+18:36 161 4d+00:52 162 4d+07:34 163 4d+14:44 164 4d+22:23 165 5d+06:35 166 5d+15:20 167 6d+00:41 168 6d+10:42 169 6d+21:23 170 7d+08:50 171 7d+21:03 172 8d+10:08 173 9d+00:06 174 9d+15:03 175 10d+07:01 176 11d+00:06 177 11d+18:22 178 12d+13:53 179 13d+10:46 180 14d+09:05 181 15d+08:56 182 16d+10:27 183 17d+13:44 184 18d+18:53 185 20d+02:04 186 21d+11:24 187 22d+23:02 188 24d+13:08 189 26d+05:52 190 28d+01:26 191+ 30d
Keys are another Kerberos V4 component. They are similar to passwords in that they are used for encrypting the tickets being sent back and forth between the client and server machines. Kerberos V4 authentication explains how keys are used in the authentication process.
When this method is active, SP authentication is based on the Kerberos V4 authentication service developed at MIT. SP trusted services use the Kerberos V4 authentication database and server to:
Kerberos V4 servers function as a trusted third party to authenticate the identities of users and distribute encryption keys to clients and servers, known as principals. Every user and every service instance on a particular host is a principal in the Kerberos V4 database. Each Kerberos V4 principal has an identifier, a password, an expiration date, and a maximum ticket lifetime registered in the authentication database. Kerberos V4 does not store the clear-text password, but a 64-bit binary value derived from it using a one-way hash. Database information is also encrypted in the Kerberos V4 master key, known only to the database administrator. Passwords are never sent across the network in clear-text form, neither for user authentication nor during database administration.
On the authentication server system there are two daemons that access the database. The kadmind daemon provides network access for database administration via the kpasswd and kadmin commands. The kerberos daemon is the actual authentication server. It is sometimes referred to as the "Key Distribution Center (KDC)" because of its role in distributing session keys. The KDC actually consists of two separate functions: the Authentication Service, which generates ticket-granting-tickets based on authentication using the client user's private key; and the Ticket Granting Service (TGS), which generates service tickets, based on authentication using a ticket-granting-ticket.
The underlying method for accomplishing the authentication is a ticket scheme, consisting of the following steps, illustrated in Figure 1.
Figure 1. An overview of Kerberos V4 authentication
View figure.
The scenario outlined previously assumes no unexpired service ticket was found in the ticket cache file. The ticket-granting-ticket can be used to get as many different tickets as are needed, without requiring the user to reenter the password.
A client's service ticket can be used to re-authenticate as often as the client and server require. Typically, clients using TCP/IP authenticate once on connection to the server. Users of connectionless protocol should authenticate each message exchange, though less rigorous schemes can be used following an initial authentication, by using the shared session key to encrypt a small piece of known data.
The authentication services use the Data Encryption Standard (DES) algorithm. The DES algorithm is used only as an internal method for authenticating the identities of clients and servers. You might need to be aware that in order to comply with U.S. export regulations on the DES algorithm, SP authentication services provide a subset of the full MIT Kerberos V4 services. No interface is provided for using the encryption routines directly. No interface is provided to allow the encryption of any portion of service messages that are not directly connected with the authentication of the client and server identities.
For additional information, see the Kerberos man page in the PSSP: Command and Technical Reference.
AFS is a distributed file system developed by Transarc Corporation. AFS includes an authentication implementation that is based on Kerberos V4. Therefore, AFS authentication servers can be used in place of SP authentication servers to provide credentials for SP Kerberos V4 principals.
Although AFS and SP Kerberos V4 authentication services can work together, there are differences in the way the authentication database is administered (for example, adding principals and changing passwords).
AFS uses a different set of servers, protocols, interfaces, and commands for Kerberos V4 database administration.
The primary tasks the system administrator performs in administering AFS authentication services are:
The AFS system has its own administration commands and utilities for the administrator user. These commands and utilities provide for authentication, protection of files, file manipulation, and backup services. The following commands and utilities are relevant for administering authentication services. See the AFS documentation for more information.
The following SP authentication service commands work in an AFS authentication system:
The SP authentication services provide only the interfaces from the SP System to work in an AFS authentication system. The SP authentication services do not supply any of the AFS executables.
The AFS system provides multiple daemons that are activated on AFS server machines and support authentication tasks:
The authentication services work primarily with the kaserver and the ptserver. The kaserver allows the administrator to execute various commands to administer the authentication database. The admin user can enter kas help to view the commands available. The admin user needs to provide a password when using the kas command.
The ptserver protects and maintains system entries that are stored in the authentication database. The admin user can enter pts help to view the commands available. The admin user needs to provide a password when using the pts command. The admin user needs to create an AFS token (klog.krb) when working with the pts command.
See AFS documentation for information on installing and administering the AFS system.