Secure RPC

Secure RPC is fundamental to Secure NFS. The goal of Secure RPC is to build a system at least as secure as a time-sharing system (one in which all users share a single computer). A time-sharing system authenticates a user through a login password. With Data Encryption Service(DES) authentication, the same is true. Users can log in on any remote computer just as they can on a local terminal, and their login passwords are their passports to network security. In time-sharing, the system administrator has an ethical obligation not to change a password in order to impersonate someone. In Secure RPC, the network administrator is trusted not to alter entries in a database that stores "public keys."

You need to be familiar with two terms to understand an RPC authentication system: credentials and verifiers. Using ID badges as an example, the credential is what identifies a person: a name, address, birth date, and so on. The verifier is the photo attached to the badge: you can be sure the badge has not been stolen by checking the photo on the badge against the person carrying it. In RPC, the client process sends both a credential and a verifier to the server with each RPC request. The server sends back only a verifier because the client already knows the server's credentials.

RPC's authentication is open ended, which means that a variety of authentication systems may be plugged into it. Currently, there are three systems: UNIX, DES, and KERB.

When UNIX authentication is used by a network service, the credentials contain the client's computer-name, UID, gid, and group-access-list, but the verifier contains nothing. Because there is no verifier, a root user could deduce appropriate credentials, using commands such as su. Another problem with

UNIX authentication is that it assumes all computers on a network are UNIX computers. UNIX authentication breaks down when applied to other operating systems in a heterogeneous network.

To overcome the problems of UNIX authentication, Secure RPC uses DES authentication--a scheme that employs verifiers, yet allows Secure RPC to be general enough to be used by most operating systems.

DES Authentication

DES authentication uses the Data Encryption Standard (DES) and Diffie-Hellman public key cryptography to authenticate both users and computers in the network. DES is a standard encryption mechanism; Diffie-Hellman public key cryptography is a cipher system that involves two keys: one public and one secret. The public and secret keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map, and NIS+ stores the keys in the cred table. These maps contain the public key and secret key for all potential users. See Security, Performance, and Accounting Administration for more information on how to set up the maps and tables.

The security of DES authentication is based on a sender's ability to encrypt the current time, which the receiver can then decrypt and check against its own clock. The timestamp is encrypted with DES. There are two requirements for this scheme to work:

• The two agents must agree on the current time
• The sender and receiver must be using the same encryption key.

If a network runs a time synchronization program, then the time on the client and the server is synchronized automatically. If a time synchronization program is not available, timestamps can be computed using the server's time instead of the network time. The client asks the server for the time before starting the RPC session, then computes the time difference between its own clock and the server's. This difference is used to offset the client's clock when computing timestamps. If the client and server clocks get out of sync to the point where the server begins to reject the client's requests, the DES authentication system resynchronizes with the server.

The client and server arrive at the same encryption key by generating a random conversation key, also known as the session key, and then using public key cryptography (an encryption scheme involving public and secret keys) to

deduce a common key. The common key is a key that only the client and server are capable of deducing. The conversation key is used to encrypt and decrypt the client's timestamp; the common key is used to encrypt and decrypt the conversation key.

KERB Authentication

Kerberos is an authentication system developed at MIT. Encryption in Kerberos is based on DES.

Kerberos works by authenticating the user's login password. A user types the kinit command, which obtains a ticket that is valid for the time of the session (or eight hours, the default session time) from the authentication server. When the user logs out, the ticket may be destroyed using the kdestroy command.

The Kerberos software is available from MIT project Athena, and is not part of the SunOS software. SunOS software provides:

• Routines used by the client to create, acquire, and verify tickets
• An authentication option to Secure RPC
• A client-side daemon, kerbd (1M)

See Security, Performance, and Accounting Administration for more details.

AUTH_DES Client/Server Session

This section describes the series of transactions in a client/server session using AUTH_DES.

Step 1 Sometime prior to a transaction, the administrator runs a program, either newkey (1M) or nisaddcred (1) that generates a public key and a secret key. (Each user has a unique public key and secret key.) The public key is stored in a public database; the secret key is stored in encrypted form, in the same database. To change the key pair, use the chkey (1) command.

