Secure RPC (AUTH_DES)

In the late 1980s, Sun Microsystems developed a system for improving Unix network security. Called Secure RPC, Sun’s system was first released with the SunOS 4.0 operating system. Although early versions of Secure RPC were difficult to use, later releases of the Solaris operating system have integrated Secure RPC into Sun’s NIS+ network information system (described in Chapter 14), which makes administration very simple.

Secure RPC is based on a combination of public key cryptography and secret key cryptography (see Chapter 7). Sun’s implementation uses the Diffie-Hellman mechanism for key exchange between users and DES secret key cryptography for encrypting information that is sent over the network. DES is also used to encrypt the user’s secret key that is stored in a central network server. This encryption eliminates the need for users to memorize or carry around the hundred-digit numbers that make up their secret keys.

Secure RPC solves many of the problems of AUTH_UNIX-style authentication. Because both users and computers must be authenticated, it eliminates many of the spoofing problems to which other systems lend themselves. Indeed, when used with higher-level protocols, such as NFS, Secure RPC can bring unprecedented security to the networked environment. Nevertheless, Secure RPC has not enjoyed the widespread adoption that Sun’s original RPC did. There are probably several reasons for this:

Free implementations of Secure RPC were not quickly forthcoming. Because Secure RPC is based on public key cryptography, using it within the United States required a license from the holder of the particular patents in question.^[182] Thus, Secure RPC was not included in many of the widely used fee-free versions of Unix.
As a result of the patents, the only way for vendors to implement Secure RPC was to write their own version (an expensive proposition) or to license the code from Sun. For whatever reason, some Unix vendors were unwilling or unable to license or implement Secure RPC from Sun. Thus, it is not possible to use Secure RPC with those systems.

Secure RPC Authentication

Secure RPC authentication is based on the Diffie-Hellman exponential key exchange system. Each Secure RPC principal^[183] has a secret key and a public key, both of which are stored on the Secure RPC server. The public key is stored unencrypted; the secret key is stored encrypted with the principal’s password. Both keys are typically numbers several thousand bits long.

A Secure RPC principal proves his, her, or its identity by decrypting the stored secret key and participating in the Diffie-Hellman key exchange. Each principal combines its secret key with the other’s public key, allowing both to arrive independently at a common, mutually known key. This key is then used to exchange a session key.

Proving your identity

The way you prove your identity with a public key system is by knowing your secret key. Unfortunately, most people aren’t good at remembering hundred-digit numbers, and deriving a good pair of numbers for a public key/secret key pair from a Unix password is relatively difficult.

Sun solves these problems by distributing a database consisting of usernames, public keys, and encrypted secret keys using the Sun NIS or NIS+ network database system. (Both NIS and NIS+ are described in Chapter 14.) The secret key is encrypted using the user’s Unix password as the key and the DES encryption algorithm. If you know your Unix password, your workstation software can get your secret key and decrypt it.

For each user, the following information is maintained:^[184]

Netname or canonical name: This is the user’s definitive name on the network. An example is fred.sun.com, which signifies the user fred in the domain sun.com. Older versions of NIS used the form UID.UNIX@domain.
User’s public key: A hexadecimal representation of the user’s public key.
User’s secret key: A hexadecimal representation of the user’s secret key, encrypted using the user’s password.

The user’s keys are created with either the chkey command or the nisaddcred command. Normally, this process is transparent to the user.

When the user logs into a workstation running Secure RPC, the workstation obtains a copy of the user’s encrypted secret key. The workstation then attempts to decrypt the secret key using the user’s provided password. The secret key must now be stored for use in communication with the Secure RPC server. In Version 4.1 and above, the unencrypted key is kept in the memory of the keyserv key server process. (In the original version of Secure RPC shipped with SunOS 4.0, the unencrypted secret key was stored in the /etc/keystore file. This was less secure, as anyone gaining access to the user’s workstation as either that user or as root could have easily accessed the user’s secret key.)

