13.2 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. 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.
13.2.1 Secure RPC Authentication
Secure RPC authentication is based on the
Diffie-Hellman
exponential key exchange system. Each Secure
RPC principal 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.
13.2.1.1 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:
- 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. 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.
13.2.1.2 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.
13.2.1.3 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.)
13.2.2 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+.
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.
|
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.
|
|
13.2.2.1 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.
13.2.2.2 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
13.2.2.3 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.
|
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.
|
|
13.2.3 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
13.2.4 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.
- 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.
|