Andrew Tanenbaum - Distributed operating systems

The login facilityis a program that asks users their names and passwords during the login sequence. It uses the authentication and privilege servers to do its job, which is to get the user logged in and to collect the necessary tickets and PACs for them.

Fig. 10-26.Major components of the DCE security system for a single cell.

Once a user is logged in, he can start a client process that can communicate securely with a server process using authenticated RPC. When an authenticated RPC request comes in, the server uses the PAC to determine the user's identity, and then checks its ACL to see if the requested access is permitted. Each server has its own ACL manager for guarding its own objects. Users can be added or removed from an ACL, permissions granted or removed, and so on, using an ACL editor program.

In this section we will describe how the authentication and privilege servers work and how they allow users to log into DCE in a secure way over an insecure network. The description covers only the barest essentials, and ignores most of the variants and options available.

Each user has a secret key known only to himself and to the registry. It is computed by passing the user's password through a one-way (i.e., noninvertible) function. Servers also have secret keys. To enhance their security, these keys are used only briefly, when a user logs in or a server is booted. After that authentication is done with tickets and PACs.

A ticketis an encrypted data structure issued by the authentication server or ticket-granting server to prove to a specific server that the bearer is a client with a specific identity. Tickets have many options, but mostly we will discuss tickets that look like this:

ticket = S, {session-key, client, expiration-time, message-id} K s

where S is the server for whom the ticket is intended. The information within curly braces is encrypted using the server's private key, K S . The fields encrypted include a temporary session key, the client's identity, the time at which the ticket ceases to be valid, and a message identifier or noncethat is used to relate requests and replies. When the server decrypts the ticket with its private key, it obtains the session key to use when talking to the client. In our descriptions below, we will omit all encrypted ticket fields except the session-key and client name.

In some situations tickets and PACs are used together. Tickets establish the identity of the sender (as an ASCII string), whereas PACs give the numerical values of user-id and group-ids that a particular principal is associated with. Tickets are generated by the authentication server or ticket-granting server (one and the same server), whereas PACs are generated by the privilege server.

In many situations, it is not essential that messages be secret, only that intruders not be able to forge or modify them. For this purpose, authenticators can be attached to plaintext messages to prevent active intruders from changing them. An authenticatoris an encrypted data structure containing at least the following information:

authenticator = {sender, MD5-checksum, timestamp) K

where the checksum algorithm, MD5 (Message Digest 5), has the property that given a 128-bit MD5 checksum it is computationally infeasible to modify the message so that it still matches the checksum (which is protected by encryption). The timestamp is needed to make it possible for the receiver to detect the replay of an old authenticator.

The sequence from logging in to the point where the first authenticated RPC is possible typically requires five steps. Each step consists of a message from the client to some server, followed by a reply back from the server to the client. The steps are summarized in Fig. 10-27 and are described below. For simplicity, most of the fields, including the cells, message IDs, lifetimes, and identifiers have been omitted. The emphasis is on the security fundamentals: keys, tickets, authenticators, and PACs.

Principals

A: Authentication server (handles authentication)

C: Client (user)

P: Privilege server (issues PACs)

S: Application server (does the real work)

T: Ticket-granting server (issues tickets)

Step 1: client gets a ticket for the ticket-granting server using a password

C→A: C (just the client's name, in plaintext)

C←A: {K 1 , {K 1, C}K A}}K C

Step 2:client uses the previous ticket to get a ticket for the privilege server

C→T: {K 1, C}K A, {C, MD-5 checksum, Timestamp}K 1

C←T: {K 2,{C, K 2}K P}K,

Step 3:client asks the privilege server for the initial PAC

C→P: {C, K 2}K P, {C, MD-5 checksum, Timestamp}K 2

C←P: {K 3,{PAC, K 3}K A}K 2

Step 4:client asks the ticket-granting server for a PAC usable by S

C→T: {K 3,{PAC, K 3}K A}K 3, {C, MD-5 checksum, Timestamp}K 3

C←T: {K 4,{PAC, K 4}K S}K 3

Step 5:client establishes a key with the application server

C→S: {PAC, K 4}K S,{C, MD-5checksum, Timestamp}K 4

C←S: {K 5, Timestamp}K 4

Fig. 10-27.From login to authenticated RPC in five easy steps.

When a user sits down at a DCE terminal, the login program asks for his login name. The program then sends this login name to the authentication server in plaintext. The authentication server looks it up in the registry and finds the user's secret key. It then generates a random number for use as a session key and sends back a message encrypted by the user's secret key, K C , containing the first session key, K 1, and a ticket good for later use with the ticket-granting server. These messages are shown in Fig. 10-27 in step 1. Note that this figure shows 10 messages, and for each the source and destination are given before the message, with the arrow pointing from the source to the destination.

When the encrypted message arrives at the login program, the user is prompted for his password. The password is immediately run through the oneway function that generates secret keys from passwords. As soon as the secret key, K C has been generated from the password, the password is removed from memory. This procedure minimizes the chance of password disclosure in the event of a client crash. Then the message from the authentication server is decrypted to get the session key and the ticket. When that has been done, the client's secret key can also be erased from memory.

Note that if an intruder intercepts the reply message, it will be unable to decrypt it and thus unable to obtain the session key and ticket inside it. If it spends enough time, the intruder might eventually be able to break the message, but even then the damage will be limited because session keys and tickets are valid only for relatively short periods of time.

In step 2 of Fig. 10-27, the client sends the ticket to the ticket-granting server (in fact, the authentication server under a different name) and asks for a ticket to talk to the privilege server. Except for the initial authentication in step 1, talking to a server in an authenticated way always requires a ticket encrypted with that server's private key. These tickets can be obtained from the ticket-granting server as in step 2.

When the ticket-granting server gets the message, it uses its own private key, K A to decrypt the message. When it finds the session key, K 1, it looks in the registry and verifies that it recently assigned this key to client C. Since only C knows K C, the ticket-granting server knows that only C was able to decrypt the reply sent in step 1, and this request must have come from C.