|
|
The Network File System (NFS), originally designed by Sun, provides access to shared resources in client-server style, where users can log into a client system and access file systems by mounting the file systems from a server. As a result, files would appear to be local to the client. The Secure NFS service uses Secure RPC—which protects remote procedures with an authentication mechanism— to authenticate users who make requests to the service. The authentication mechanism (Diffie- Hellman) uses Data Encryption Standard (DES) encryption to encrypt the common key between client and server with a 56-bit key. Although more secure authentication services are available for use with Sun Solaris, in this section we'll be discussing Secure RPC across NFS. For more information on Solaris encryption services, refer to Chapter 11.
Authentication is based on the ability of the sending system to use the common key to encrypt the current time. Then the receiving system can decrypt and check against its current time. The time on the client and the server must be synchronized. The public keys and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map. NIS+ stores the keys in the cred table. These files contain the public key and 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 each user. The private key is stored in encrypted form with the user's password. This process makes the private key known only to the user.
| Exam Watch |
The authentication mechanism (Diffie-Hellman) uses Data Encryption Standard (DES) encryption to encrypt the common key between client and server with a 56-bit key. |
Sometimes, prior to a transaction, the administrator runs either the newkey or the nisaddcred command to generate a public key and a secret key. Each user has a unique public key and secret key. The public key is stored in a public database, while the secret key is stored in encrypted form in the same database. The chkey command changes the key pair.
Normally, the login password is identical to the Secure RPC password. In this case, the keylogin command is not required. However, if the passwords are different, the users must log in and then run the keylogin command.
The keylogin command prompts the user for a Secure RPC password. The command then uses the password to decrypt the secret key. The command passes the decrypted secret key to the keyserver program, an RPC service with a local instance on every computer. The keyserver saves the decrypted secret key and waits for the user to initiate 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 the passwords are required to be different, the user must always run the keylogin command. When the command is included in the user's environment configuration file, such as the ~/.login, ~/.cshrc, or ~/.profile file, the command runs automatically whenever the user logs in.
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.
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.
The transmission, which includes the encrypted timestamp and the encrypted conversation key, is then sent to the server. The transmission includes a credential and a verifier. The credential contains three components: the client's network name; the conversation key, which is encrypted with the common key; and a window, which is encrypted with the conversation key.
The window is the difference in time that the client says should be allowed between the server's clock and the client's timestamp. If the difference between the server's clock and the timestamp is greater than the window, the server rejects the client's request. Under normal circumstances, this rejection does not happen, because the client first synchronizes with the server before starting the RPC session.
The client's verifier contains the encrypted timestamp and an encrypted verifier of the specified window (which is decremented by 1). The window verifier is needed in case somebody wants to impersonate a user. The impersonator can write a program that, instead of filling in the encrypted fields of the credential and verifier, just inserts random bits. The server decrypts the conversation key into some random key. The server then uses the key to try to decrypt the window and the timestamp. The result is random numbers. After a few thousand trials, however, the random window/timestamp pair is likely to pass the authentication system. The window verifier lessens the chance that a fake credential could be authenticated.
Decrypting the Conversation Key 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.
After the server decrypts the client's timestamp, the server stores four items of 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, and it stores the client's timestamp to protect against replays. The server accepts only timestamps that are chronologically greater than the last timestamp seen. As a result, any replayed transactions are guaranteed to be rejected.
| Exam Watch |
You should also know the decryption process of a conversation key after the server receives a transmission from the client. Remember that the keyserver looks up the client's public key in the public key database and uses the client's public key and the server's secret key to deduce the common key. The kernel then uses the common key to decrypt the conversation key, and it calls the keyserver to decrypt the client's timestamp with the decrypted conversation key. |
Returning the Verifier to the Client and Authenticating the Server The server returns a verifier to the client, including the index ID, which the server records in its credential cache, and the client's timestamp minus 1, which is encrypted by the conversation key. The 1 is subtracted from the client's timestamp to ensure that the timestamp is out of date. An out-of-date timestamp cannot be reused as a client verifier.
The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier, because only the server knows what timestamp the client sent.
With every transaction after the first transaction, the client returns the index ID to the server in its next transaction. The client also sends another encrypted timestamp. The server sends back the client's timestamp minus 1, which is encrypted by the conversation key.
By requiring authentication for use of mounted NFS file systems, you increase the security of your network. In this section, we'll discuss procedures to configure Secure RPC for NIS, NIS+, and NFS.
To restart the secure RPC keyserver, you need to assume the Primary Administrator role or become superuser. The Primary Administrator role includes the Primary Administrator profile. Next, verify that the keyserv daemon is running with the command ps -ef | grep keyserv to get output such as this:
root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv
Next, if the daemon is not running, start the keyserver with this command: /usr/sbin/keyserv
This procedure should be done on every host in the NIS+ domain:
Assume the Primary Administrator role, or become superuser.
Enable the publickey table in the name service by adding the following line to the /etc/nsswitch.conf file:
publickey: nisplus
Initialize the NIS+ client with this command:
nisinit -cH hostname
where hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client system.
Add the client to the cred table with the commands nisaddcred local and nisaddcred des.
Verify the setup by using the keylogin command. If you are prompted for a password, the procedure was successful.
This procedure should be done on every user in the NIS+ domain:
Assume the Primary Administrator role, or become superuser.
Add the user to the cred table on the root master server with the following command:
nisaddcred -p unix.UID@domain-name -P username.domain-name. des
Note that, in this case, the username.domain-name must end with a dot (.).
Verify the setup by logging in as the client and typing the keylogin command.
This procedure should be done on every host in the NIS domain:
Assume the Primary Administrator role, or become superuser.
Enable the publickey map in the name service by adding the following line to the /etc/nsswitch.conf file: publickey: nis
Create a new key pair by using the newkey command: newkey -h hostname; where hostname is the name of the client.
This procedure should be done for every user in the NIS domain. Only system administrators, when logged in to the NIS master server, can generate a new key for a user.
Assume the Primary Administrator role, or become superuser.
Create a new key for a user:
newkey -u username
The system prompts for a password. You can type in a generic password. The private key is stored in an encrypted form by using the generic password.
Tell the user to log in and type the chkey-p command. This command allows users to re-encrypt their private keys with a password known only to the user.
Note: The chkey command can be used to create a new key pair for a user.
This procedure protects shared file systems on an NFS server by requiring authentication for access. Before you begin, Diffie-Hellman public key authentication must be enabled on the network.
Become superuser, or assume a role that includes the System Management profile.
Share a file system with Diffie-Hellman authentication:
share -F nfs -o sec=dh /filesystem
where filesystem is the file system that is being shared. The -o sec=dh option means that AUTH_DH authentication is now required to access the file system.
Following is how an NFS client mounts a file system that is protected with Diffie- Hellman authentication:
Become superuser, or assume a role that includes the System Management profile.
Mount a file system with Diffie-Hellman authentication:
mount -F nfs -o sec=dh server:filesystem mount-point
where
server is the name of the system that is sharing file system.
filesystem is the name of the file system that is being shared, such as opt.
mount-point is the name of the mount point, such as /opt.
The -o sec=dh option mounts the file system with AUTH_DH authentication.
| Exam Watch |
By requiring authentication for use of mounted NFS file systems, you increase the security of your network. |
|
|