Chapter 7 Introduction to SEAM

This chapter provides an introduction to Sun Enterprise Authentication Mechanism (SEAM).

• What Is SEAM?

• How SEAM Works

• SEAM Security Services

• SEAM Releases

What Is SEAM?

SEAM is a client/server architecture that provides secure transactions over networks. SEAM offers strong user authentication, as well as data integrity and data privacy. Authentication guarantees that the identities of both the sender and the recipient of a network transaction are true. SEAM can also verify the validity of data being passed back and forth (integrity) and encrypt the data during transmission (privacy). Using SEAM, you can log on to other machines, execute commands, exchange data, and transfer files securely. Additionally, SEAM provides authorization services, which allows administrators to restrict access to services and machines. Moreover, as a SEAM user, you can regulate other people's access to your account.

SEAM is a single-sign-on system, which means that you only need to authenticate yourself to SEAM once per session, and all subsequent transactions during the session are automatically secured. After SEAM has authenticated you, you do not need to authenticate yourself every time you use a SEAM-based command such as kinit or klist, or access data on an NFS file system. Thus, you do not have to send your password over the network, where it can be intercepted, each time you use these services.

SEAM is based on the Kerberos V5 network authentication protocol that was developed at the Massachusetts Institute of Technology (MIT). People who have used Kerberos V5 should therefore find SEAM very familiar. Since Kerberos V5 is a de facto industry standard for network security, SEAM promotes interoperability with other systems. In other words, because SEAM works with systems that use Kerberos V5, it allows for secure transactions even over heterogeneous networks. Moreover, SEAM provides authentication and security both between domains and within a single domain.

---

Note –

Because SEAM is based on, and designed to interoperate with, Kerberos V5, this manual often uses the terms “Kerberos” and “SEAM” more or less interchangeably, for example, “Kerberos realm” or “SEAM-based utility.” Moreover, “Kerberos” and “Kerberos V5” are used interchangeably. The manual draws distinctions when necessary.

---

SEAM allows for flexibility in running Solaris applications. You can configure SEAM to allow both SEAM-based and non-SEAM-based requests for network services such as the NFS service. As a result, current Solaris applications still work even if they are running on systems on which SEAM is not installed. Of course, you can also configure SEAM to allow only SEAM-based network requests.

Additionally, applications do not have to remain committed to SEAM if other security mechanisms are developed. Because SEAM is designed to integrate modularly into the Generic Security Service (GSS) API, applications that make use of the GSS-API can utilize whichever security mechanism best suits its needs.

How SEAM Works

The following is an overview of the SEAM authentication system. For a more detailed description, see How the Authentication System Works.

From the user's standpoint, SEAM is mostly invisible after the SEAM session has been started. Initializing a SEAM session often involves no more than logging in and providing a Kerberos password.

The SEAM system revolves around the concept of a ticket. A ticket is a set of electronic information that serves as identification for a user or a service such as the NFS service. Just as your driver's license identifies you and indicates what driving permissions you have, so a ticket identifies you and your network access privileges. When you perform a SEAM-based transaction (for example, if you rlogin in to another machine), you transparently send a request for a ticket to a Key Distribution Center, or KDC. The KDC accesses a database to authenticate your identity and returns a ticket that grants you permission to access the other machine. “Transparently” means that you do not need to explicitly request a ticket.

Tickets have certain attributes associated with them. For example, a ticket can be forwardable (which means that it can be used on another machine without a new authentication process), or postdated (not valid until a specified time). How tickets are used (for example, which users are allowed to obtain which types of ticket) is set by policies that are determined when SEAM is installed or administered.

---

Note –

You will frequently see the terms credential and ticket. In the greater Kerberos world, they are often used interchangeably. Technically, however, a credential is a ticket plus the session key for that session. This difference is explained in more detail in Gaining Access to a Service Using SEAM.

---

The following sections further explain the SEAM authentication process.

Initial Authentication: the Ticket-Granting Ticket

Kerberos authentication has two phases: an initial authentication that allows for all subsequent authentications, and the subsequent authentications themselves.

The following figure shows how the initial authentication takes place.

Figure 7–1 Initial Authentication for SEAM Session

1. A client (a user, or a service such as NFS) begins a SEAM session by requesting a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). This request is often done automatically at login.

   A ticket-granting ticket is needed to obtain other tickets for specific services. Think of the ticket-granting ticket as similar to a passport. Like a passport, the ticket-granting ticket identifies you and allows you to obtain numerous “visas,” where the “visas” (tickets) are not for foreign countries but for remote machines or network services. Like passports and visas, the ticket-granting ticket and the other various tickets have limited lifetimes. The difference is that “Kerberized” commands notice that you have a passport and obtain the visas for you. You don't have to perform the transactions yourself.

