Managing NFS and NIS, 2nd Edition - Mike Eisler [163]
There's one thing missing: how does the root, or host, private key get decrypted? You establish a session key using the host key for the NFS server. In order for the server to exchange keys with you, it must be able to decrypt the host's private key, and this requires the root password or a "hidden" copy of the root key. One obvious approach is to force someone to supply the root password when the machine boots, so that the host private key in the publickey map can be decrypted and given to the keyserv daemon. However, this is often too restrictive: if an NFS server boots and no system administrator is present to supply the root password, no NFS/dh services will be available.
You can solve this dilemma by using the -r option to keylogin to store the host's private key in the protected /etc/.rootkey file of the NFS server. Note that this is not the root password; it's the large, random number used as the host's private key. When the keyserv daemon starts up, it reads the host's key out of this file so that clients of the host can establish session keys with it.
A similar issue applies to the NFS client when you are using the automounter to access NFS mounted filesystems. Unless the superuser has logged into the system, and thus manually established his private key into keyserv, users will not be able use the automounter to access filesystems exported with sec=dh. Once again, you use keylogin -r, this time running it on the NFS client. When the keyserv daemon starts up, it reads the host's key out of this file so that the automounter can establish session keys on NFS servers.
NFS/dh checklist
This list summarizes what you need to do to create the various daemons and files that must be in place for proper operation of NFS/dh:
Create keys for users with chkey or newkey -u. Create a host key for each machine on which you need secure root access using newkey -h.
Make sure the NIS master server is running rpc.ypupdated.
Push the publickey map to all NIS slaves after making any changes to it, so that NFS/dh is operating before the next NIS map transfer.
Establish a /etc/.rootkey file on every NFS server and client via keylogin -r.
If you are using NFS/dh on trusted hosts, make sure that users perform a keylogin to produce a temporary private key. If users do not supply a password when they log into a host, the local keyserv process on that host must be given the user's private key explicitly. Also, have users add keylogout to their .logout files to remove the temporary keys given to keyserv.
Ensure that each client that is using NFS/dh is running the keyserv daemon.
To export a filesystem using NFS/dh, add the sec=dh option to its entry in /etc/dfs/dfstab. On NFS Version 2 clients, mount the filesystem with the sec=dh option in the mount options field of the automounter map or /etc/vfstab.
Finally, make sure that your client and server clocks remain well-synchronized (see Section 14.7 for a simple scheme). Since NFS/dh uses encrypted timestamps for validation, drifting client clocks may cause the server to reject otherwise valid NFS/dh requests because they appear to be replays of out-of-date requests. The NFS server code has a small window for checking client timestamps, and if the clock drift falls within this window, the RPC call is executed.
On Solaris 8, the default window size is five minutes (300 seconds). If you are serious about using NFS/dh, you will probably want to leave this window unchanged. However, you can change it to a different value, by modifying the authdes_win tunable parameter in the /etc/system file:
* 10 minutes
set rpcsec:authdes_win = 600
You can also set it on a live system without rebooting by:
# echo
authdes_win/W 0t600
| adb -k -w
authdes_win: 0x12c = 0x258
The shorter the window, the less time a would-be network spoofer has to attempt to replay any request, but on the other hand, the less clock drift you can tolerate.
How secure is RPC/DH?
RPC/DH is flawed for several