Managing NFS and NIS, 2nd Edition - Mike Eisler [169]
Planning a transition from NFS/sys to stronger NFS security
Perhaps you've been exporting filesystems with sec=sys (the default if sec= is not specified) for some time, and now decide to start using better NFS security, such as NFS/dh or Kerberized NFS. One issue is that it takes less time to reconfigure servers to use stronger NFS security than to reconfigure clients, because there are more client machines, and more user ids than host ids to add to the various tables that RPC/DH and Kerberos V5 require. Also, some NFS client implementations may not be running Solaris 8, and may support the stronger NFS security that you decide to switch to. So even after you get your servers reconfigured to use Kerberos V5 security, it won't be practical to simply change:
share -o rw /export/home
to:
share -o sec=krb5,rw /export/home
and not expect some chaos. That you can combine any two or more sec= options on the same dfstab entry allows you to stage some graceful transitions.
For example, suppose you've decided to use NFS/dh. You may have some legacy software running on some NFS clients that is stuck on older systems. Thus you can't upgrade the client systems to an operating system that can support stronger NFS security. You can do the following:
share -o sec=sys,rw=legacy-group,sec=dh,rw=upgrade-group /export/home
such that the legacy machines and upgrade machines are each placed in their own netgroup.
NFS security futures
In Section 12.5.2.2, we mentioned the RSA public key algorithm, but did not talk about any NFS security that uses RSA. RSA is arguably the best asymmetric key encryption algorithm known to us. It is the foundation of most Public Key Infrastructure (PKI) products, as well as networking protocols like SSL/TLS and S/MIME. So why doesn't NFS use it? The main issue with RSA is that it was patented and so royalties were due to its rights holders. Now that the patent has expired, expect to see the following features in the future:
Asymmetric key technology integrated with Kerberos V5. Without asymmetric key technology, a physical compromise of the KDC effectively compromises all of the principals listed in KDC, as it stores each user's symmetric key. With asymmetric key technology, only the public key needs to be stored in the KDC.
The NFS Version 4 protocol specifies an SSL-like GSS-API mechanism provider called LIPKEY as one of the two required security providers to RPCSEC_GSS (Kerberos V5 being the other). LIPKEY uses asymmetric key algorithms. So when NFS Version 4 is deployed widely, expect to see RSA used to secure it. Like SSL, LIPKEY can be easily used through a firewall.
The poor performance of krb5p (Table 12-2) is due largely to the fact that DES is a very slow algorithm. There are faster, not to mention more secure, algorithms, but many of them are proprietary, subject to royalties. The royalty free Advanced Encryption Standard (AES) has been selected to replace DES. AES is faster and more secure than DES. Expect to see future versions of NFS run over Kerberos V5 and LIPKEY using AES as the encryption algorithm.
* * *
[4] For brevity, we don't describe how a secret key and a message are combined, nor how the one-way hash function is applied. Unless you are a skilled cryptographer, you should not attempt to invent your own scheme. Instead, use the algorithm described in RFC2104.
[5] If you are not running NIS or NIS+, you can still create keys, and use NFS/dh with the publickey entry in nsswitch.conf set to files. You will need to set up an NIS domain name on each NFS client and server (see Section 3.2.4 for how to set up a domain name on a host). You will also have to devise a means for keeping all the /etc/publickey files on each client and server synchronized, since the encrypted private key field must change every time the user's password changes.
[6] This appraisal is the opinion of one of the