|
Chapter 19 RPC, NIS, NIS+, and Kerberos |
|
|
|
Chapter 19 RPC, NIS, NIS+, and Kerberos |
|
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 later in this chapter), which makes administration very simple.
Secure RPC is based on a combination of public key cryptography and secret key cryptography, which we describe in Chapter 6, Cryptography . 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:
The University of California at Berkeley did not write a free implementation of Secure RPC .[5] As a result, 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.
[5] Because Secure RPC is based on public key cryptography, using it within the United States would have required a license from the holder of the particular patents in question. 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. This situation might change after 1997, when the patents covering Diffie-Hellman cryptography expire.
For whatever reason, many UNIX vendors were unwilling or unable to license or implement Secure RPC from Sun. Thus, it is not possible to interoperate with those systems.
Secure RPC authentication is based on the Diffie-Hellman exponential key exchange system. Each Secure RPC principal[6] 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 hexadecimal numbers of several hundred digits.
[6] Secure RPC principals are users that have Secure RPC passwords and computers that are configured to use Secure RPC.
A Secure RPC principal proves his, her or its identity by being able to decrypt 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.
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 later in this chapter.) 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:[7]
[7] The information could 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 .
This is the user's definitive name over 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 .
A hexadecimal representation of the user's public 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 in to a computer running Secure RPC , the computer obtains a copy of the user's encrypted secret key. The computer 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 is then 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 would be able to easily access 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 then generates a random 56-bit conversation key and sends it to the server, encrypted with the session key. The conversation key is used for the duration of the login, and is stored in the key server process.
The file 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 known the key that it was encrypted with--which is, in fact, the user's password.
Notice the following:
The user's password is never transmitted over the network.
The only time the secret key is transmitted over the network is when it is encrypted using the user's password.
There is no "secret" information on the file server that must be protected from attackers.[8]
[8] In contrast, the Kerberos system, as we shall see, 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 is compromised.
The entire security of the system 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 6 ) for all subsequent communications between the workstation and the server.
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 through 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.
Inside the header sent with every Secure RPC request is a timestamp. This time-stamp 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 file 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 system administrator to set the "window" that the server uses to determine how far the client's clock can drift and remain acceptable. Obviously, using a large window reduces the danger of drift. Unfortunately, large windows similarly increase the chance of a playback attack, in which an attacker sniffs a packet from the network, then uses the authenticated credentials for his or her own purposes. Larger windows increase 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 uses a window of 300 seconds (5 minutes). This window is what Sun Microsystems recommends for security-sensitive applications.
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 a System VR4 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.
If you have a SunOS system, you can modify the value of _authdes_win by using the adb debugger program. Execute the following commands as superuser:
# adb -w /vmunix - authdes_win?D _authdes_win: _authdes_win: 3600 The default window ?W0t600 _authdes_win: 0xe10 = 0x258 _authdes_win: 300 $q Write the result out #
You do not need to reboot under SunOS, as the adb command modifies both the kernel and the running image.
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 skew more than five seconds during the course of a single day's operation. However, NTP servers can get skewed, and sometimes can even be maliciously led astray of the correct time. If you are depending on the correct time for a protocol, you might consider obtaining a clock that synchronizes with a radio time signal, so that you can set up your own time server.
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 you can have them distributed automatically with either NIS or NIS +.[9]
[9] 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.
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 documentation for explicit instructions on how to set up Secure RPC . Nevertheless, this guide may be helpful.
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.
Secure RPC also allows you to create public key/secret key pairs for the superuser account on each host of your network. To do so, type:
# newkey -h hostname
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 the rpc.yp.updated 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 a Solaris 2.X system):
% 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
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 push it.
NOTE: There is a very nasty vulnerability with rpc.ypupdated that allows external users access on servers or clients. See " CERT advisory CA-95:17. rpc.ypupdated.vul."
Once you've gone to all of the trouble of setting up Secure RPC , your next step is to set up Secure NFS . We'll cover this in detail in Chapter 20 . But if you want to go ahead and do it right now, here are the steps to follow for a BSD -derived system such as SunOS; the procedure is the same, but the filenames are different for other systems.
On the file server, edit the /etc/exports file and add the -secure option for every filesystem that should be exported using Secure NFS . For example, suppose the old /etc/exports file exported the mail spool directory /usr/spool/mail with the line:
/usr/spool/mail -access=allws
To make the filesystem be exported using Secure NFS , change the line to read:
/usr/spool/mail -secure,access=allws
After changing /etc/exports , you need to do an exportfs (or equivalent).
You must modify the /etc/fstab file on every workstation that mounts a Secure NFS filesystem to include the secure option as a mount option.
To continue the above example, suppose your workstation mounted the /usr/spool/mail directory with the line:
mailhub:/usr/spool/mail /usr/spool/mail nfs rw,intr,bg 0 0
To mount this filesystem with the secure option, you would change the line to read:
mailhub:/usr/spool/mail /usr/spool/mail nfs rw,intr,bg,secure 00
After changing /etc/fstab, you need to umount and mount the filesystems again.
Using Secure RPC is very similar to using standard RPC . If you log in by typing your username and password (either at the login window on the console or by using telnet or rlogin to reach your machine), 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 rlogin to reach your computer from a trusted machine - you will need to use the keylogin program to have your secret key calculated and stored in the key server. Unfortunately, this will result in your key being sent over the network and makes it subject to eavesdropping.
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
Sun's Secure RPC represents a quantum leap in security over Sun's standard RPC . This is good news for sites that use NFS : with Secure RPC , NFS can be used with relative safety. Nevertheless, Secure RPC it 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.[10]
[10] We said the same thing five years ago, in the first version of this book.
There is a performance penalty . Secure RPC penalizes every RPC transaction that uses it, because the RPC authenticator must be decrypted using DES to verify each transmission. Fortunately, the performance penalty is small: On a Sun-4, only 1.5 milliseconds are required for the decryption. In comparison, the time to complete an average NFS transaction is about 20 milliseconds, making the performance penalty about eight percent.
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 may be 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 become faster, the possibility of a brute force attack against the user's encrypted secret key may become a reality.
In the final analysis, using Secure RPC appears to provide 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 +, some multi-vendor sites have chosen not to use it. These sites should consider DCE , which provides a workable solution for a heterogeneous environment.
|
|
|
|
| 19.2 Sun's Remote Procedure Call (RPC) |
|
19.4 Sun's Network Information Service (NIS) |