Next, the software on the workstation uses the user’s secret key and the server’s public key to generate a session key. (The server meanwhile has done the same thing using its secret key and the user’s public key). The workstation software then generates a random 56-bit conversation key and sends it, encrypted with the session keys to the server. The conversation key is used for the duration of the login, and is stored in the key server process.

The server knows that the user is who he claims to be because:

The packet that the user sent was encrypted using a conversation key.
The only way that the user could know the conversation key would be by generating it, using the server’s public key and the user’s secret key.
To know the user’s secret key, the workstation had to look up the secret key using NIS and decrypt it.
To decrypt the encrypted secret key, the user had to have entered the user’s password.

The user, similarly, is assured that the server is really genuine because it must possess a secret key that corresponds to the server public key held by the user.

Notice the following:

The user’s password is never transmitted over the network.
Only the encrypted form of the secret key is transmitted over the network.
There is no “secret” information about users on the server that must be protected from attackers.^[185] The server’s private key, however, is stored in cleartext on the server, and must be protected to prevent someone from impersonating the server.
The security of a particular session depends on the difficulty of breaking a 56-bit key.

Because public key encryption is slow and difficult to use for large amounts of data, the only thing that it is used for is initially proving your identity and exchanging the session key. Secure RPC then uses the session key and DES encryption (described in Chapter 7) for all subsequent communications between the workstation and the server.

Using Secure RPC services

After your workstation and the server have agreed upon a session key, Secure RPC authenticates all RPC requests.

When your workstation communicates with a server, the user provides a netname which the server is supposed to translate automatically into a local UID and GID. Ideally, this means that the user’s UID on the server does not have to be the same as the user’s UID on the workstation. In practice, most organizations insist that its users have a single UID throughout the organization; so the ability of Secure RPC to map UIDs from one computer to another is not terribly important.

When your session key expires, your workstation and the server automatically renegotiate a new session key.

Setting the window

Inside the header sent with every Secure RPC request is a timestamp. This timestamp prevents an attacker from capturing the packets from an active session and replaying them at a later time.

For a timestamp-based system to operate properly, it’s necessary for both the client and the server to agree on what time it is. Unfortunately, the real-time clocks on computers sometimes drift in relation to one another. This can present a serious problem to the user of Secure RPC: if the clock on the workstation and the clock on the server drift too far apart, the server will not accept any more requests from the client! The client and server will then have to reauthenticate each other.

Because reauthenticating takes time, Secure RPC allows the workstation’s system administrator to set the “window” that the server uses to determine how far the client’s clock can drift and still remain acceptable. Obviously, using a large window reduces the danger of drift. Unfortunately, a large window similarly increases the chance of a playback attack, in which an attacker sniffs a packet from the network, then uses the authenticated credentials for her own purposes. A larger window increases the possibility of a playback attack because any packet that is intercepted will be good for a longer period of time.

Solaris Versions 2.3 and 2.4 use a default window of 60 minutes; Solaris Version 2.5 and later uses a window of 300 seconds (5 minutes). This latter window is what Sun Microsystems recommends for security-sensitive applications. If you have well-synchronized clocks (e.g., dependable NTP service), you may wish to reduce this window even further—a window of 2-5 seconds should be sufficient.

The size of the Secure RPC window is set in the kernel by the variable authdes_win , which stores the value of the window in seconds. On an SVR4 machine such as Solaris 2.x, you modify the authdes_win variable from the /etc/system file:

set nfs:authdes_win=300

You then reboot with the modified /etc/system file.

On other systems, you may need to modify a kernel variable and recompile the kernel. For example, in the Linux 2.4 kernel, the macro DES_REPLAY_SLACK is defined in milliseconds in net/sunrpc/svcauth_des.c in the kernel source; it defaults to 2000 (2 seconds).

Note that if you set this window value too small, your RPCs will be extremely time-consuming because they will need to continually execute the resynchronization protocol, and this includes the slow public key operations. In general, you should pick a value that is twice the maximum tolerable deviation for any system clock, compared to “real” time. (You use twice this value because one clock could be fast and the other slow.)

