Managing NFS and NIS, 2nd Edition - Mike Eisler [168]
Like krb5 and krb5i, krb5p uses Kerberos V5 to authenticate. Like krb5i it uses Kerberos V5 to provide integrity. Unlike krb5 and krb5i, krb5p uses Kerberos V5's DES encryption to provide privacy. Note that only the NFS arguments and results are encrypted; the RPC headers go in the clear. So an attacker could deduce which NFS operation is being performed, but not on what file, nor what the file or directory content is.
Security and performance
So, why wouldn't a client want to always mount with krb5p ? It is, after all, the most secure of sec= options we've seen in this book. The reason is that as soon as you involve cryptography in data processing, you slow down the processing. This is because cryptography tends to be a highly CPU-bound function. Consider the performance results in Table 12-2. The NFS client and server were each running Solaris 8 with SEAM. Both the systems were Sun Ultra 5 systems, each with 128 megabytes of RAM, and one 270 Mhz CPU. A 200 megabyte file was written from the client to the server to the server's /tmp file system, via the mkfile utility. NFS Version 3 over TCP was used. As we can see from Table 12-2, the krb5 option does not cost much to use relative to sys. But krb5i and krb5p added increasingly significant overhead. Some people have the reasonable perspective that drop off in throughput is not as important as the increased CPU utilization.
Table 12-2. Kerberized NFS performance
sec= value
Throughput in MB/sec
Throughput Degradation Relative to sec=sys
Percent CPU Utilization on Server
sys
5.40
N/A
69%
krb5
5.26
2.6%
70%
krb5i
4.44
17.7%
77%
krb5p
1.45
73.1%
99%
Combining krb5, krb5i, krb5p
You can combine the krb5 * options with each other.
Let's suppose /export/home on server labrador contains the home directories of security conscious folks, though some are less paranoid than others. You can accommodate everyone by adding the following to /etc/dfs/dfstab:
share -o sec=krb5p:krb5i:krb5,rw /export/home
This means the clients pick any of the three flavors of krb5 when they mount the NFS filesystem. Note that this is one instance where even if the client is using NFS Version 3, that the administrator on the client may want to specify a sec= option in their automounter maps or vfstab or on their mount command line. The reason is that the client (at least the Solaris 8 client) will pick from the array of security flavors that mountd returns the first security flavor that the client supports. So if a client prefers krb5 but krb5p is first, sec= is needed for the mount command to override the automatic choice.
Given the results in Table 12-2, you might want to be careful about exporting filesystems with krb5i or krb5p security enabled. If you have data that can go in the clear on the network, then never export it with krb5p. If your users are writing data over the network, and very bad things could happen if an attacker spliced the RPC header from a sec=krb5 NFS request onto a forged set of destructive arguments, then enable krb5i. Otherwise krb5 should be sufficient. Indeed, for certain kinds of read-only data, sec=sys or sec=none are fine.
IPSec versus krb5i and krb5p
As discussed earlier in Section 12.5.3, IPSec can provide integrity (AH) and privacy (ESP) services. If you are enabling AH and ESP then do you need to use krb5i or krb5p ? Note that the session keys for AH and ESP are derived from per-host keys, whereas the session keys for krb5i and krb5p are derived from per user keys. If you are paranoid about attacks on hosts to find the IPSec keys, then you'll want to run krb5i and krb5p in addition to AH and ESP. However, it will cost you double in CPU utilization to do so. In general, it is not necessary to use krb5i if AH is used, and not necessary to use