Overview of Secure RPC
Secure RPC (Remote Procedure Call) protects remote procedures with an authentication mechanism.The Diffie-Hellman authentication mechanism authenticates both the host and the user who ismaking a request for a service. The authentication mechanism uses Data EncryptionStandard (DES) encryption. Applications that use Secure RPC include NFS and thenaming services, NIS and NIS+.
NFS Services and Secure RPC
NFS enables several hosts to share files over the network. Under the NFSservice, a server holds the data and resources for several clients. Theclients have access to the file systems that the server shares withthe clients. Users who are logged in to the client systems can accessthe file systems by mounting the file systems from the server. Tothe user on the client system, it appears as if the filesare local to the client. One of the most common uses ofNFS allows systems to be installed in offices, while storing all user filesin a central location. Some features of the NFS service, such asthe -nosuid option to the mount command, can be used to prohibitthe opening of devices and file systems by unauthorized users.
The NFS service uses Secure RPC to authenticate users who make requestsover the network. This process is known as Secure NFS. The Diffie-Hellman authenticationmechanism, AUTH_DH, uses DES encryption to ensure authorized access. The AUTH_DH mechanismhas also been called AUTH_DES. For more information, see the following:
To set up and administer Secure NFS, see Administering the Secure NFS System in System Administration Guide: Network Services.
To set up the NIS+ tables and enter names in the cred table, see System Administration Guide: Naming and Directory Services (NIS+).
For an outline of the transactions that are involved in RPC authentication, see Implementation of Diffie-Hellman Authentication.
DES Encryption With Secure NFS
The Data Encryption Standard (DES) encryption functions use a 56-bit key toencrypt data. If two credential users or principals know the same DESkey, they can communicate in private by using the key to encipherand decipher text. DES is a relatively fast encryption mechanism. A DES chipmakes the encryption even faster. However, if the chip is not present,a software implementation is substituted.
The risk of using just the DES key is that an intrudercan collect enough cipher-text messages that were encrypted with the same keyto be able to discover the key and decipher the messages. For thisreason, security systems such as Secure NFS need to change the keysfrequently.
Kerberos Authentication
Kerberos is an authentication system that was developed at MIT. Some encryption inKerberos is based on DES. Kerberos V4 support is no longer suppliedas part of Secure RPC. However, a client-side and server-side implementation ofKerberos V5, which uses RPCSEC_GSS, is included with this release. For more information,see Chapter21, Introduction to the Kerberos Service.
Diffie-Hellman Authentication and Secure RPC
The Diffie-Hellman (DH) method of authenticating a user is nontrivial for anintruder to crack. The client and the server have their own privatekey, which they use with the public key to devise a commonkey. The private key is also known as the secret key. The clientand the server use the common key to communicate with each other.The common key is encrypted with an agreed-upon encryption function, such asDES.
Authentication is based on the ability of the sending system to usethe common key to encrypt the current time. Then, the receiving systemcan decrypt and check against its current time. The time on theclient and the server must be synchronized. For more information, see Managing Network Time Protocol (Tasks) in System Administration Guide: Network Services.
The public keys and private keys are stored in an NIS orNIS+ database. NIS stores the keys in the publickey map. NIS+ storesthe keys in the cred table. These files contain the public keyand the private key for all potential users.
The system administrator is responsible for setting up NIS maps or NIS+ tables,and for generating a public key and a private key for eachuser. The private key is stored in encrypted form with the user'spassword. This process makes the private key known only to the user.
Implementation of Diffie-Hellman Authentication
This section describes the series of transactions in a client-server session thatuse Diffie-Hellman authentication (AUTH_DH).
Generating the Public Keys and Secret Keys for Secure RPC
Sometime prior to a transaction, the administrator runs either the newkey or thenisaddcred command to generate a public key and a secret key. Eachuser has a unique public key and secret key. The public keyis stored in a public database. The secret key is stored in encryptedform in the same database. The chkey command changes the key pair.
Running the keylogin Command for Secure RPC
Normally, the login password is identical to the Secure RPC password. Inthis case, the keylogin command is not required. However, if the passwordsare different, the users have to log in and then run thekeylogin command.
The keylogin command prompts the user for a Secure RPC password. Thecommand then uses the password to decrypt the secret key. The keylogincommand then passes the decrypted secret key to the keyserver program. The keyserveris an RPC service with a local instance on every computer. Thekeyserver saves the decrypted secret key and waits for the user toinitiate a Secure RPC transaction with a server.
If both the login password and the RPC password are the same,the login process passes the secret key to the keyserver. If thepasswords are required to be different, then the user must always runthe keylogin command. When the keylogin command is included in the user's environmentconfiguration file, such as the ~/.login, ~/.cshrc, or ~/.profile file, the keylogincommand runs automatically whenever the user logs in.
Generating the Conversation Key for Secure RPC
When the user initiates a transaction with a server, the following occurs:
The keyserver randomly generates a conversation key.
The kernel uses the conversation key, plus other material, to encrypt the client's timestamp.
The keyserver looks up the server's public key in the public key database. For more information, see the publickey(4) man page.
The keyserver uses the client's secret key and the server's public key to create a common key.
The keyserver encrypts the conversation key with the common key.
Initially Contacting the Server in Secure RPC
The transmission, which includes the encrypted timestamp and the encrypted conversation key,is then sent to the server. The transmission includes a credential anda verifier. The credential contains three components:
The client's network name
The conversation key, which is encrypted with the common key
A “window,” which is encrypted with the conversation key
The window is the difference in time that the client says shouldbe allowed between the server's clock and the client's timestamp. If thedifference between the server's clock and the timestamp is greater than the window,the server rejects the client's request. Under normal circ*mstances, this rejection doesnot happen, because the client first synchronizes with the server before startingthe RPC session.
The client's verifier contains the following:
The encrypted timestamp
An encrypted verifier of the specified window, which is decremented by 1
The window verifier is needed in case somebody wants to impersonate auser. The impersonator can write a program that, instead of filling in theencrypted fields of the credential and verifier, just inserts random bits. Theserver decrypts the conversation key into some random key. The server thenuses the key to try to decrypt the window and the timestamp.The result is random numbers. After a few thousand trials, however, the randomwindow/timestamp pair is likely to pass the authentication system. The window verifierlessens the chance that a fake credential could be authenticated.
Decrypting the Conversation Key in Secure RPC
When the server receives the transmission from the client, the following occurs:
The keyserver that is local to the server looks up the client's public key in the public key database.
The keyserver uses the client's public key and the server's secret key to deduce the common key. The common key is the same common key that is computed by the client. Only the server and the client can calculate the common key because the calculation requires knowing one of the secret keys.
The kernel uses the common key to decrypt the conversation key.
The kernel calls the keyserver to decrypt the client's timestamp with the decrypted conversation key.
Storing Information on the Server in Secure RPC
After the server decrypts the client's timestamp, the server stores four itemsof information in a credential table:
The client's computer name
The conversation key
The window
The client's timestamp
The server stores the first three items for future use. The serverstores the client's timestamp to protect against replays. The server accepts onlytimestamps that are chronologically greater than the last timestamp seen. As a result,any replayed transactions are guaranteed to be rejected.
Note - Implicit in these transactions is the name of the caller, who mustbe authenticated in some manner. The keyserver cannot use DES authentication to authenticatethe caller because the use of DES by the keyserver would createa deadlock. To avoid a deadlock, the keyserver stores the secret keysby user ID (UID) and grants requests only to local root processes.
Returning the Verifier to the Client in Secure RPC
The server returns a verifier to the client, which includes the following:
The index ID, which the server records in its credential cache
The client's timestamp minus 1, which is encrypted by the conversation key
The reason for subtracting 1 from the client's timestamp is to ensurethat the timestamp is out of date. An out-of-date timestamp cannot bereused as a client verifier.
Authenticating the Server in Secure RPC
The client receives the verifier and authenticates the server. The client knowsthat only the server could have sent the verifier because only theserver knows what timestamp the client sent.
Handling Transactions in Secure RPC
With every transaction after the first transaction, the client returns the indexID to the server in its next transaction. The client also sendsanother encrypted timestamp. The server sends back the client's timestamp minus 1,which is encrypted by the conversation key.