Using a network time service like NTP (Network Time Protocol) can eliminate time skew between servers and workstations. Even without NTP, clocks typically don’t drift more than five seconds during the course of a single day’s operation, but running with a proper NTP installation can keep the skew in the range of milliseconds (or better). However, vanilla NTP servers can be maliciously led away from the correct time by a determined and skilled adversary. If you are depending on the correct time for this protocol, you should consider establishing keyed NTP access to trusted servers, syncing against multiple time sources, or obtaining your own stratum-1 time source. (See the description of NTP and the sidebar Telling Time in Chapter 12.)

Setting Up Secure RPC with NIS

To use Secure RPC, your client computers need a way of obtaining keys from the Secure RPC server. You can distribute the keys in standard Unix files or distribute them automatically with either NIS or NIS+.^[186]

The easiest way to set up Secure RPC is to set up NIS+. Sun’s NIS+ requires Secure RPC to function properly. As a result, the NIS+ installation procedure will automatically create the appropriate Secure RPC keys and credentials. When you add new NIS+ users, their Secure RPC keys will automatically be created.

Running Secure RPC with NIS is more difficult. You will need to manually create the keys and place them in the appropriate NIS maps. If you are not using NIS, you can simply place the keys in the file /etc/publickey. For detailed information, you should refer to your vendor’s documentation for explicit instructions on how to set up Secure RPC. Nevertheless, this guide may be helpful.

Tip

As this book goes to press, Sun is migrating away from NIS+ to LDAP-based network services. If your system uses LDAP instead of NIS or NIS+, you should check your documentation for how keys are created and distributed.

Creating passwords for users

Before you enable Secure RPC, make sure that every user has been assigned a public key and a secret key. Check the file /etc/publickey on the master NIS server. If a user doesn’t have an entry in the database, you can create an entry for that user by becoming the superuser on the NIS master server and typing:

# newkey -u 
                     username

Alternatively, you create an entry in the database for the special user nobody. After an entry is created for nobody, users can run the chkey program on any client to create their own entries in the database.

Creating passwords for hosts

Secure RPC also allows you to create public secret key pairs for each host of your network. To do so, type:

# newkey -h 
                     hostname

Making sure Secure RPC support is running on every workstation

Log into a workstation and make sure that the keyserv and ypbind daemons are running. The programs should be started by a command in the appropriate system startup file (e.g., /etc/rc.local for BSD-derived systems, and /etc/rc2.d/S*rpc for System V-derived systems). You also need to make sure that rpc.ypupdated is run from either inetd.conf or rc.local on the server.

You can check for these daemons with the ps command (you would use the -ef flags to ps on an SVR4 system such as Solaris 2.x):

% ps aux | egrep 'keyserv|ypbind'
root 63 0.0 0.0  56  32 ? IW Jul 30 0:30 keyserv 
root 60 0.3 0.7 928 200 ?  S Jul 30 3:10 ypbind

Now you should log onto an NIS client and make sure that the publickey map is available. Use the ypcat publickey command. If the map is not available, log into the server and issue the yppush command.

Warning

There have been some nasty vulnerabilities with RPC services in the past; see, for example, CERT advisories CA-2002-25, CA-2002-11, CA-2002-10, CA-2000-17, CA-1999-16, CA-1999-12, CA-1999-08, CA-1999-05, CA-1998-12, and CA-1995-17. Some of these vulnerabilities have been widely exploited in automated attack tools. As always, make sure that you are running the most recent version of all network services. See http://www.cert.org/ for more details.

Using Secure RPC

Using Secure RPC is very similar to using standard RPC. If you log in by typing your username and password (at the login window on the console, by using telnet or rlogin to reach your machine, or with a client such as ssh that has been linked with the RPC libraries), your secret key is automatically decrypted and stored in the key server. Secure RPC automatically performs the authentication “handshake” every time you contact a service for the first time. In the event that your session key expires—either because of a time expiration or a crash and reboot—Secure RPC automatically obtains another session key.

