SEAM Terminology

The following section presents terms and their definitions. Those terms are used throughout the SEAM documentation. In order to grasp SEAM concepts, an understanding of these terms is essential.

Kerberos-Specific Terminology

You need to understand the terms in this section in order to administer KDCs.

The Key Distribution Center or KDC is the component of SEAM that is responsible for issuing credentials. These credentials are created by using information that is stored in the KDC database. Each realm needs at least two KDCs, a master and at least one slave. All KDCs generate credentials, but only the master KDC handles any changes to the KDC database.

A stash file contains an encrypted copy of the master key for the KDC. This key is used when a server is rebooted to automatically authenticate the KDC before starting the kadmind and krb5kdc commands. Because this file includes the master key, the file and any backups of the file should be kept secure. If the encryption is compromised, then the key could be used to access or modify the KDC database.

Authentication-Specific Terminology

You need to know the terms in this section to understand the authentication process. Programmers and system administrators should be familiar with these terms.

A client is the software that runs on a user's workstation. The SEAM software that runs on the client makes many requests during this process. So, it is important to differentiate the actions of this software from the user.

The terms server and service are often used interchangeably. To clarify, the term server is used to define the physical system that SEAM software is running on. The term service corresponds to a particular function that is being supported on a server (for instance, nfs). Documentation often mentions servers as part of a service, but this definition clouds the meaning of the terms. Therefore, the term server refers to the physical system. The term service refers to the software.

The SEAM product includes three types of keys. One key is the private key. The private key is given to each user principal and is known only to the user of the principal and to the KDC. For user principals, the key is based on the user's password. For servers and services, the key is known as a service key. The service key serves the same purpose as the private key, but is used by servers and services. The third type of key is a session key. A session key is a key that is generated by the authentication service or the ticket-granting service. A session key is generated to provide secure transactions between a client and a service.

A ticket is an information packet that is used to securely pass the identity of a user to a server or service. A ticket is valid for only a single client and a particular service on a specific server. A ticket contains the principal name of the service, the principal name of the user, the IP address of the user's host, a time stamp, and a value to define the lifetime of the ticket. A ticket is created with a random session key to be used by the client and the service. After a ticket has been created, it can be reused until the ticket expires.

A credential is a packet of information that includes a ticket and a matching session key. Credentials are often encrypted by using either a private key or a service key, depending on which software decrypts the credential.

An authenticator is another type of information. When used with a ticket, an authenticator can be used to authenticate a user principal. An authenticator includes the principal name of the user, the IP address of the user's host, and a time stamp. Unlike a ticket, an authenticator can be used once only, usually when access to a service is requested. An authenticator is encrypted by using the session key for that client and that server.

Types of Tickets

Tickets have properties that govern how they can be used. These properties are assigned to the ticket when it is created, although you can modify a ticket's properties later. For example, a ticket can change from forwardable to forwarded. You can view ticket properties with the klist command. See How to View Tickets.

Tickets can be described by one or more of the following terms:

Forwardable/forwarded

A forwardable ticket can be sent from one host to another, obviating the need for a client to reauthenticate itself. For example, if the user david obtains a forwardable ticket while on user jennifer's machine, he can log in to his own machine without having to get a new ticket (and thus authenticate himself again). See Example—Creating a Ticket for an example of a forwardable ticket.

Initial

An initial ticket is a ticket that is issued directly, not based on a ticket-granting ticket. Some services, such as applications that change passwords, can require tickets to be marked initial in order to assure themselves that the client can demonstrate a knowledge of its secret key. An initial ticket indicates that the client has recently authenticated itself (instead of relying on a ticket-granting ticket, which might have been around for a long time).

Invalid

An invalid ticket is a postdated ticket that has not yet become usable. An invalid ticket will be rejected by an application server until it becomes validated. To be validated, a ticket must be presented to the KDC by the client in a TGS request, with the VALIDATE flag set, after its start time has passed.

Postdatable/postdated

