test

System Administration Guide, Volume 2

Chapter 21 SEAM Overview

This chapter provides an introduction to the Solaris 8 version of the SEAM product. The SEAM 1.0 product includes an implementation of the Kerberos V5 network authentication protocol. It is available in the Sun Easy Access Server (SEAS) 3.0 release.The Solaris 8 release does not include all parts of the SEAM product. Only the client-side product is included. This chapter includes information for both the client-side and the server-side parts of the SEAM product, so that the interaction of the whole product can be described. The following topics are covered:

What Is SEAM?

Sun Enterprise Authentication Mechanism (SEAM) is a client/server architecture that offers strong user authentication, as well as data integrity and privacy, for providing secure transactions over networks. Authentication guarantees that the identities of both the sender and recipient of a network transaction are true; SEAM can also verify the validity of data being passed back and forth (integrity) and encrypt it 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, allowing 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, meaning that you only need to authenticate yourself to SEAM once per session, and all subsequent transactions during the session are automatically authenticated. You will not need to re-enter the password once your are authenticated. This means 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 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 industry standard for network security (see RFC 1510), SEAM promotes interoperability with other systems. In other words, because SEAM works with systems using 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." ("Kerberos" and "Kerberos V5" are used interchangeably as well.) 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. That means 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 layer modularly under the Generic Security Service API, applications that make use of the GSS-API can utilize whichever security mechanism best suits their needs.

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.

Kerberos-Specific Terminology

Understanding the terms presented in this section, is needed when studying the sections about the administering the KDCs.

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

A stash file contains a 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 kadmind and krb5kdc. 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

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.

SEAM Components

The full release of SEAM 1.0 in SEAS 3.0 includes many components, including:

The list of all of the components in the SEAM 1.0 release can be found in "Introduction to SEAM" in Sun Enterprise Authentication Mechanism Guide.

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

How SEAM Works

The following is a generalized 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 kinit to a new principal -- you transparently send a request for a ticket to a Key Distribution Center, or KDC, which accesses a database to authenticate your identity. The KDC returns a ticket granting you permission to access the other machine. "Transparently" means that you do not need to explicitly request a ticket; it happens as part of the kinit command. Because only the authenticated client can get a ticket for a specific service, another client cannot use kinit under an assumed identity.

Tickets have certain attributes associated with them. For example, a ticket can be forwardable (meaning 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 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".

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.ACME.COM, where:

The following are all valid principal names:

Realms

A realm is a logical network, like a domain, which defines a group of systems under the same master KDC. The figure below shows how realms can relate to one another. Some realms are hierarchical, with one being a superset of the other. Otherwise, the realms are non-hiearchical 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.

Figure 21-1 Realms

Graphic

Realms and Servers

Each realm must include a server that maintains the master copy of the principal database. This 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 and the slave KDC servers create tickets 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, using Kerberos authentication.

The figure below shows what a hypothetical realm might contain.

Figure 21-2 A Typical Realm

Graphic

Security Services

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

Developers can design their RPC-based applications to choose a security service by using the RPCSEC_GSS programming interface.