path: root/lib/librpc/secure_rpc/doc/nfs.secure.ms

.\" Must use  --  pic tbl eqn  --   with this one.
.\"
.\" @(#)nfs.secure.ms	2.2 88/08/09 4.0 RPCSRC
.de BT
.if \\n%=1 .tl ''- % -''
..
.ND
.\" prevent excess underlining in nroff
.if n .fp 2 R
.OH 'Secure Networking''Page %'
.EH 'Page %''Secure Networking'
.if \\n%=1 .bp
.EQ
delim $$
gsize 11
.EN
.SH
\&Secure Networking
.nr OF 1
.IX "security" "of networks" "" "" PAGE START
.IX "network security" "" "" "" PAGE START
.IX "NFS security" "" "" "" PAGE START
.LP
RPCSRC 4.0 includes an authentication system
that greatly improves the security of network environments.
The system is general enough to be used by other
.UX
and non-UNIX systems.
The system uses DES encryption and public key cryptography
to authenticate both users and machines in the network.
(DES stands for Data Encryption Standard.)
.LP
Public key cryptography is a cipher system that involves two keys:
one public and the other private.
The public key is published, while the private key is not;
the private (or secret) key is used to encrypt and decrypt data.
Sun's system differs from some other public key cryptography systems
in that the public and secret keys are used to generate a common key,
which is used in turn to create a DES key.
DES is relatively fast,
and on Sun Workstations,
optional hardware is available to make it even faster.
.#
.NH 0
\&Administering Secure RPC
.IX "administering secure RPC"
.IX "security" "RPC administration"
.LP
This section describes what the system administrator must do
in order to use secure networking.
.IP 1
RPCSRC now includes the
.I /etc/publickey
.IX "etc/publickey" "" "\&\fI/etc/publickey\fP"
database, which should contain three fields for each user:
the user's netname, a public key, and an encrypted secret key.
The corresponding Yellow Pages map is available to YP clients as
.I publickey.byname
but the database should reside only on the YP master.  Make sure
.I /etc/netid
exists on the YP master server.
As normally installed, the only user is
.I nobody .
This is convenient administratively,
because users can establish their own public keys using
.I chkey (1)
.IX "chkey command" "" "\&\fIchkey\fP command"
without administrator intervention.
For even greater security,
the administrator can establish public keys for everyone using
.I newkey (8).
.IX "newkey command" "" "\&\fInewkey\fP command"
Note that the Yellow Pages take time to propagate a new map,
so it's a good idea for users to run
.I chkey ,
or for the administrator to run
.I newkey ,
just before going home for the night.
.IP 2
Verify that the
.I keyserv (8c)
.IX "keyserv daemon" "" "\&\fIkeyserv\fP daemon"
daemon was started by
.I /etc/rc.local
and is still running.
This daemon performs public key encryption
and stores the private key (encrypted, of course) in
.I /etc/keystore :
.DS
% \fBps aux | grep keyserv\fP
root   1354  0.0  4.1  128  296 p0 I  Oct 15 0:13 keyserv
.DE
When users log in with
.I login 
.IX "login command" "" "\&\fIlogin\fP command"
or remote log in with
.I rlogin ,
these programs use the typed password to decrypt the secret key stored in
.I /etc/publickey .
This becomes the private key, and gets passed to the
.I keyserv 
daemon.
If users don't type a password for
.I login 
or
.I rlogin ,
either because their password field is empty
or because their machine is in the
.I hosts\fR.\fPequiv 
.IX "etc/hosts.equiv" "" "\&\fI/etc/hosts.equiv\fP"
file of the remote host,
they can still place a private key in
.I /etc/keystore 
by invoking the
.I keylogin (1)
.IX "keylogin command" "" "\&\fIkeylogin\fP command"
program.
Administrators should take care not to delete
.I /etc/keystore 
and
.I /etc/.rootkey 
(the latter file contains the private key for
.I root ).
.IP 3
When you reinstall, move, or upgrade a machine, save
.I /etc/keystore 
and
.I /etc/.rootkey 
along with everything else you normally save.
.LP
.LP
Note that if you
.I login ,
.I rlogin ,
or
.I telnet 
to another machine, are asked for your password, and type it correctly,
you've given away access to your own account.
This is because your secret key is now stored in
.I /etc/keystore
on that remote machine.
This is only a concern if you don't trust the remote machine.
If this is the case,
don't ever log in to a remote machine if it asks for your password.
Instead, use NFS to remote mount the files you're looking for.
At this point there is no
.I keylogout 
command, even though there should be.
.LP
The remainder of this chapter discusses the theory of secure networking,
and is useful as a background for both users and administrators.
.#
.NH 1
\&Security Shortcomings of NFS
.IX "security" "shortcomings of NFS"
.LP
Sun's Remote Procedure Call (RPC) mechanism has proved to be a very 
powerful primitive for building network services.
The most well-known of these services is the Network File System (NFS),
a service that provides transparent file-sharing
between heterogeneous machine architectures and operating systems.
The NFS is not without its shortcomings, however. 
Currently, an NFS server authenticates a file request by authenticating the
machine making the request, but not the user. 
On NFS-based filesystems, it is a simple matter of running
.I su 
.IX "su command" "" "\&\fIsu\fP command"
to impersonate the rightful owner of a file.
But the security weaknesses of the NFS are nothing new. 
The familiar command
.I rlogin 
is subject to exactly the same attacks as the NFS
because it uses the same kind of authentication. 
.LP
A common solution to network security problems
is to leave the solution to each application.
A far better solution is to put authentication at the RPC level.
The result is a standard authentication system
that covers all RPC-based applications,
such as the NFS and the Yellow Pages (a name-lookup service).
Our system allows the authentication of users as well as machines.
The advantage of this is that it makes a network environment
more like the older time-sharing environment.
Users can log in on any machine,
just as they could log in on any terminal. 
Their login password is their passport to network security.
No knowledge of the underlying authentication system is required.
Our goal was a system that is as secure and easy to use
as a time-sharing system. 
.LP
Several remarks are in order.  Given
.I root 
access and a good knowledge of network programming,
anyone is capable of injecting arbitrary data into the network,
and picking up any data from the network.
However, on a local area network, no machine is capable of packet smashing \(en
capturing packets before they reach their destination, changing the contents, 
then sending packets back on their original course \(en
because packets reach all machines, including the server, at the same time.
Packet smashing is possible on a gateway, though,
so make sure you trust all gateways on the network.
The most dangerous attacks are those involving the injection of data,
such as impersonating a user by generating the right packets,
or recording conversations and replaying them later.
These attacks affect data integrity.
Attacks involving passive eavesdropping \(en
merely listening to network traffic without impersonating anybody \(en
are not as dangerous, since data integrity had not been compromised.
Users can protect the privacy of sensitive information
by encrypting data that goes over the network.
It's not easy to make sense of network traffic, anyway.
.#
.NH 1
\&RPC Authentication
.IX "RPC authentication"
.IX "authentication" "RPC"
.LP
RPC is at the core of the new network security system.
To understand the big picture,
it's necessary to understand how authentication works in RPC.
RPC's authentication is open-ended: 
a variety of authentication systems may be plugged into it
and may coexist on the network.
Currently, we have two: UNIX and DES. 
UNIX authentication is the older, weaker system;
DES authentication is the new system discussed in this chapter.
Two terms are important for any RPC authentication system:
.I credentials
and
.I verifiers .
Using ID badges as an example, the credential is what identifies a person:
a name, address, birth date, etc.
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, things are similar.
The client process sends both a credential and a verifier 
to the server with each RPC request.
The server sends back only a verifier,
since the client already knows the server's credentials.
.#
.NH 2
\&UNIX Authentication
.IX "UNIX authentication"
.IX "authentication" "UNIX"
.LP
UNIX authentication was used by most of Sun's original network services.
The credentials contain the client's machine-name, 
.I uid ,
.I gid ,
and group-access-list.
The verifier contains \fBnothing\fP!
There are two problems with this system.
The glaring problem is the empty verifier,
which makes it easy to cook up the right credential using
.I hostname 
.IX "hostname command" "" "\&\fIhostname\fP command"
and
.I su .
.IX "su command" "" "\&\fIsu\fP command"
If you trust all root users in the network, this is not really a problem.
But many networks \(en especially at universities \(en are not this secure.
The NFS tries to combat deficiencies in UNIX authentication 
by checking the source Internet address of
.I mount 
requests as a verifier of the
.I hostname 
field, and accepting requests only from privileged Internet ports.
Still, it is not difficult to circumvent these measures, 
and NFS really has no way to verify the user-ID.
.LP
The other problem with UNIX authentication appears in the name UNIX.
It is unrealistic to assume that all machines on a network
will be UNIX machines.
The NFS works with MS-DOS and VMS machines,
but UNIX authentication breaks down when applied to them.
For instance, MS-DOS doesn't even have a notion of different user IDs.
.LP
Given these shortcomings,
it is clear what is needed in a new authentication system:
operating system independent credentials, and secure verifiers.
This is the essence of DES authentication discussed below.
.#
.NH 2
\&DES Authentication
.IX "DES authentication"
.IX "authentication" "DES"
.LP
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.
Two things are necessary for this scheme to work:
1) the two agents must agree on what the current time is, and
2) the sender and receiver must be using the same encryption key.
.LP
If a network has time synchronization (Berkeley's TEMPO for example), 
then client/server time synchronization is performed automatically.
However, if this is not available,
timestamps can be computed using the server's time instead of network time.
In order to do this, the client asks the server what time it is,
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 rejecting the client's requests,
the DES authentication system just resynchronizes with the server.
.LP
Here's how the client and server arrive at the same encryption key.
When a client wishes to talk to a server, it generates at random 
a key to be used for encrypting the timestamps (among other things). 
This key is known as the
.I "conversation key, CK."
The client encrypts the conversation key using a public key scheme,
and sends it to the server in its first transaction.
This key is the only thing that is ever encrypted with public key cryptography.
The particular scheme used is described further on in this chapter.
For now, suffice to say that for any two agents A and B,
there is a DES key $K sub AB$ that only A and B can deduce.
This key is known as the
.I "common key,"
$K sub AB$.
.EQ
gsize 10
.EN
.ne 1i
.PS
.in +.7i
circlerad=.4
boxht=.2
boxwid=1.3
circle "\s+9A\s-9" "(client)" at 0,1.2
circle "\s+9B\s-9" "(server)" at 5.1,1.2
line invis at .5,2 ; box invis "\fBCredential\fP"; line invis;
	box invis "\fBVerifier\fP"
arrow at .5,1.7; box "$A, K sub AB (CK), CK(win)$"; arrow;
	box "$CK(t sub 1 ), CK(win + 1)$"; arrow
arrow <- at .5,1.4; line right 1.3; line;
	box "$CK(t sub 1 - 1), ID$"; arrow <-
arrow at .5,1; box "ID"; arrow;
	box "$CK(t sub 2 )$"; arrow
arrow <- at .5,.7; line right 1.3; line;
	box "$CK(t sub 2 - 1), ID$"; arrow <-
arrow at .5,.3; box "ID"; arrow;
	box "$CK(t sub n )$"; arrow
arrow <- at .5,0; line right 1.3; line;
	box "$CK(t sub n - 1), ID$"; arrow <-
.PE
.EQ
gsize 11
.EN
.in -.7i
.LP
The figure above illustrates the authentication protocol in more detail,
describing client A talking to server B.
A term of the form $K(x)$ means $x$ encrypted with the DES key $K$.
Examining the figure, you can see that for its first request,
the client's credential contains three things: 
its name $A$, the conversation key $CK$ encrypted with the common key 
$K sub AB$, and a thing called $win$ (window) encrypted with $CK$.
What the window says to the server, in effect, is this:
.LP
.I
I will be sending you many credentials in the future,
but there may be crackers sending them too,
trying to impersonate me with bogus timestamps.
When you receive a timestamp, check to see if your current time
is somewhere between the timestamp and the timestamp plus the window.
If it's not, please reject the credential. 
.LP
For secure NFS filesystems, the window currently defaults to 30 minutes.
The client's verifier in the first request contains the encrypted timestamp
and an encrypted verifier of the specified window, $win + 1$. 
The reason this exists is the following.
Suppose somebody wanted to impersonate A by writing a program
that instead of filling in the encrypted fields of the credential and verifier,
just stuffs in random bits.
The server will decrypt CK into some random DES key,
and use it to decrypt the window and the timestamp.
These will just end up as random numbers.
After a few thousand trials, 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.
.LP
After authenticating the client,
the server stores four things into a credential table:
the client's name A, the conversation key $CK$, the window, and the timestamp.
The reason the server stores the first three things should be clear:
it needs them for future use.
The reason for storing the timestamp is to protect against replays.
The server will only accept timestamps
that are chronologically greater than the last one seen,
so any replayed transactions are guaranteed to be rejected.
The server returns to the client in its verifier an index ID
into its credential table, plus the client's timestamp minus one,
encrypted by $CK$.
The client knows that only the server could have sent such a verifier,
since only the server knows what timestamp the client sent.
The reason for subtracting one from it is to insure that it is invalid
and cannot be reused as a client verifier.
.LP
The first transaction is rather complicated,
but after this things go very smoothly.
The client just sends its ID and an encrypted timestamp to the server,
and the server sends back the client's timestamp minus one,
encrypted by $CK$.
.#
.NH 1
\&Public Key Encryption
.IX "public key encryption"
.LP
The particular public key encryption scheme Sun uses
is the Diffie-Hellman method.
The way this algorithm works is to generate a
.I "secret key"
$SK sub A$ at random
and compute a
.I "public key"
$PK sub A$ using the following formula
($PK$ and $SK$ are 192 bit numbers and \(*a is a well-known constant):
.EQ
PK sub A ~ = ~ alpha sup {SK sub A}
.EN
Public key $PK sub A$ is stored in a public directory,
but secret key $SK sub A$ is kept private.
Next, $PK sub B$ is generated from $SK sub B$ in the same manner as above.
Now common key $K sub AB$ can be derived as follows:
.EQ
K sub AB ~ = ~ PK sub B sup {SK sub A} ~ = ~
( alpha sup {SK sub B} ) sup {SK sub A} ~ = ~
alpha sup {( SK sub A SK sub B )}
.EN
Without knowing the client's secret key,
the server can calculate the same common key $K sub AB$
in a different way, as follows:
.EQ
K sub AB ~ = ~ PK sub A sup {SK sub B} ~ = ~
( alpha sup {SK sub A} ) sup {SK sub B} ~ = ~
alpha sup {( SK sub A SK sub B )}
.EN
Notice that nobody else but the server and client can calculate $K sub AB$,
since doing so requires knowing either one secret key or the other.
All of this arithmetic is actually computed modulo $M$,
which is another well-known constant.
It would seem at first that somebody could guess your secret key
by taking the logarithm of your public one, 
but $M$ is so large that this is a computationally infeasible task.
To be secure, $K sub AB$ has too many bits to be used as a DES key,
so 56 bits are extracted from it to form the DES key.
.LP
Both the public and the secret keys
are stored indexed by netname in the Yellow Pages map
.I publickey.byname
the secret key is DES-encrypted with your login password.
When you log in to a machine, the
.I login 
program grabs your encrypted secret key,
decrypts it with your login password,
and gives it to a secure local keyserver to save
for use in future RPC transactions.
Note that ordinary users do not have to be aware of 
their public and secret keys.
In addition to changing your login password, the
.I yppasswd 
.IX "yppasswd command" "" "\&\fIyppasswd\fP command"
program randomly generates a new public/secret key pair as well.
.LP
The keyserver
.I keyserv (8c)
.IX "keyserv daemon" "" "\&\fIkeyserv\fP daemon"
is an RPC service local to each machine
that performs all of the public key operations,
of which there are only three.  They are:
.DS
setsecretkey(secretkey)
encryptsessionkey(servername, des_key)
decryptsessionkey(clientname, des_key)
.DE
.I setsecretkey()
tells the keyserver to store away your secret key $SK sub A$ for future use;
it is normally called by
.I login .
The client program calls
.I encryptsessionkey()
to generate the encrypted conversation key
that is passed in the first RPC transaction to a server.
The keyserver looks up
.I servername 's
public key and combines it with the client's secret key (set up by a previous
.I setsecretkey()
call) to generate the key that encrypts
.I des_key .
The server asks the keyserver to decrypt the conversation key by calling
.I decryptsessionkey().
Note that 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,
since it would create deadlock. 
The keyserver solves this problem by storing the secret keys by
.I uid ,
and only granting requests to local root processes.
The client process then executes a
.I setuid 
process, owned by root, which makes the request on the part of the client,
telling the keyserver the real
.I uid 
of the client.  Ideally, the three operations described above
would be system calls, and the kernel would talk to the keyserver directly,
instead of executing the
.I setuid 
program.
.#
.NH 1
\&Naming of Network Entities
.IX "naming of network entities"
.IX "network naming"
.LP
The old UNIX authentication system has a few problems when it comes to naming.
Recall that with UNIX authentication,
the name of a network entity is basically the
.I uid .
These
.I uid s
are assigned per Yellow Pages naming domain,
which typically spans several machines.
We have already stated one problem with this system,
that it is too UNIX system oriented, 
but there are two other problems as well.
One is the problem of
.I uid 
clashes when domains are linked together.
The other problem is that the super-user (with
.I uid 
of 0) should not be assigned on a per-domain basis, 
but rather on a per-machine basis.
By default, the NFS deals with this latter problem in a severe manner:
it does not allow root access across the network by
.I uid 
0 at all.
.LP
DES authentication corrects these problems
by basing naming upon new names that we call
.I netnames.
Simply put, a netname is just a string of printable characters,
and fundamentally, it is really these netnames that we authenticate.
The public and secret keys are stored on a per-netname,
rather than per-username, basis.
The Yellow Pages map
.I netid.byname
maps the netname into a local
.I uid 
and group-access-list, 
though non-Sun environments may map the netname into something else.
.LP
We solve the Internet naming problem by choosing globally unique netnames.
This is far easier then choosing globally unique user IDs.
In the Sun environment, user names are unique within each Yellow Page domain.
Netnames are assigned by concatenating the operating system and user ID
with the Yellow Pages and ARPA domain names.
For example, a UNIX system user with a user ID of 508 in the domain
.I eng.sun.COM 
would be assigned the following netname:
.I unix.508@eng.sun.COM .
A good convention for naming domains is to append 
the ARPA domain name (COM, EDU, GOV, MIL) to the local domain name.
Thus, the Yellow Pages domain
.I eng 
within the ARPA domain
.I sun.COM 
becomes
.I eng.sun.COM .
.LP
We solve the problem of multiple super-users per domain
by assigning netnames to machines as well as to users.
A machine's netname is formed much like a user's.
For example, a UNIX machine named
.I hal 
in the same domain as before has the netname
.I unix.hal@eng.sun.COM .
Proper authentication of machines is very important for diskless machines
that need full access to their home directories over the net.
.LP
Non-Sun environments will have other ways of generating netnames, 
but this does not preclude them from accessing
the secure network services of the Sun environment.
To authenticate users from any remote domain,
all that has to be done is make entries for them in two Yellow Pages databases.
One is an entry for their public and secret keys, 
the other is for their local
.I uid 
and group-access-list mapping.
Upon doing this, users in the remote domain
will be able access all of the local network services,
such as the NFS and remote logins.
.#
.NH 1
\&Applications of DES Authentication
.IX "applications of DES authentication"
.IX "authentication" "DES"
.LP
The first application of DES authentication
is a generalized Yellow Pages update service. 
This service allows users to update private fields in Yellow Page databases.
So far the Yellow Pages maps
.I hosts,
.I ethers,
.I bootparams
and
.I publickey
employ the DES-based update service.
Before the advent of an update service for mail aliases,
Sun had to hire a full-time person just to update mail aliases.
.LP
The second application of DES authentication is the most important: 
a more secure Network File System.
There are three security problems with the 
old NFS using UNIX authentication.
The first is that verification of credentials occurs only at mount time
when the client gets from the server a piece of information
that is its key to all further requests: the
.I "file handle" .
Security can be broken if one can figure out a file handle
without contacting the server, perhaps by tapping into the net or by guessing.
After an NFS file system has been mounted,
there is no checking of credentials during file requests,
which brings up the second problem.
If a file system has been mounted from a server that serves multiple clients
(as is typically the case), there is no protection
against someone who has root permission on their machine using
.I su 
(or some other means of changing
.I uid )
gaining unauthorized access to other people's files.
The third problem with the NFS is the severe method it uses to circumvent
the problem of not being able to authenticate remote client super-users: 
denying them super-user access altogether. 
.LP
The new authentication system corrects all of these problems. 
Guessing file handles is no longer a problem since in order to gain 
unauthorized access, the miscreant will also have to guess the right 
encrypted timestamp to place in the credential,
which is a virtually impossible task.
The problem of authenticating root users is solved,
since the new system can authenticate machines.
At this point, however,
secure NFS is not used for root filesystems.
Root users of nonsecure filesystems are identified by IP address.
.LP
Actually, the level of security associated with each filesystem
may be altered by the administrator.  The file
.I /etc/exports 
.IX "etc/exports" "" "\&\fI/etc/exports\fP"
contains a list of filesystems and which machines may mount them. 
By default, filesystems are exported with UNIX authentication,
but the administrator can have them exported with DES authentication
by specifying
.I -secure 
on any line in the
.I /etc/exports 
file.  Associated with DES authentication is a parameter:
the maximum window size that the server is willing to accept.
.#
.NH 1
\&Security Issues Remaining
.IX "security" "issues remaining"
.IX "remaining security issues"
.LP
There are several ways to break DES authentication, but using
.I su 
is not one of them.  In order to be authenticated,
your secret key must be stored by your workstation.
This usually occurs when you login, with the
.I login 
program decrypting your secret key with your login password,
and storing it away for you.
If somebody tries to use
.I su 
to impersonate you, it won't work,
because they won't be able to decrypt your secret key.  Editing
.I /etc/passwd 
isn't going to help them either, because the thing they need to edit, 
your encrypted secret key, is stored in the Yellow Pages.
If you log into somebody else's workstation and type in your password,
then your secret key would be stored in their workstation and they could use
.I su 
to impersonate you.  But this is not a problem since you should not
be giving away your password to a machine you don't trust anyway. 
Someone on that machine could just as easily change
.I login 
to save all the passwords it sees into a file. 
.LP
Not having
.I su 
to employ any more, how can nefarious users impersonate others now?
Probably the easiest way is to guess somebody's password,
since most people don't choose very secure passwords.
We offer no protection against this;
it's up to each user to choose a secure password.
.LP
The next best attack would be to attempt replays.
For example, let's say I have been squirreling away
all of your NFS transactions with a particular server.
As long as the server remains up,
I won't succeed by replaying them since the server always demands timestamps
that are greater than the previous ones seen.
But suppose I go and pull the plug on your server, causing it to crash.
As it reboots, its credential table will be clean,
so it has lost all track of previously seen timestamps,
and now I am free to replay your transactions.
There are few things to be said about this.
First of all, servers should be kept in a secure place
so that no one can go and pull the plug on them.
But even if they are physically secure,
servers occasionally crash without any help.
Replaying transactions is not a very big security problem,
but even so, there is protection against it.
If a client specifies a window size that is smaller than the time it takes
a server to reboot (5 to 10 minutes), the server will reject
any replayed transactions because they will have expired.
.LP
There are other ways to break DES authentication, 
but they are much more difficult.
These methods involve breaking the DES key itself,
or computing the logarithm of the public key,
both of which would would take months of compute time on a supercomputer.
But it is important to keep our goals in mind.
Sun did not aim for super-secure network computing.
What we wanted was something as secure as a good time-sharing system,
and in that we have been successful.
.LP
There is another security issue that DES authentication does not address, 
and that is tapping of the net.
Even with DES authentication in place, 
there is no protection against somebody watching what goes across the net.
This is not a big problem for most things,
such as the NFS, since very few files are not publically readable, and besides,
trying to make sense of all the bits flying over the net is not a trivial task.
For logins, this is a bit of a problem because you wouldn't 
want somebody to pick up your password over the net.
As we mentioned before,
a side effect of the authentication system is a key exchange, 
so that the network tapping problem can be tackled on a per-application basis.
.#
.NH 1
\&Performance
.IX "performance of DES authentication"
.IX "authentication" "performance"
.LP
Public key systems are known to be slow,
but there is not much actual public key encryption going on in Sun's system.
Public key encryption only occurs in the first transaction with a service,
and even then, there is caching that speeds things up considerably.
The first time a client program contacts a server,
both it and the server will have to calculate the common key.
The time it takes to compute the common key is basically the time it takes
to compute an exponential modulo $M$.
On a Sun-3 using a 192-bit modulus, this takes roughly 1 second, 
which means it takes 2 seconds just to get things started,
since both client and server have to perform this operation.
This is a long time,
but you have to wait only the first time you contact a machine.
Since the keyserver caches the results of previous computations, 
it does not have to recompute the exponential every time.
.LP
The most important service in terms of performance is the secure NFS,
which is acceptably fast.
The extra overhead that DES authentication requires versus UNIX authentication 
is the encryption.
A timestamp is a 64-bit quantity,
which also happens to be the DES block size.
Four encryption operations take place in an average RPC transaction:
the client encrypts the request timestamp, the server decrypts it,
the server encrypts the reply timestamp, and the client decrypts it.
On a Sun-3, the time it takes to encrypt one block is about
half a millisecond if performed by hardware,
and 1.2 milliseconds if performed by software.
So, the extra time added to the round trip time is about 
2 milliseconds for hardware encryption and 5 for software.
The round trip time for the average NFS request is about 20 milliseconds,
resulting in a performance hit of 10 percent if one has encryption hardware, 
and 25 percent if not.
Remember that this is the impact on network performance.
The fact is that not all file operations go over the wire,
so the impact on total system performance will actually be lower than this.
It is also important to remember that security is optional, 
so environments that require higher performance can turn it off.
.#
.NH 1
\&Problems with Booting and \&\fBsetuid\fP Programs
.IX "problems with booting and \&\fIsetuid\fP programs"
.IX "booting and \&\fIsetuid\fP problems"
.LP
Consider the problem of a machine rebooting,
say after a power failure at some strange hour when nobody is around.
All of the secret keys that were stored get wiped out,
and now no process will be able to access secure network services,
such as mounting an NFS filesystem.
The important processes at this time are usually root processes,
so things would work OK if root's secret key were stored away, 
but nobody is around to type the password that decrypts it.
The solution to this problem is to store root's decrypted secret key in a file,
which the keyserver can read.
This works well for diskful machines that can store the secret key
on a physically secure local disk,
but not so well for diskless machines,
whose secret key must be stored across the network.
If you tap the net when a diskless machine is booting,
you will find the decrypted key.
This is not very easy to accomplish, though.
.LP
Another booting problem is the single-user boot.
There is a mode of booting known as single-user mode, where a
.I root 
login shell appears on the console.
The problem here is that a password is not required for this. 
With C2 security installed,
a password is required in order to boot single-user.
Without C2 security installed,
machines can still be booted single-user without a password,
as long as the entry for
.I console 
in the
.I /etc/ttytab 
.IX "etc/ttytab" "" "\&\fI/etc/ttytab\fP"
file is labeled as physically
.I secure 
(this is the default).
.LP
Yet another problem is that diskless machine booting is not totally secure.
It is possible for somebody to impersonate the boot-server,
and boot a devious kernel that, for example, 
makes a record of your secret key on a remote machine.
The problem is that our system is set up to provide 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.
We don't consider this a serious problem,
because it is highly unlikely that somebody would be able to write
this funny kernel without source code.
Also, the crime is not without evidence.
If you polled the net for boot-servers, 
you would discover the devious boot-server's location.
.LP
Not all
.I setuid 
programs will behave as they should.
For example, if a 
.I setuid 
program is owned by
.I dave ,
who has not logged into the machine since it booted,
then the program will not be able to access any secure network services as
.I dave .
The good news is that most
.I setuid 
programs are owned by root, 
and since root's secret key is always stored at boot time, 
these programs will behave as they always have.
.#
.NH 1
\&Conclusion
.IX "network security" "summary"
.LP
Our goal was to build a system as secure as a time-shared system. 
This goal has been met.
The way you are authenticated in a time-sharing system
is by knowing your password.
With DES authentication, the same is true.
In time-sharing the person you trust is your system administrator,
who has an ethical obligation
not to change your password in order to impersonate you.
In Sun's system, you trust your network administrator,
who does not alter your entry in the public key database.
In one sense, our system is even more secure than time-sharing,
because it is useless to place a tap on the network
in hopes of catching a password or encryption key, 
since these are encrypted.
Most time-sharing environments do not encrypt data emanating from the terminal;
users must trust that nobody is tapping their terminal lines.
.LP
DES authentication is perhaps not the ultimate authentication system. 
In the future it is likely there will be sufficient advances 
in algorithms and hardware to render the public key system
as we have defined it useless.
But at least DES authentication offers a smooth migration path for the future.
Syntactically speaking,
nothing in the protocol requires the encryption of the conversation 
key to be Diffie-Hellman, or even public key encryption in general. 
To make the authentication stronger in the future,
all that needs to be done is to strengthen the way
the conversation key is encrypted. 
Semantically, this will be a different protocol,
but the beauty of RPC is that it can be plugged in
and live peacefully with any authentication system.
.LP
For the present at least, DES authentication satisfies our requirements
for a secure networking environment.
From it we built a system secure enough for use in unfriendly networks,
such as a student-run university workstation environment.
The price for this security is not high.
Nobody has to carry around a magnetic card or remember
any hundred digit numbers.
You use your login password to authenticate yourself, just as before.
There is a small impact on performance,
but if this worries you and you have a friendly net,
you can turn authentication off.
.#
.NH 1
\&References
.IX "references on network security"
.LP
Diffie and Hellman, ``New Directions in Cryptography,''
\fIIEEE Transactions on Information Theory IT-22,\fP
November 1976.
.LP
Gusella & Zatti, ``TEMPO: A Network Time Controller
for a Distributed Berkeley UNIX System,''
\fIUSENIX 1984 Summer Conference Proceedings,\fP
June 1984.
.LP
National Bureau of Standards, ``Data Encryption Standard,''
\fIFederal Information Processing Standards Publication 46,\fP
January 15, 1977.
.LP
Needham & Schroeder, ``Using Encryption for Authentication
in Large Networks of Computers,''
\fIXerox Corporation CSL-78-4,\fP
September 1978.
.EQ
delim off
.EN
.IX "security" "of networks" "" "" PAGE END
.IX "network security" "" "" "" PAGE END
.IX "NFS security" "" "" "" PAGE END