A postdated ticket is a ticket that does not become valid until some specified time after its creation. Such a ticket is useful, for example, for batch jobs that are intended to be run late at night, since the ticket, if stolen, cannot be used until the batch job is to be run. When a postdated ticket is issued, it is issued as Invalid and remains that way until: its start time has passed, and the client requests validation by the KDC. A postdated ticket is normally valid until the expiration time of the ticket-granting ticket. However, if the ticket is marked renewable, its lifetime is normally set to be equal to the duration of the full life of the ticket-granting ticket.

Proxiable/proxy

At times, it is necessary for a principal to allow a service to perform an operation on its behalf. An example might be when a principal requests a service to run a print job on a third host. The service must be able to take on the identity of the client, but need only do so for that single operation. In that case, the server is said to be acting as a proxy for the client. The principal name of the proxy must be specified when the ticket is created.

A proxiable ticket is similar to a forwardable ticket, except that it is valid only for a single service, whereas a forwardable ticket grants the service the complete use of the client's identity. A forwardable ticket can therefore be thought of as a sort of super-proxy.

Renewable

Because it is a security risk to have tickets with very long lives, tickets can be designated as renewable. A renewable ticket has two expiration times: the time at which the current instance of the ticket expires, and the maximum lifetime for any ticket. If a client wants to continue to use a ticket, the client renews it before the first expiration occurs. For example, a ticket can be valid for one hour, with all tickets having a maximum lifetime of 10 hours. If the client that is holding the ticket wants to keep it for more than an hour, the client must renew it within that hour. When a ticket reaches the maximum ticket lifetime (10 hours), it automatically expires and cannot be renewed.

For information on how to view tickets to see what their attributes are, see How to View Tickets.

Ticket Lifetimes

Any time a principal obtains a ticket, including a ticket–granting ticket, the ticket's lifetime is set as the smallest of the following lifetime values:

• The lifetime value that is specified by the -l option of kinit, if kinit is used to get the ticket.

• The maximum lifetime value (max_life) that is specified in the kdc.conf file.

• The maximum lifetime value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm.

• The maximum lifetime value that is specified in the Kerberos database for the user principal that requests the ticket.

Figure 12–1 shows how a TGT's lifetime is determined and where the four lifetime values come from. Even though this figure shows how a TGT's lifetime is determined, basically the same thing happens when any principal obtains a ticket. The only differences are that kinit doesn't provide a lifetime value, and the service principal that provides the ticket provides a maximum lifetime value (instead of the krbtgt/realm principal).

Figure 12–1 How a TGT's Lifetime is Determined

The renewable ticket lifetime is also determined from the minimum of four values, but renewable lifetime values are used instead, as follows:

• The renewable lifetime value that is specified by the -r option of kinit, if kinit is used to obtain or renew the ticket.

• The maximum renewable lifetime value (max_renewable_life) that is specified in the kdc.conf file.

• The maximum lifetime renewable value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm.

• The maximum lifetime renewable value that is specified in the Kerberos database for the user principal that requests the ticket.

Principal Names

Each ticket is identified by a principal name. The principal name can identify a user or a service. Here are examples of several principal names.

Table 12–4 Examples of Principal Names

Principal Name	Description
root/boston.example.com@EXAMPLE.COM	A principal that is associated with the root account on an NFS client. This principal is called a root principal and is needed for authenticated NFS-mounting to succeed.
host/boston.example.com@EXAMPLE.COM	A principal that is used by the Kerberized applications (klist and kprop, for example). This principal is called a host or service principal.
username@EXAMPLE.COM	A principal for a user.
username/admin@EXAMPLE.COM	An admin principal that can be used to administer the KDC database.
nfs/boston.example.com@EXAMPLE.COM	A principal that is used by the NFS service. This principal can be used instead of a host principal.
K/M@EXAMPLE.COM	The master key name principal. There is one master key name principal that is associated with each master KDC.
kadmin/history@EXAMPLE.COM	A principal which includes a key used to keep password histories for other principals. Each master KDC has one of these principals.
kadmin/kdc1.example.com@EXAMPLE.COM	A principal for the master KDC server that allows access to the KDC by using kadmind.
changepw/kdc1.example.com@EXAMPLE.COM	A principal for the master KDC server that allows access to the KDC when you are changing passwords.
krbtgt/EXAMPLE.COM@EXAMPLE.COM	This principal is used when you generate a ticket-granting ticket.