Chapter 7 SEAM Reference

This chapter lists many of the files, commands, and daemons that are part of the SEAM product. In addition, this chapter provides detailed information about how the Kerberos authentication system works.

This is a list of the reference information in this chapter.

• "SEAM Files"

• "SEAM Commands"

• "SEAM Daemons"

• "SEAM Terminology"

• "How the Authentication System Works"

• "Gaining Access to a Service Using SEAM"

• "Using the gsscred Table"

SEAM Files

PAM Configuration File

The default PAM configuration file delivered with SEAM includes entries to handle the new Kerberized applications. The new file includes entries for the authentication service, account management, session management, and password management modules.

For the authentication module, the new entries are for rlogin, login, dtlogin, krlogin, ktelnet, and krsh. An example of these entries is shown below. All of these services use the new PAM library, /usr/lib/security/pam_krb5.so.1, to provide Kerberos authentication.

The first three entries employ the try_first_pass option, which requests authentication using the user's initial password. Using the initial password means that the user is not prompted for another password even if multiple mechanisms are listed.

The next three entries use the acceptor option to prevent that PAM module from performing the step to obtain the initial ticket-granting ticket. For kerberized server applications, the exchange is already performed by the application so the step does not need to be done using PAM. In addition, an other entry is included as the default entry for all entries requiring authentication that are not specified.

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

For the account management, dtlogin has a new entry that uses the Kerberos library, as shown below. An other entry is included to provide a default rule. Currently no actions are taken by the other entry.

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

The last two entries in the /etc/pam.conf file are shown below. The other entry for session management destroys user credentials. The new other entry for password management selects the Kerberos library.

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM Commands

This section lists some of the commands included in the SEAM product.

Changes to the share Command

In addition to the new SEAM commands, the SEAM product includes changes to the share command that has been delivered for both the Solaris 2.6 and the Solaris 7 release. Three new security modes can be used by the share command:

krb5

Select Kerberos authentication

krb5i

Select Kerberos authentication with integrity

krb5p

Select Kerberos authentication with integrity and privacy

When multiple modes are included with the share command, the first mode listed is used by default if the client does not specify a security mode. Otherwise, the mode that the client selected is used.

If a mount request using a Kerberos mode fails, the mount completes using none as the security mode. This often occurs when the root principal on the NFS client is not authenticated. The mount request might succeed, but the user will be unable to access the files unless they are authenticated through Kerberos. Any transactions between the client and the server require Kerberos authentication, even if the file system is not mounted using a Kerberos security mode.

SEAM Daemons

The daemons that are used on the SEAM product are listed in the following table.

SEAM Terminology

The following section presents terms and their definitions that are used throughout the SEAM documentation. In order to follow many of the discussions, a understanding of these terms is essential.

Authentication-Specific Terminology

The terms discussed below are necessary for an understanding of the authentication process. Programmers and system administrators should be familiar with these terms.

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

The terms server and service are often used interchangeably. To make things clearer, 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, ftp or nfs). Documentation often mentions servers as part of a service, but using this definition clouds the meaning of the terms; therefore, servers refer to the physical system and service refers to the software.

The SEAM product includes three types of keys. One of them is the private key. This 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. This 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. This is a key 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 used to securely pass the identity of a user to a server or service. A ticket is good for only a single client and a particular service on a specific server. It contains the principal name of the service, the principal name of the user, the IP address of the user's host, a timestamp, 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 using either a private key or a service key depending on what will be decrypting 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 timestamp. Unlike a ticket, an authenticator can be used once only, usually when access to a service is requested. An authenticator is encrypted 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 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.) Compare a forwardable ticket to a proxiable ticket, below.

initial

An initial ticket is one 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 -- because 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. (See postdated, below.) It will be rejected by an application server until it becomes validated. To be validated, it 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 one that does not become valid until some specified time after its creation. Such a ticket is useful, for example, for batch jobs 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. (See invalid, above.) A postdated ticket is normally valid until the expiration time of the ticket-granting ticket; however, if it is marked renewable, its lifetime is normally set to be equal to the duration of the full life of the ticket-granting ticket. See renewable, below.

proxiable/proxy

At times it can be 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, it 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 ten hours. If the client 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 specified by the -l option of kinit, if kinit is used to get the ticket

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

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

• The maximum lifetime value specified in the Kerberos database for the user principal requesting the ticket.

Figure 7-1 shows how a TGT's lifetime is determined and illustrates where the four lifetime values come from. Even though Figure 7-1 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 providing the ticket provides a maximum lifetime value (instead of the krbtgt/realm principal).

Figure 7-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:

• The renewable lifetime value 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) specified in the kdc.conf file

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

• The maximum lifetime renewable value specified in the Kerberos database for the user principal requesting 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 of the principal names.

How the Authentication System Works

Applications allow you to log on to a remote system if you can provide a ticket that proves your identity and a matching session key. The session key contains information that is specific to the user and the service being accessed. A ticket and session key are created by the KDC for all users when they first log in. The ticket and matching session key form a credential. While using multiple networking services, a user can gather many credentials. The user needs to have a credential for each service running on a particular server. For instance, access to the ftp service on a server named boston requires one credential, and access to the ftp service on another server requires its own credential.

