diff options
Diffstat (limited to 'lib/librpc/secure_rpc/doc')
| -rw-r--r-- | lib/librpc/secure_rpc/doc/Makefile | 40 | ||||
| -rw-r--r-- | lib/librpc/secure_rpc/doc/nfs.secure.ms | 934 |
2 files changed, 974 insertions, 0 deletions
diff --git a/lib/librpc/secure_rpc/doc/Makefile b/lib/librpc/secure_rpc/doc/Makefile new file mode 100644 index 0000000..3cfbe9e --- /dev/null +++ b/lib/librpc/secure_rpc/doc/Makefile @@ -0,0 +1,40 @@ +# +# @(#)Makefile 2.1 88/08/10 4.0 RPCSRC +# +# +TROFF= ditroff +TOPTS= -t +NROFF= nroff +NOPTS= +PIC= pic +TBL= tbl +EQN= eqn + +SRC= nfs.secure.ms + +all default: all.nroff + +install: all.nroff + @echo "Nothing installed." + +all.nroff: ${SRC} + ${TBL} ${SRC} | ${EQN} | ${NROFF} ${NOPTS} -ms >all.nroff + +all.troff: ${SRC} + ${TBL} ${SRC} | ${PIC} | ${EQN} | ${TROFF} ${TOPTS} -ms >all.troff + +# + +nfs.secure.nroff: nfs.secure.ms + ${TBL} nfs.secure.ms | ${EQN} | ${NROFF} ${NOPTS} -ms >nfs.secure.nroff + +nfs.secure.troff: nfs.secure.ms + ${TBL} nfs.secure.ms|${PIC}|${EQN}| ${TROFF} ${TOPTS} -ms >nfs.secure.troff + +clean: + rm -f *.nroff *.troff + +spell: ${SRC} + @for i in ${SRC}; do \ + echo $$i; spell $$i | sort | comm -23 - spell.ok > $$i.spell; \ + done diff --git a/lib/librpc/secure_rpc/doc/nfs.secure.ms b/lib/librpc/secure_rpc/doc/nfs.secure.ms new file mode 100644 index 0000000..2476790 --- /dev/null +++ b/lib/librpc/secure_rpc/doc/nfs.secure.ms @@ -0,0 +1,934 @@ +.\" 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 |