Step 2 The user logs in and runs the keylogin program (or the keylogin program may be included in the user's environment configuration file, such as ~/.login, ~/.cshrc, or ~/.profile, so that it runs automatically whenever the user logs in). The keylogin program prompts the user for a secure RPC, or network, password and uses the password to decrypt the secret key. The keylogin program then passes the decrypted secret key to a program called the Keyserver. (The Keyserver is an RPC service with a local instance on every computer.) The Keyserver saves the decrypted secret key, and waits for the user to initiate a secure RPC transaction with a server.

Usually, the login password is identical to the network password. In this case, keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin explicitly.

Step 3 When the user initiates a transaction with a server:

1. The Keyserver randomly generates a conversation key.

2. The kernel uses the conversation key to encrypt the client's timestamp (among other things).

3. The Keyserver looks up the server's public key in the public key database (see publickey (4)).

4. The Keyserver uses the client's secret key and the server's public key to create a common key.

5. The Keyserver encrypts the conversation key with the common key.

Step 4 The transmission including the encrypted timestamp and the encrypted conversation key is then sent to the server. The transmission includes a credential and a verifier. The credential contains threecomponents:

• The client's net name
• The conversation key, encrypted with the common key
• A "window," encrypted with the conversation key

The window is the difference the client says should be allowed between the server's clock and the client's timestamp. If the difference between the server's clock and the timestamp is greater than the window, the server would reject the client's request.

The client's verifier contains:

• The encrypted timestamp
• An encrypted verifier of the specified window, incremented by 1

The window verifier is needed in case somebody wants to impersonate a user and writes a program that, instead of filling in the encrypted fields of the credential and verifier, just stuffs in random bits. The server will decrypt the conversation key into some random key, and use it to try to decrypt the window and the timestamp. The result will be random numbers. After a few thousand trials, however, there is a good chance that the random window/timestamp pair will pass the authentication system. The window verifier makes guessing the right credential much more difficult.

Step 5 When the server receives the transmission from the client:

1. The Keyserver local to the server looks up the client's public key in the publickey database.

2. The Keyserver uses the client's public key and the server's secret key to deduce the common key--the same common key computed by the client. (Only the server and the client can calculate the common key because doing so requires knowing one secret key or the other.)

3. The kernel uses the common key to decrypt the conversation key.

4. The kernel calls the Keyserver to decrypt the client's timestamp with the decrypted conversation key.

Step 6 After the server decrypts the client's timestamp, it stores four items of information in a credential table:

• The client's computer name
• The conversation key
• The window

• The client's timestamp

The server stores the first three items for future use. It stores the timestamp to protect against replays. The server accepts only timestamps that are chronologically greater than the last one seen, so any replayed transactions are guaranteed to be rejected.

---

Note - Implicit in these procedures is the name of caller, who must be authenticated in some manner. The Keyserver cannot use DES authentication to do this because it would create a deadlock. To solve this problem, the Keyserver stores the secret keys by UID, and grants requests only to local root processes. The client process then executes a set-UID process, owned by root, which makes the request on the part of the client, telling the Keyserver the real UID of the client.

---

Step 7 The server returns a verifier to the client, which includes:

• The index ID, which the server records in its credential cache.
• The client's timestamp minus one, encrypted by conversation key

The reason for subtracting one from the timestamp is to ensure that it is invalid and cannot be reused as a client verifier.

Step 8 The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what timestamp the client sent.

Step 9 The client returns the index ID to the server in its second transaction and sends another encrypted timestamp.

Step 10 The server sends back the client's timestamp minus one, encrypted by the conversation key.

With every transaction after the first, the client sends its index ID and another encrypted timestamp, and the server returns the timestamp minus one.

You should be aware of the following points if you plan to use Secure RPC:

• If a server crashes when no one is around (after a power failure for example), all of the secret keys that are stored on the system are wiped out. Now no process is able to access secure network services, or mount an NFS file system. The important processes at this time are usually root processes, so things would work if root's secret key were stored away, but nobody is around to type the password that decrypts it. keylogin -r allows root to store the clear secret key in /etc/.rootkey which keyserve(1M) reads.
• Some systems boot in single-user mode, with a root login shell on the console and no password prompt. Physical security is imperative in such cases.
• Diskless computer booting is not totally secure. Somebody could impersonate the boot server, and boot a devious kernel that, for example, makes a record of your secret key on a remote computer. Secure NFS provides protection only after the kernel and the Keyserver are running. Before that, there is no way to authenticate the replies given by the boot server. This is not a serious problem, because somebody would probably not be able to write this compromised kernel without source code. Also, the crime would have evidence. If you polled the network for boot-servers, you would discover the devious boot-server's location.
• Most set-UID programs are owned by root; because root's secret key is always stored at boot time, these programs behave as they always have. If a set-UID program is owned by a user, however, it may not always work. For example, if a set-UID program is owned by dave, and dave has not logged into the computer since it booted, then the program would not be able to access secure network services.
• If you log in to a remote computer (using login, rlogin, or telnet) and use keylogin to gain access, you give away access to your account. This is because your secret key gets passed to that computer's Keyserver, which then stores it. This is only a concern if you don't trust the remote computer. If you have doubts, however, don't log in to a remote computer if it requires a password. Instead, use the NFS environment to mount file systems shared by the remote computer. As an alternative, you can use keylogout(1) to delete the secret key from the Keyserver.

Administering Secure NFS

To use Secure NFS, all the computers you are responsible for must have a domain name. A domain is an administrative entity, typically consisting of several computers, that joins a larger network. If you are running NIS+, you should also establish the NIS+ name service for the domain. See Security, Performance, and Accounting Administration.

With UNIX authentication, the name of a domain is the UID. UIDs are assigned per domain. A problem with this scheme is that UIDs clash when domains are linked across the network. Another problem with UNIX authentication has to do with superusers; with UNIX authentication, the superuser ID (UID 0) is assigned one per computer, not one per domain. Therefore, a domain can have multiple superusers--all with the same UID.

DES authentication corrects these problems by using netnames. A netname is a string of printable characters created by concatenating the name of the operating system, a user ID, and a domain name. For example, a UNIX system user with a user ID of 508 in the domain eng.acme.COM would be assigned the following netname: unix.508@eng.acme.COM. Because user IDs are unique within a domain, and because domain names are unique on a network, this scheme produces a unique netname for every user.

To overcome the problem of multiple superusers per domain, netnames are assigned to computers as well as to users. A computer's netname is formed much like a user's--by concatenating the name of the operating system and the computer name with the domain name. A UNIX computer named hal in the domain eng.acme.COM would have the netname unix.hal@eng.acme.COM.

Instructions for Administering Secure NFS

This section includes step-by-step instructions for performing tasks related to managing Secure NFS. After each set of instructions for many tasks, there is an example of the screen input and output associated with the task, with all relevant assumptions defined and described.

Setting Up Secure NFS

1. Assign your domain a domain name, and make the domain name known to each computer in the domain. See the Name Services Administration Guide if you are using NIS+ as your name service.

2. Establish public keys and secret keys for your clients' users using the

   newkey(1M) command, and have each user establish his or her own secure RPC password using the chkey command.

---

Note - For information about these commands, see the newkey(1M) and the chkey(1) manual pages.

---

When public and secret keys have been generated, the public and encrypted secret keys are stored in the publickey database.

3. Usually, the login password is identical to the network password. In this case, keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin. You still need to use the keylogin -r command as root to store the decrypted secret key in /etc/.rootkey.

4. If you are running NIS, verify that the ypbind daemon is running and that there is a ypserv running in the domain.

ps -ef | grep ypbind

5. To verify that the keyserv daemon (the Keyserver) is running, type the following:

ps -ef | grep keyserv

If it isn't running, to start the Keyserver, type the following:

/usr/sbin/keyserv

6. Edit the /etc/dfs/dfstab file and add the secure option to the appropriate entries (for DES authentication).

share -F nfs -o secure /export/home

(For KERB authentication, add the kerberos option.)

share -F nfs -o kerberos /export/home

7. Edit the auto_master map to include secure as a mount option in the appropriate entries: (for DES authentication)

/home auto_home -nosuid,secure

(For KERB authentication, add the kerberos option.)

/home auto_home -nosuid,kerberos

---

Note - If a client does not mount as secure a file system that is shared as secure, users have access as user nobody, rather than as themselves.

---

When you reinstall, move, or upgrade a computer, remember to save /etc/.rootkey if you don't establish new keys or change them for root. If you do delete /etc/.rootkey, it's not fatal. You can always type keylogin -r (1).