The process of creating and storing the credentials is transparent. Credentials are created by the KDC that sends the credential to the requestor. When received, the credential is stored in a credential cache.

Gaining Access to a Service Using SEAM

In order for a user to access a specific service on a specific server, the user must obtain two things. The first is a credential for the ticket-granting service (known as the TGT). Once the ticket-granting service has decrypted this credential, the service creates a second credential for the server that the user is requesting access to. This second credential can then be used to request access to the service on the server. After the server has successfully decrypted the second credential, then the user is given access. This process is described in more detail below.

Obtaining a Credential for the Ticket-Granting Service

1. To start the authentication process, the client sends a request to the authentication server for a specific user principal. This request is sent without encryption. There is no secure information included in the request, so it is not necessary to use encryption.

2. When the request is received by the authentication service, the principal name of the user is looked up in the KDC database. If a principal matches, the authentication service obtains the private key for that principal. The authentication service then generates a session key to be used by the client and the ticket-granting service (call it session key 1) and a ticket for the ticket-granting service (ticket 1). This ticket is also known as the ticket-granting ticket (TGT). Both the session key and the ticket are encrypted using the user's private key and the information is sent back to the client.

3. The client uses this information to decrypt session key 1 and ticket 1, using the private key for the user principal. Since the private key should only be known by the user and the KDC database, the information in the packet should be safe. The client stores the information in the credentials cache.

Normally during this a user is prompted for her password. If the password she enters is the same as the one used to build the private key stored in the KDC database, then the client can successfully decrypt the information sent by the authentication service. Now the client has a credential to be used with the ticket-granting service. The client is ready to request a credential for a server.

Figure 7-2 Obtaining a Credential for the Ticket-Granting Service

Obtaining a Credential for a Server

1. To request access to a specific server, a client must first have obtained a credential for that server from the authentication service (see "Obtaining a Credential for the Ticket-Granting Service"). The client then sends a request to the ticket-granting service, which includes the service principal name, ticket 1, and an authenticator encrypted with session key 1. Ticket 1 was originally encrypted by the authentication service using the service key of the ticket-granting service.

2. Because the service key of the ticket-granting service is known to the ticket-granting service, ticket 1 can be decrypted. The information included in ticket 1 includes session key 1, so the ticket-granting service can decrypt the authenticator. At this point, the user principal is authenticated with the ticket-granting service.

3. Once the authentication is successful, the ticket-granting service generates a session key for the user principal and the server (session key 2) and a ticket for the server (ticket 2). Session key 2 and ticket 2 are then encrypted using session key 1. Since session key 1 is known only to the client and the ticket-granting service, this information is secure and can be safely set over the net.

4. When the client receives this information packet, it decrypts the information using session key 1, which it had stored in the credential cache. The client has obtained a credential to be used with the server. Now the client is ready to request access to a particular service on that server.

Figure 7-3 Obtaining a Credential for a Server

Obtaining Access to a Specific Service

1. To request access to a specific service, the client must first have obtained a credential for the ticket-granting service from the authentication server, and a server credential from the ticket-granting service (see "Obtaining a Credential for the Ticket-Granting Service" and "Obtaining a Credential for a Server"). The client can send a request to the server including ticket 2 and another authenticator. The authenticator is encrypted using session key 2.

2. Ticket 2 was encrypted by the ticket-granting service with the service key for the service. Since the service key is known by the service principal, the service can decrypt ticket 2 and get session key 2. Session key 2 can then be used to decrypt the authenticator. If the authenticator is successfully decrypted, the client is given access to the service.

Figure 7-4 Obtaining Access to a Specific Service

Using the gsscred Table

The gsscred table is used by an NFS server when the server is trying to identify a SEAM user. The NFS services use UNIX IDs to identify users and these IDs are not part of a user principal or credential. The gsscred table provides a mapping from UNIX UIDs (from the password file) to principal names. The table must be created and administered after the KDC database is populated.

When a client request comes in, the NFS services try to map the principal name to a UNIX ID. If the mapping fails, the gsscred table is consulted. With the kerberos_v5 mechanism, a root/hostname principal is automatically mapped to UID 0, and the gsscred table is not consulted. This means that there is no way to do special remappings of root through the gsscred table.

Which Mechanism to Select for the gsscred Table

Choosing the correct mechanism for the gsscred table depends on several factors.

• Are you interested in improving the lookup time?

• Are you interested in increasing data access security?

• Do you need to build the file quickly?

This is a list of all of the back-end mechanisms that can be selected along with a description of advantages of the mechanism.

files

The gsscred table is stored on a file system. A local file system that is not shared provides the most secure back-end, since no transmissions are done over the net after the table is created. This version of the file builds the quickest.

xfn_files

The gsscred table is stored within the /var/fn file system. This file system can be shared or not. All xfn files take a long time to build.

xfn_nis

The gsscred table is stored within the NIS namespace. The lookups in this file system are not secure. All xfn files take a long time to build.

xfn_nisplus

The gsscred table is stored within the NIS+ namespace. The lookups in this file system are not secure. All xfn files take a long time to build.

xfn

The gsscred table is stored within the default system for xfn. All xfn files take a long time to build.

For the files back-end mechanism, the initial lookup can be slow. For the other mechanisms, the initial lookup can be faster using a name service. For all of the mechanisms, after the data is cached the retrieval time should be about the same.