Managing NFS and NIS, 2nd Edition - Mike Eisler [164]
It uses a 192-bit modulus for its public and private keys. In 1987, 192 bits was appropriate because for larger sizes, it was found that common key generation took several minutes to complete on Motorola 68010 processors, which were still used in a significant number of Sun's installed base of systems. However, by 1990, advances in RISC processors produced workstation machines that could, by brute force, derive the private key from any public key in under a day.
It uses only a 48-bit shared secret key for encrypting the session key. This can be brute forced in less than a day as well.
Recall the discussion about requiring users to do a keylogin if they are using rlogin between trusted hosts. The point of rlogin with trusted hosts is to avoid constant password challenges. Also, the more times the same password is entered, the more opportunity for someone to look over your shoulder (or to eavesdrop on the network) to see it.
RPC/DH does a better job of authentication than AUTH_SYS, but there is no support for integrity or privacy. It is obvious why privacy is desirable, but why is integrity so important to NFS? Say we are using NFS/dh, and our attacker in the middle intercepts a request to read a particular file. He prevents the read from proceeding. However, he takes the RPC/DH header, and concatenates it with a new NFS request to write the same file (this is known as a splicing attack). As we discussed earlier in Section 12.5.2.4, this would not be possible if RPC/DH had integrity services.
It's impossible to extend RPC/DH to fix the above issues.
For these reasons, many security experts will tell you that NFS/dh is waste of time to deploy, even though the successful attacks on NFS/dh require the attacker to have much more sophistication than that needed to attack NFS over AUTH_SYS. If you understand the risks and you are comfortable with the security offered by one more of:
NIS
DNS (that is, DNS without DNSSEC)
NFS over AUTH_SYS
Transparent security discussed earlier in Section 12.1
Password-based security such as what imap, telnet, and ftp offer
then you ought to be comfortable with RPC/DH. If you aren't comfortable with any of the above, including RPC/DH, then you should be running a very secure combination of directory service and file service. One combination would be NIS+ with enhanced DH security, as mentioned in Section 12.2 earlier in this chapter, and Kerberized NFS as described in the next section.
RPCSEC_GSS: Generic security services for RPC
The previous section described a complete security system for NFS and RPC, and the subsection Section 12.5.4.10 discusses its flaws. Sun decided to develop a new RPC security flavor that would address the problems, with one added feature: it would be infinitely extendable, so that key size limitations, and problems with cryptographic algorithms (cryptographers are constantly finding problems with various algorithms) would not slow development of new security mechanisms.
The new security flavor is called RPCSEC_GSS. Note that it does not have the AUTH_ prefix like AUTH_SYS and AUTH_DH. This is because it provides integrity and privacy services in addition to authentication.
RPCSEC_GSS is based on the Generic Security Services API (GSS-API). GSS-API provides the ability to write applications that can authenticate clients and servers, integrity protect the messages they exchange, and also privacy protect the messages they exchange. GSS-API also permits one to "plug in" different security mechanisms or providers without changing the application that uses GSS-API. Figure 12-2 depicts the GSS-API multiplex applications that are consumers of GSS-API, and mechanisms that are providers for GSS-API.
Figure 12-2. GSS-API architecture
RPCSEC_GSS leverages GSS-API capabilities to provide authentication, integrity, and privacy if the security mechanism provider supports those services. Currently Kerberos V5 is the mostly widely deployed GSS-API security provider, and it does support all three services. NFS over RPCSEC_GSS can use Kerberos V5's