test

Sun Enterprise Authentication Mechanism Guide

Chapter 1 Introduction to SEAM

This chapter provides an introduction to the SEAM product.

What Is SEAM?

SEAM (Sun Enterprise Authentication Mechanism) 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 secured. After SEAM has authenticated you, you do not need to authenticate yourself every time you use a SEAM-based command such as ftp or rsh, or access data on an NFS file system. 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 de facto industry standard for network security, 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." (Moreover, "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, telnet, and ftp. 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 integrate modularly into the Generic Security Service API, applications that make use of the GSS-API can utilize whichever security mechanism best suits their needs.

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. Commands such as rsh or ftp work pretty much in their usual fashion. Initializing a SEAM session is often 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, 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 rlogin command. Because only the authenticated client can get a ticket for a specific service, another client cannot use rlogin 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".

The following sections briefly 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.

Figure 1-1 shows how the initial authentication takes place:

Figure 1-1 Initial Authentication for SEAM Session

Graphic

  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. This is often done automatically at login.

    A ticket-granting ticket is needed to obtain other tickets for specific services. One analogy is to 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 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, such as rlogin or telnet, for as long as the ticket-granting ticket lasts. This is usually 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 shown in Figure 1-2:

Figure 1-2 Obtaining Access to a Service

Graphic

  1. The client requests a ticket for a particular service (say, to rlogin into another machine) from the KDC, 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 the user joe uses rlogin on the server boston. Since he is already authenticated (that is, he already has a ticket-granting ticket), he automatically and transparently obtains a ticket as part of the rlogin command. This ticket allows him to rlogin into boston as often as he wants until it expires. If joe wants to rlogin into the machine denver, he obtains another ticket, as in Step 1.

  3. The client sends the ticket to the server.

  4. The server allows the client access.

Looking at these steps, you might have noticed that the server doesn't appear to ever communicate with the KDC. It does, though; it registers itself with the KDC, just as the first client does. For simplicity's sake we have left that part out.

The SEAM-Based Commands

What are the SEAM-based (or "Kerberized") commands that a user such as joe can use? They are:

These applications are the same as the Solaris applications of the same name, except that they use Kerberos principals to authenticate transactions, thereby providing Kerberos-based security. (See "Principals" for information on principals.)

These commands are discussed further in "SEAM Commands".

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.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 (see below). Figure 1-3 shows how realms can relate to one another. Some realms are hierarchical (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 1-3 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.

Figure 1-4 shows what a hypothetical realm might contain.

Figure 1-4 A Typical Realm

Graphic

Security Services

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

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 Components

Like the MIT distribution of Kerberos V5, SEAM includes:

In addition, the SEAM product includes the following: