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 or telnet.

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 (ftp, rcp, rlogin, and so on).

• 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, ftp/bigmachine.eng.example.com or 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

• ftp/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 13-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 13-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.

The realm can also include two additional types of SEAM servers. A SEAM network application server is a server that provides access to Kerberized applications (such as ftp, telnet and rsh). 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 13-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.

Currently, of the various Kerberized applications which are part of SEAM, only the ftp command allows users to change security service at runtime ("on the fly"). Developers can design their RPC-based applications to choose a security service by using the RPCSEC_GSS programming interface.

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 13-1 SEAM Release Contents

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