If you log in over the network without having to type a password—for example, you use ssh to reach your computer from a trusted machine—you will need to use the keylogin program to calculate your secret key and store it in the key server. Do not use keylogin unless you have logged in using ssh or a VPN; otherwise, your password will travel over the network without being first encrypted.

Before you log out of your workstation, be sure to run the keylogout program to destroy the copy of your secret key stored in the key server. If you use csh as your shell, you can run this program automatically by placing the command keylogout in your ~/.logout file:

# 
# ~/.logout file 
#

# Destroy secret keys.
keylogout

Limitations of Secure RPC

At the time of its release, Sun’s Secure RPC represented a quantum leap in security over Sun’s standard RPC. This was good news for sites that used NFS: with Secure RPC, NFS could be used with relative safety. Nevertheless, Secure RPC is not without its problems:

Every network client must be individually modified for use with Secure RPC

Although Secure RPC is a transparent modification to Sun’s underlying RPC system, the current design of Sun’s RPC library requires an application program to specify individually which authentication system (AUTH_NONE, AUTH_UNIX, AUTH_DES, or AUTH_KERB) the program wants to use. For this reason, every client that uses a network service must be individually modified to use AUTH_DES authentication.

Although the modifications required are trivial, a better approach would be to allow the user to specify the authentication service requested in an environment variable, or on some other per-user or per-site, rather than per-program, basis.^[187]

There is a slight performance penalty

Secure RPC penalizes every RPC transaction that uses it because the RPC authenticator must be decrypted to verify each transmission. Fortunately, the performance penalty is small because symmetric encryption algorithms are quite fast.

Secure RPC does not provide for data integrity or confidentiality

Secure RPC authenticates the user, but it does not protect the data that is transmitted with either encryption or digital signatures. It is the responsibility of programs using Secure RPC to encrypt using a suitable key and algorithm.

It may be possible to break the public key

Any piece of information encrypted with the Diffie-Hellman public key encryption system used in Secure RPC can be decrypted if an attacker can calculate the discrete logarithm of the public key. In 1989, Brian LaMacchia and Andrew Odlyzko at AT&T’s Bell Laboratories in New Jersey discovered a significant performance improvement for the computation of discrete logarithms. Since then, numerous other advances in this field of mathematics have taken place. Secure RPC makes the public key and the encrypted secret key available to RPC client computers on the network. Thus, keys that are secure today may be broken tomorrow.

It is possible to break the secret key

The Secure RPC secret key is encrypted with a 56-bit DES key and is made publicly available on the network server. As computers have become faster, the possibility of a real-time, brute force attack against the user’s encrypted secret key has become a reality.

In the final analysis, using Secure RPC provides much better protection than many other approaches, especially with multiuser machines. Secure RPC is clearly better than plain RPC. Unfortunately, because Secure RPC requires the use of either NIS or NIS+, many multivendor sites have chosen not to use it. These sites should consider DCE or LDAP, which provide workable solutions for heterogeneous environments.

^[182]At the time that Berkeley was developing its free version of the Unix operating system, the holder of the public key cryptography patents, a California partnership called Public Key Partners, was notoriously hesitant to give licenses to people who were writing free versions of programs implementing the PKP algorithms. The patents covering Diffie-Hellman cryptography expired in 1997, and the RSA patent expired in 2000.

^[183]Secure RPC principals are users that have Secure RPC passwords and computers that are configured to use Secure RPC.

^[184]This information can be maintained in the files /etc/publickey and /etc/netid. If you are using NIS, the data is stored in the NIS maps publickey.byname and netid.byname. With NIS+, all of this information is combined in a single NIS+ table cred.org_dir.

^[185]In contrast, the Kerberos system requires that the master Kerberos Server be protected literally with lock and key: if the information stored on the Kerberos Server is stolen by an attacker, the entire system, including all user passwords, is compromised.

^[186]If you are using Secure RPC on something other than a Sun system, be sure to check your documentation—there may be some other way to distribute the key information.

^[187]We said the same thing in the first version of this book in 1991.

Previous Chapter

Remote Procedure Call (RPC)

Next Chapter

Summary