2. The KDC creates a ticket–granting ticket and sends it back, in encrypted form, to the client. The client decrypts the ticket-granting ticket by using the client's password.

3. Now in possession of a valid ticket-granting ticket, the client can request tickets for all sorts of network operations for as long as the ticket-granting ticket lasts. This ticket usually lasts for a few hours. Each time the client performs a unique network operation, it requests a ticket for that operation from the KDC.

Subsequent Authentications

After the client has received the initial authentication, each individual authentication follows the pattern that is shown in the following figure.

Figure 7–2 Obtaining Access to a Service

1. The client requests a ticket for a particular service from the KDC by sending the KDC its ticket-granting ticket as proof of identity.

2. The KDC sends the ticket for the specific service to the client.

   For example, suppose user joe wants to access an NFS file system that has been shared with krb5 authentication required. Since he is already authenticated (that is, he already has a ticket-granting ticket), as he attempts to access the files, the NFS client system automatically and transparently obtains a ticket from the KDC for the NFS service.

3. The client sends the ticket to the server.

   When using the NFS service, the NFS client automatically and transparently sends the ticket for the NFS service to the NFS server.

4. The server allows the client access.

These steps make it appear that the server doesn't ever communicate with the KDC. The server does, though; it registers itself with the KDC, just as the first client does. For simplicity's sake, we have left that part out.

Principals

A client in SEAM is identified by its principal. A principal is a unique identity to which the KDC can assign tickets. A principal can be a user, such as joe, or a service, such as nfs.

By convention, a principal name is divided into three parts: the primary, the instance, and the realm. A typical SEAM principal would be, for example, joe/admin@ENG.EXAMPLE.COM, where:

• joe is the primary. The primary can be a user name, as shown here, or a service, such as nfs. The primary can also be the word host, which signifies that this principal is a service principal that is set up to provide various network services.

• admin is the instance. An instance is optional in the case of user principals, but it is required for service principals. For example: if the user joe sometimes acts as a system administrator, he can use joe/admin to distinguish himself from his usual user identity. Likewise, if joe has accounts on two different hosts, he can use two principal names with different instances (for example, joe/denver.example.com and joe/boston.example.com). Notice that SEAM treats joe and joe/admin as two completely different principals.

  In the case of a service principal, the instance is the fully qualified host name. bigmachine.eng.example.com is an example of such an instance so that the primary/instance might be, for example, host/bigmachine.eng.example.com.

• ENG.EXAMPLE.COM is the SEAM realm. Realms are discussed in Realms.

The following are all valid principal names:

• joe

• joe/admin

• joe/admin@ENG.EXAMPLE.COM

• nfs/host.eng.example.com@ENG.EXAMPLE.COM

• host/eng.example.com@ENG.EXAMPLE.COM

Realms

A realm is a logical network, similar to a domain, which defines a group of systems under the same master KDC. Figure 7–3 shows how realms can relate to one another. Some realms are hierarchical (one realm being a superset of the other realm). Otherwise, the realms are non-hierarchical (or “direct”) and the mapping between the two realms must be defined. A feature of SEAM is that it permits authentication across realms. Each realm only needs to have a principal entry for the other realm in its KDC. The feature is called cross-realm authentication.

Figure 7–3 Realms

Realms and Servers

Each realm must include a server that maintains the master copy of the principal database. This server is called the master KDC server. Additionally, each realm should contain at least one slave KDC server, which contains duplicate copies of the principal database. Both the master KDC server and the slave KDC server create tickets that are used to establish authentication.

Realms can also include NFS servers, which provide NFS services by using Kerberos authentication. If you have installed SEAM 1.0 or 1.0.1, the realm might include a SEAM network application server, which provides access to Kerberized applications (such as ftp, telnet, and rsh).

The following figure shows what a hypothetical realm might contain.

Figure 7–4 A Typical Realm

SEAM Security Services

In addition to providing secure authentication of users, SEAM provides two security services:

• Integrity – Just as authentication ensures that clients on a network are who they claim to be, integrity ensures that the data they send is valid and has not been tampered with during transit. Integrity is done through cryptographic checksumming of the data. Integrity also includes user authentication.

• Privacy – Privacy takes security a step further. Privacy not only includes verifying the integrity of transmitted data, but it encrypts the data before transmission, protecting it from eavesdroppers. Privacy authenticates users, as well.

SEAM Releases

Components of the SEAM product have been included in four releases. The following table describes which components are included in each release. All components are described in the following sections.

Table 7–1 SEAM Release Contents

Release Name	Contents
SEAM 1.0 in Solaris Easy Access Server (SEAS) 3.0	Full release of SEAM for the Solaris 2.6 and 7 releases
SEAM in the Solaris 8 release	SEAM client software only
SEAM 1.0.1 in the Solaris 8 Admin Pack	SEAM KDC and remote applications for the Solaris 8 release
SEAM in the Solaris 9 release	SEAM KDC and client software only
SEAM 1.0.2	SEAM remote applications for the Solaris 9 release

SEAM 1.0 Components

Similar to the MIT distribution of Kerberos V5, SEAM includes the following:

• Key Distribution Center (KDC) (master):

  • Kerberos database administration daemon – kadmind

  • Kerberos ticket processing daemon – krb5kdc

• Slave KDCs

• Database administration programs – kadmin and kadmin.local

• Database propagation software – kprop

• User programs for obtaining, viewing, and destroying tickets – kinit, klist, kdestroy – and for changing your SEAM password – kpasswd

• Applications – ftp, rcp, rlogin, rsh, and telnet – and daemons for these applications – ftpd, rlogind, rshd and telnetd

• Administration utilities – ktutil, kdb5_util

• Several libraries

In addition, SEAM includes the following:

• SEAM Administration Tool (gkadmin) – Allows you to administer the KDC. This Java^TM technology-based GUI allows an administrator to perform the tasks that are usually performed through the kadmin command.

• The Pluggable Authentication Module (PAM) – Allows applications to use various authentication mechanisms. PAM can be used to make login and logouts transparent to the user.

• A utility (gsscred) and a daemon (gssd) – These programs help map UNIX user IDs (UIDs) to principal names. These programs are needed because SEAM NFS servers use UNIX UIDs to identify users and not principal names, which are stored in a different format.

• The Generic Security Service Application Programming Interface (GSS-API) – Allows applications to use multiple security mechanisms without having to recompile the application every time a new mechanism is added. Because GSS-API is machine-independent, it is appropriate for applications on the Internet. GSS-API provides applications with the ability to include the integrity and privacy security services, as well as authentication.

• The RPCSEC_GSS Application Programming Interface (API) – Allows NFS services to use Kerberos authentication. RPCSEC_GSS is a new security flavor that provides security services that are independent of the mechanisms being used. RPCSEC_GSS sits “on top” of the GSS-API layer. Any pluggable GSS_API-based security mechanism can be used by applications that use RPCSEC_GSS.

• A preconfiguration procedure – Allows you to set the parameters for installing and configuring SEAM, which make SEAM installation automatic. This procedure is especially useful for multiple installations.

• Kernel modifications – Allows for faster performance.

SEAM Components in the Solaris 8 Release

The Solaris 8 release included only the client-side portions of SEAM, so many components are not included. This product enables systems that run the Solaris 8 release to become SEAM clients without having to install SEAM separately. To use these capabilities, you must install a KDC that uses either SEAS 3.0 or the Solaris 8 Admin Pack, the MIT distribution, or Windows2000. The client-side components are not useful without a configured KDC to distribute tickets. The following components were included in this release:

• User programs for obtaining, viewing, and destroying tickets – kinit, klist, kdestroy.

• User program for changing your SEAM password – kpasswd.

• Key table administration utility – ktutil.

• Additions to the Pluggable Authentication Module (PAM) – Allows applications to use various authentication mechanisms. PAM can be used to make login and logouts transparent to the user.

• GSS_API plug–ins – Provides Kerberos protocol and cryptographic support.

• NFS client and server support.

SEAM 1.0.1 Components

The SEAM 1.0.1 release includes all components of the SEAM 1.0 release that are not already included in the Solaris 8 release. The components are as follows:

• Key Distribution Center (KDC) (master):

  • Kerberos database administration daemon – kadmind.

  • Kerberos ticket processing daemon – krb5kdc.

• Slave KDCs.

• Database administration programs – kadmin and kadmin.local.

• Database propagation software – kprop

• Applications – ftp, rcp, rlogin, rsh, and telnet – and daemons for these applications – ftpd, rlogind, rshd and telnetd.

• Administration utility – kdb5_util.

• SEAM Administration Tool (gkadmin) – Allows you to administer the KDC. This Java technology-based GUI allows an administrator to perform the tasks that are usually performed through the kadmin command.

• A preconfiguration procedure – Allows you to set the parameters for installing and configuring SEAM, which makes SEAM installation automatic. This procedure is especially useful for multiple installations.

• Several libraries.

SEAM Components in the Solaris 9 Release

The Solaris 9 release includes all components of the SEAM 1.0 release, except for the remote applications and the preconfiguration procedure.

SEAM 1.0.2 Components

The SEAM 1.0.2 release includes the remote applications. These applications are the only part of SEAM 1.0 that have not been incorporated into the Solaris 9 release. The components for the remote applications are as follows:

• Client applications – ftp, rcp, rlogin, rsh, and telnet.

• Server Daemons – ftpd, rlogind, rshd and telnetd.