Can a Nfs Secuirty Be Used Over Again

12.5. Stronger security for NFS

The security mechanisms described so far in this

chapter are essentially refinements of the standard Unix login/countersign and file permission constraints, extended to handle distributed environments. Some additional care is taken to restrict superuser access over the network, merely nothing in RPC'due south AUTH_SYS authentication protocol ensures that the user specified past the UID in the credential structure is permitted to use the RPC service, and nix verifies that the user (or user running the application sending RPC requests) is really who the UID professes to be. Just checking user credentials is like giving out employee badges: the bluecoat holder is given certain access rights. Someone who is not an employee could steal a badge and gain those same rights. Validating the user credentials in an NFS request is similar to making employees wear badges with their photographs on them: the badge grants certain admission rights to its holder, and the photograph on the bluecoat ensures that the bluecoat holder is the "right" person. Stronger RPC security mechanisms than AUTH_SYS exist, which add together credential validation to the standard RPC system. These stronger mechanisms can be used with NFS. We will talk over 2 of the stronger RPC security mechanisms bachelor with Solaris eight, AUTH_DH, and RPCSEC_GSS. Both mechanisms rely on cryptographic techniques to achieve stronger security.

12.5.i. Security services

Before we depict AUTH_DH and RPCSEC_GSS, we volition explain the notion of security services, and which services RPC provides. Security isn't a monolithic concept, but among others, includes notions like authorization, auditing, and compartmentalization. RPC security is concerned with four services: identification, authentication, integrity, and privacy. Identification is merely the name RPC gives to the client and the server. The customer'due south name usually corresponds to the UID. The server's proper name normally corresponds to the hostname. Authentication is the service that proves that the client and server are who they identify themselves to be. Integrity is the service that ensures the letters are non tampered with, or at least ensures that the receiver knows they have been tampered with. Privacy is the service that prevents eavesdropping.

12.5.2. Brief introduction to cryptography

Before we describe how the AUTH_DH and RPCSEC_GSS mechanisms work, we will explain some of the general principles of cryptography that apply to both mechanisms. A complete treatment of the topic tin be institute in the book Applied Cryptography, by Bruce Schneier (John Wiley and Sons, Inc., 1996). There are four general cryptographic techniques that are pertinent: symmetric key encryption, asymmetric key encryption, public key exchange, and i way hash functions.

12.v.two.2. Asymmetric cardinal encryption

Asymmetric central encryption involves the use of a public key to encrypt a secret value, such as a symmetric key, and, a private key to decrypt the aforementioned value. A public key and private key are associated every bit a pair. I one-half of the pair gets generated from the other via a serial of arithmetic operations. The private key is never equal to the public central, hence the term asymmetric. As the names advise, the public key is well-known to anybody, whereas the private primal is known only to its possessor. This helps solve the problem of getting a secret key on both hosts. You choose a symmetric secret primal, encrypt information technology with the server'southward public key, send the result to the server and the server decrypts the secret fundamental with its own private fundamental. The clandestine key tin and so exist used to encrypt a value like a timestamp, which the server validates past decrypting with the shared hole-and-corner key. Alternatively, we could have encrypted the timestamp value with the server's public key, sent it to the server, and allow the server decrypt it with the server's private fundamental. Even so, disproportionate key encryption is usually much slower than symmetric primal encryption. So, typically software that uses asymmetric key encryption uses symmetric central encryption once the shared surreptitious key is established The public key is published so that it is available for authentication services. The encryption mechanism used for asymmetric schemes typically uses a diversity of exponentiation and other arithmetic operators that take dainty commutative properties. The encryption algorithm is complex plenty, and the keys themselves should be big enough (at to the lowest degree 1024 bits), to guarantee that a public fundamental can't exist decoded to notice its respective private primal. Asymmetric cardinal encryption is as well called public fundamental encryption. An case of an asymmetric key encryption is RSA.

12.five.ii.four. Ane-way hash functions and MACs

A ane-mode hash part takes a cord of octets of any length and produces a stock-still width value called the hash. The function is designed such that given the hash, information technology is hard to detect the string used equally input to the ane-way hash function, or for that matter, any string that produces the same hash effect. Let'southward say y'all and the server have established a common symmetric secret key using one of the iii previously mentioned techniques. You at present want to transport a message to the server, but desire to brand sure an assailant in the middle cannot tamper with the message without the server knowing. What yous tin do is first combine your message with the secret central (you don't have to encrypt your message with the hugger-mugger key), and and so take this combination and apply the one style hash part to information technology.

[22] This computation is called a message hallmark code or MAC. Then ship both the MAC and the message (not the combination with the secret central) to the server. The server can and so verify that you sent the message, and non someone who intercepted information technology past taking the message, combining it with the shared hole-and-corner cardinal in the same fashion you did, and calculating the MAC. If the server'southward computed MAC is the same equally the MAC you sent, the server has verified that you lot sent it.

[22]For brevity, we don't draw how a secret central and a message are combined, nor how the i-style hash function is practical. Unless you are a skilled cryptographer, you lot should not attempt to invent your ain scheme. Instead, use the algorithm described in RFC2104.

Even though your message and MAC are sent in the articulate to the server, an attacker in the eye cannot change the message without the server knowing it because this would change the effect of the MAC computation on the server. The attacker can't modify the MAC to match a tampered message considering he doesn't know the secret central that only the server and you lot know. An example of a one-way hash function is MD5. An case of a MAC algorithm is HMAC-MD5. Notation that when you add together a MAC to a message y'all are

enabling the

security service of integrity.

12.5.three. NFS and IPSec

IPSec is the standard protocol for

security at the IP network level. With IPSec y'all tin can beef upwardly your trusted host relationships with stiff cryptography. IPSec was invented by the Net Technology Task Force (IETF) to

deal with three issues:

• Attackers are becoming quite adept at spoofing IP addresses. The attacker targets a host to victimize. The victim shares some resources (such as NFS exports) to just a specific set of clients and uses the source IP address of the client to check access rights. The attacker selects the IP accost of i of these clients to masquerade as. Sometimes the assaulter is lucky, and the client is down, and so this is not too hard. Or the assaulter has to accept some steps such as disabling a router or loading the targeted customer. If the assaulter fails, you might see messages like:

  IP: Hardware address '%s' trying to be our address %south!

  or:

  IP: Proxy ARP trouble?  Hardware accost '%due south' thinks it is %s

  on the legitimate client's panel. In one case the legitimate client is disabled, the attacker then changes the IP accost on a automobile that he controls to that of the legitimate customer and can then access the victim.
• An aggressor that controls a gateway can easily engineer attacks where he tampers with the IP packets.
• Finally, if the Cyberspace is to exist a tool enabling more collaboration between organizations, and then there needs to exist a manner to add together privacy protections to sensitive traffic.

Hither is what IPSec can do:

• Via per-host keys, allows hosts to authenticate each other. This frustrates IP spoofing attacks.
• Using a session key derived from per-host keys as input to a MAC, protects the integrity of IP traffic to frustrate packet tampering.
• Using a session fundamental, encrypts all the information in the IP bundle to frustrate eavesdropping.

The first ii capabilities are provided past the AH (Authentication Header) feature of IPSec. The all three capabilities are provided by the ESP (Encapsulating Security Payload) feature of IPSec. Many systems, including Solaris viii, have IPSec support. We won't become into the details of how to fix IPSec. Withal, we will betoken out that IPSec tin can be a useful tool to improve the security of your NFS environs:

• If yous use the AH feature, then all NIS lookups are safety from tampering on the NIS server, or the NIS traffic. So the assaulter cannot fool your NFS server into believing that client gonzo has IP address 192.four.five.6, instead of 10.1.2.3.
• Enabling AH on NFS clients and servers prevents attackers from spoofing the clients yous list on servers' rw=, ro=, and root= lists.
• ESP used on the NFS customer and server makes operating through firewalls safer when accessing sensitive data.

While IPSec is useful for securing NFS, because its security is host based, it does not protect your network from attackers that log onto your IPSec-protected hosts and assume the identity of other users. The discussions of AUTH_DH and RPCSEC_GSS that follow address this effect.

12.5.4. AUTH_DH: Diffie-Hellman authentication

AUTH_DH is an RPC security flavor that uses encryption techniques to better on AUTH_SYS.

12.five.four.1. Old terms: AUTH_DES, secure RPC, and, secure NFS

AUTH_DH was originally called AUTH_DES, and indeed, you'll detect that most documentation of AUTH_DH still calls information technology AUTH_DES. However, the _DES function of the name is a misnomer. While the DES algorithm is used in AUTH_DH, equally we will see later, it is the Diffie-Hellman algorithm that is central to the workings of the AUTH_DH. We will not refer to AUTH_DES again. When AUTH_DH is combined with RPC, the combination is often referred to as "Secure RPC." When RPC, and AUTH_DH are combined with NFS, the outcome is frequently referred to every bit "Secure NFS." However, in the 13 years since AUTH_DH was invented, two things have occurred:

• AUTH_DH is no longer considered secure by many security experts. After y'all read the cloth on AUTH_DH, you might concur.
• RPCSEC_GSS, a stronger, more secure security flavor for RPC is now available with Solaris 8 and other NFS implementations.

We will non use the terms "Secure RPC" or "Secure NFS" again, since they are disruptive. Instead, we will utilise RPC/DH and NFS/dh to refer to RPC secured with AUTH_DH, and NFS secured with RPC/DH, respectively.

12.5.4.2. Diffie-Hellman key substitution

AUTH_DH uses Diffie-Hellman public cardinal commutation. Using this encryption scheme, RPC tin can be fabricated more secure past requiring each client to found a valid common key before making RPC requests to the server. Diffie-Hellman key exchange relies on each agent that wants to establish a common key to agree on 2 pieces of data beforehand. For AUTH_DH these pieces are:

• A base of operations for the exponentiation part of the adding. AUTH_DH uses a base of three.
• A modulus used for the remainder office of the calculation. AUTH_DH uses a modulus of 0xd4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b. Let's label this constant as AUTH_DH_MOD.

Allow PRIV_C exist the individual cardinal of the client. Then the public cardinal of the customer is:

(1) PUBLIC_C = ( 3                    PRIV_C                    ) mod                    AUTH_DH_MOD

Let PRIV_S be the private primal of the server. Then the public key of the server is:

(2) PUBLIC_S = ( three                    PRIV_S                    ) mod                    AUTH_DH_MOD

The customer computes a common cardinal between the client and server as:

(3) COMMON_C_S = ( PUBLIC_S                    PRIV_C                    ) mod                    AUTH_DH_MOD

The server computes the mutual cardinal between the server and client equally:

(iv) COMMON_S_C = ( PUBLIC_C                    PRIV_S                    ) mod AUTH_DH_MOD

To show that COMMON_C_S equals COMMON_S_C, we replace PUBLIC_S in statement (three) with the expression it was derived from in argument (2) and driblet the MOD part of the expression. We practice the same for PUBLIC_C in statement (four) with the expression from argument (2):

(3.1) COMMON_C_S_PRIME = ( three                    PRIV_S                    )PRIV_C =                    3                    PRIV_S * PRIV_C                    (4.i) COMMON_S_C_PRIME = ( three                    PRIV_C                    )PRIV_S =                    iii                    PRIV_C * PRIV_S                                      

Because multiplication is a commutative functioning, information technology is obvious that COMMON_C_S_PRIME equals COMMON_S_C_PRIME. Therefore, COMMON_C_S equals COMMON_S_C.

12.5.four.3. How RPC/DH works

RPC/DH uses a combination of Diffie-Hellman cardinal exchange and DES encryption. User validation is performed by the server, based on information in the RPC request. The customer and server make up one's mind on the mutual primal via the Diffie-Hellman algorithm discussed previously in

Department 12.v.4.two, "Diffie-Hellman central substitution". The common key will be used to construct a shared secret DES central. Note that because AUTH_DH_MOD is 192 bits, the common fundamental will be 192 $.25. However, DES uses 64 bit keys, such that the low society bit of each octet is a parity fleck, making DES effectively a 56-bit symmetric key algorithm. AUTH_DH deals with this by selecting the middle 64 bits of the mutual cardinal. These 64 bits are split into eight octets. Parity is added to the depression club bit of each octet. In addition the high social club bit of each octet is unused, making this effectively a 48-flake shared secret primal.

The kickoff time the customer contacts the server, it generates a random session fundamental, and encrypts it with the shared secret DES key. The session key is besides a DES primal. The customer too generates a time-to-live value (in seconds) chosen the window, and a window value that is one second less than the first window value. The 2 window values are encrypted with the session fundamental. The encrypted session primal and the encrypted window values are sent to the server. The server tin can decrypt the encrypted session cardinal because it knows the common central, and therefore the shared secret DES key. With the session key, information technology can decrypt the window values. If the second window value is non 1 less than the first, the server knows something odd is going on, and it rejects the customer'due south request.

The kickoff fourth dimension, and on every subsequent contact to the server, the customer encrypts the current fourth dimension using the session fundamental. It sends its RPC request to the server.

The server decrypts the timestamp, using the same session key, and verifies that it is accurate. If the decrypted timestamp falls outside of the fourth dimension to live window, the server rejects the request.

So far we've described how RPC/DH does authentication. We will now wait at how identity works in RPC/DH. Recall that AUTH_SYS sends a UID, GID, and a list of supplementary GIDs. The first time RPC/DH contacts the server to found the session key, it sends no UIDs or GIDs. Instead it sends a string, chosen a netname, which identifies two items:

• The user (albeit, the username is a UID expressed in ASCII-decimal)
• The domain name of the user (usually this is an NIS domain proper noun)

The server does iii things with the netname:

• Locates an NIS server serving the specified domain that knows nearly the user.
• Looks up the user's netname in the NIS netid map for the user'due south UID, GID, and list of supplementary groups.
• Looks up the user'south netname in the NIS publickey map for the user'southward Diffie-Hellman public primal. With that, and the server's private cardinal, the server tin can determine the common key, then the shared cloak-and-dagger primal, then decrypt the session key, and employ that to verify that the request came from a user corresponding to the netname.

Past the way, observe that AUTH_DH doesn't have the "too many groups" problem of AUTH_SYS that was discussed in Section 12.4.ane, "RPC security", since no GID list

is sent on the wire.

12.v.four.five. Enabling NFS/dh

Enabling NFS/dh on a filesystem is quite unproblematic: export and mount the filesystem with the sec=dh option. On the NFS server, the /etc/dfs/dfstab entry looks similar this:

share -o sec=dh,rw /export/dwelling house/thud

When a filesystem is exported with the sec=dh option, clients using NFS Version 2 must mount it with the sec=dh selection if they are to enjoy normal user access privileges in the filesystem. On the NFS customer, add the sec=dh selection in the automounter map entry, or the /etc/vfstab entry for the filesystem:

                    automounter auto_home entry:                    thud                     -sec=dh          bonk:/consign/dwelling house/thud                    vfstab entry:                    bonk:/export/home/thud - /thud nfs  - no  sec=dh,rw                  

If the client is using NFS Version 3, information technology volition use Version 3 of the MOUNT protocol. Mount Version 3 will render the RPC security flavor that the directory is exported with, along with the filehandle of the directory. Thus, with NFS Version three, the sec=dh mountoption is not necessary. If a user accessing the filesystem can generate a session key with the NFS server, it is used to encrypt the timestamps sent with that user's NFS requests. If the server decrypts the timestamps successfully, the netname presented by the user is trusted and is used to derive normal Unix-mode credentials for the purpose of file access. Information technology'south possible, though, that the user tin't exchange a session primal with the server. This will be the case if the user doesn't have a public fundamental defined, or if the user cannot supply the proper private key to generate a common key using Diffie-Hellman key commutation. When at that place is no valid common key, some NFS servers remap the user to nobody. However, by default, Solaris 8 rejects such users. If you want to give such users bearding access you can export the filesystem with the following line in /etc/dfs/dfstab :

share -o sec=dh:none,rw /export/habitation/thud

Inside the NFS/dh system, a user without a valid public/private central pair becomes an anonymous user on the NFS server and is subject to the same admission restrictions (discussed earlier in this chapter) that utilize to the bearding user nobody. To utilize NFS/dh without impairing a user'south ability to exercise work, you must ascertain public and individual central pairs for trusted users and trusted hosts.

12.5.4.6. Public and individual keys

Public and private keys are

maintained in the publickey.byname NIS map, which is built from /etc/publickey on the master NIS server.[23] The only cardinal that is defined by default is i for nobody, which is required for the anonymous user mapping. Public and encrypted secrets keys are contained in the /etc/publickey file, along with a unique identifier for the car or user owning these keys.

[23]If you lot 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. Y'all will need to gear up upward an NIS domain name on each NFS client and server (see Section 3.2.4, "Enabling NIS on customer hosts" for how to set up up a domain name on a host). Y'all volition also accept to devise a means for keeping all the /etc/publickey files on each client and server synchronized, since the encrypted private fundamental field must alter every time the user's countersign changes.

unix.10461@nesales publickey:privatekey

The keys are long strings of hexadecimal digits, representing the encrypted key values. Patently, the NIS map cannot contain the actual individual keys, or the entire encryption mechanism would be baseless. Instead, the /etc/publickey file's private primal field contains the user's private cardinal, encrypted with the user'southward login password. For host entries, the private key is encrypted using the root password. The private keys themselves are large random numbers, just like the session key that is used by RPC/DH.

Identifiers in /etc/publickey are chosen netnames and have one of two forms:

unix.uid@NISdomain  unix.host@NISdomain

The first course is used for user keys; information technology defines a primal valid in the current NIS domain. The host key is used to create a RPC/DH fundamental for the superuser on the named host. No user primal is required for root -- only a host key.

The /etc/publickey file is changed past the RPC/DH utilities that create and manage key values. Because it contains encrypted key strings, it is not hands edited past the superuser, simply every bit the password fields in /etc/passwd cannot be mitt-edited. The publickey file should exist only on the NIS master server, or else users' individual keys will become out of engagement when they change their passwords (and therefore alter the

encryption key used to store their private keys).

12.5.4.seven. Creating keys

The superuser tin can add

user

keys (on the NIS master server) using newkey -u user. Equally root, run newkey with the user's login name:

nismaster#                                          newkey -u stern                                        Adding new key for unix.1461@nesales.Due east.Sun.COM.  Enter stern'due south login password:

The countersign is used to encrypt the individual central so that it can be safely placed in the publickey maps. Unfortunately, the user's existing password in the NIS passwd maps must be supplied, requiring you to know the user's password. This is fine if you are adding the user to passwd map anyhow; he is therefore a new user. However, it is very inconvenient if you are calculation NFS/dh security and take a big puddle of existing users because:

• You could change every user'due south login password to the aforementioned value. The trouble with that is that for a catamenia of time every user has the aforementioned password, and yous can expect that some of your users will take malicious reward of that.
• You could change every user's login countersign to a unique value. The problem with that is you lot accept to somehow deeply go the new passwords to each user. Unless you have a secure e-mail organization like PGP or Southward/MIME installed that pretty much leaves you to walk to every user's office or telephone them. That yous are because NFS/dh suggests that you accept a big user base. This is but not practical.

Hopefully, a futurity version of Solaris will fix this so that you lot can supply whatsoever password to newkey. The mode it would piece of work is that you'd use the same RPC/DH password to encrypt every private key via newkey. You'd tell your users what the RPC/DH password is, and they would each use chkey -p (more on chkey later) to alter the RPC/DH password to match their login countersign. Once all the users had done the chkey, you'd then offset exporting NFS filesystems with NFS/dh. Yous cannot achieve the ideal, just you can come up close. What you lot tin can practise is create a template user login, with a unique UID (let's use 66666 for this instance) and GID, and assign it a countersign that you intend to publish to all your users. Brand sure that template has a shell of /dev/zippo in the passwd map, then that no one tin log in as template. At present create keys for template :

nismaster#                                          newkey -u template                                        Adding new key for unix.66666@nesales.East.Sun.COM.  Enter template's login password:

If you look at the /etc/publickey on host nismaster you lot should see something like:

unix.66666@nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51

The netname of template is unix.66666@nesales.Eastward.Sun.COM. Each of your users will have a similar netname, except for the number between the unix prefix, and the @nesale.East.Sun.COM suffix. The last long hexadecimal number after the colon (:) is user template 'south private primal, encrypted with template 'southward login password. Now for each user, make a copy of template 'southward entry in the /etc/publickey file, but alter the netname to match the user. Let'due south say that your set of users is stern, labiaga, and mre, with UIDs of 1461, 15124, and 23154, respectively. You then edit the /etc/publickey file to wait like:

unix.66666@nesales.Due east.Lord's day.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51 unix.                      1461                    @nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51 unix.                      15124                    @nesales.East.Sunday.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51 unix.                      23514                    @nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51

You lot now want to push the publickey file changes into the publickey NIS maps:

nismaster#                                          cd /var/yp                                        nismaster#                                          make publickey                                        updated publickey pushed publickey

You have at present almost effortlessly fully populated the publickey maps, but each entry has the same public central, same individual key, and the aforementioned password. This is not what you want for the long term. So now you lot tell your users to expend some effort. Each user should be told to:

• Change his or her RPC/DH password that the individual fundamental is encrypted with (changing the password to the user'south login password is recommended).
• Change his or her public and private key.

Hither are the instructions we give to each user:

client%                                          chkey -p                                                              Updating nis publickey database. Reencrypting cardinal for 'unix.1461@nesales.Eastward.Dominicus.COM'. Delight enter the Secure-RPC countersign for stern: Delight enter the login password for stern: Sending key change request to nismaster ...  client%                                          chkey                                        Updating nis publickey database. Generating new key for 'unix.1461@nesales.Due east.Dominicus.COM'. Please enter the Secure-RPC password for stern: Sending key change asking to nismaster ...

The first chkey control invocation reencrypts his private fundamental with his login password. The 2nd chkey invocation generates a brand new and unique private key and public key pair. If the user supplies an invalid password, no password or fundamental will be created. If the user's countersign is valid, and the NIS master server is receiving fundamental updates, the key will be added to, or modified in, the NIS publickey maps. Both the chkey and newkey utilities update the /etc/publickey file on the NIS master server. To ensure that your users are following the chkey instructions, you can check the publickey.byname map to meet if both the private key and the public fundamental fields of each user take changed, past comparing them to that of the user template. The only way to create host keys (for superuser verification) is to use newkey -h as root :

#                                          newkey -h bitatron                                        Adding new key for unix.bitatron@nesales.East.Sunday.COM.  New password:

You must create a host key for every NFS customer (and so that the client can mountain filesystems shared with sec=dh) and NFS server (and so that the server tin can generate the common fundamental). To receive NIS map updates from newkey or chkey, the primary NIS server must be able to run rpc.ypupdated. On Solaris 8, this daemon is started equally function of the /usr/lib/netsvc/yp/ypstart script, which in plough is started by the /etc/init.d/rpc boot script. On every auto that will exist using NFS/dh, make certain you lot are running the keyserv daemon. This process is used to enshroud private and common keys, and is besides started out of /etc/init.d/rpc with lines of the course:

if [ -10 /usr/sbin/keyserv -a \       -n "'/usr/bin/domainname 2>/dev/null'" ]; then        /usr/sbin/keyserv >/dev/msglog 2>&1        repeat " keyserv\c" fi

As you tin see, keyserv will not start if there is no domain name established. Make sure keyserv can start, or you will non be able to create session keys, fifty-fifty if y'all take a valid public and private key pair in the publickey NIS maps.

12.5.4.8. Establishing a session key

When you log into a machine that is running NFS/dh, the password you lot supply to login is used to attempt to decrypt your encrypted private fundamental (in the publickey map). If the login and RPC/DH passwords do not match you go errors like:

Password does not decrypt hush-hush cardinal (type = 192-0) for 'unix.23514@nesales.East.Dominicus.COM'. Password does not decrypt any hole-and-corner keys for unix.23514@nesales.East.Dominicus.COM.

The private cardinal is given to the keyserv daemon, which caches information technology for generating common keys. The mutual keys are used to substitution session keys with NFS servers, as described before in this department. Therefore, the entire session key generation procedure goes like this:

1. You define a public and private key pair, using newkey or chkey. The individual key is a large, random number; it is stored in the publickey map by encrypting it with your password.
2. When you log into a motorcar, your password is used to decrypt your individual key. The private primal is given to the keyserv daemon, where information technology is buried until you log out.
3. To access an NFS filesystem mounted with the sec=dh option, you must establish a common primal with the NFS server. You class a common primal using your individual key and the public key for the NFS server. This is done automatically by the RPC/DH organization.
4. From the mutual key, you derive a shared hole-and-corner cardinal past taking a subset of the bits of the common key. This secret cardinal is used to encrypt a randomly generated session key, which is passed to the NFS server. All of your NFS requests to that server contain a timestamp encrypted with the session cardinal. The server decrypts this timestamp to validate your NFS requests.

Notation that you must supply your login countersign for the keyserv daemon to be given your private key. If you don't supply a password when you log into a machine -- for example, you lot rlogin to another machine -- so there is no mode for the keyserv daemon to automatically receive your decrypted private key. To establish a session key in this situation, utilize the keylogin utility, which accepts your login password and uses it to decrypt your individual key:

remote%                                          keylogin                                        Password:

Note that if your login and RPC/DH passwords are different, whether you utilize rlogin or not, you must utilize keylogin to permit keyserv to see your private cardinal. Or else you can utilise chkey -p to modify your RPC/DH password to your login countersign. Keys that are decrypted via keylogin are also passed to keyserv, where they remain until the user executes a keylogout. If you are going to be logging into nontrusted hosts, use keylogin to decrypt your key, and add keylogout to your .logout file (in your home directory) so that your primal is destroyed when you log out. You must reference the NIS passwd map in order for the automatic private key caching to occur. For proper operation of NFS/dh, practice not put users in the local file /etc/passwd, or their encrypted private keys may become out-of-engagement when they change their local passwords just do not alter the NIS-managed password used to encrypt the private cardinal in the publickey map. On the NIS master server, make sure y'all use an alternate countersign source file, instead of the default /etc/passwd. In that location's 1 thing missing: how does the root, or host, individual key get decrypted? You establish a session key using the host key for the NFS server. In guild for the server to exchange keys with you, it must exist able to decrypt the host's private primal, and this requires the root password or a "hidden" copy of the root key. I obvious approach is to force someone to supply the root countersign when the machine boots, so that the host individual key in the publickey map can be decrypted and given to the keyserv daemon. However, this is oft also restrictive: if an NFS server boots and no organisation administrator is nowadays to supply the root password, no NFS/dh services volition exist available. You tin can solve this dilemma by using the -r option to keylogin to store the host'south private key in the protected /etc/.rootkey file of the NFS server. Note that this is non the root countersign; it'due south the large, random number used equally the host's private key. When the keyserv daemon starts upward, information technology reads the host's key out of this file then that clients of the host can found session keys with information technology. 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 organisation, and thus manually established his private primal into keyserv, users will not exist able utilise the automounter to access filesystems exported with sec=dh. In one case again, you use keylogin -r, this time running information technology on the NFS client. When the keyserv daemon starts up, it reads the host's fundamental out of this file so that the automounter can establish session keys on NFS servers.

12.5.4.9. NFS/dh checklist

This listing summarizes what you demand to do to create the diverse daemons and files that must be in place for proper functioning of NFS/dh:

1. Create keys for users with chkey or newkey -u. Create a host fundamental for each auto on which you need secure root access using newkey -h.
2. Make certain the NIS main server is running rpc.ypupdated.
3. Button 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.
4. Establish a /etc/.rootkey file on every NFS server and client via keylogin -r.
5. If yous are using NFS/dh on trusted hosts, make certain that users perform a keylogin to produce a temporary private fundamental. If users do non supply a password when they log into a host, the local keyserv process on that host must exist given the user's private key explicitly. Also, have users add keylogout to their .logout files to remove the temporary keys given to keyserv.
6. Ensure that each client that is using NFS/dh is running the keyserv daemon.
7. To export a filesystem using NFS/dh, add together the sec=dh pick to its entry in /etc/dfs/dfstab. On NFS Version 2 clients, mountain the filesystem with the sec=dh option in the mountain options field of the automounter map or /etc/vfstab.

Finally, make certain that your client and server clocks remain well-synchronized (see

Section 14.vii, "Time synchronization" for a uncomplicated scheme). Since NFS/dh uses encrypted timestamps for validation, globe-trotting client clocks may cause the server to reject otherwise valid NFS/dh requests because they appear to exist replays of out-of-date requests. The NFS server code has a modest window for checking customer timestamps, and if the clock drift falls inside this window, the RPC telephone call is executed.

On Solaris 8, the default window size is five minutes (300 seconds). If you are serious about using NFS/dh, y'all volition probably want to get out this window unchanged. However, y'all can modify it to a dissimilar value, by modifying the authdes_win tunable parameter in the /etc/system file:

* ten minutes set rpcsec:authdes_win = 600

You tin also set it on a live system without rebooting past:

#                                          echo                                                              authdes_win/W 0t600                                                              | adb -k -w                                                              authdes_win:    0x12c  =  0x258                                      

The shorter the window, the less fourth dimension a would-exist network spoofer has to endeavor to replay any request, but on the other hand, the less clock drift you tin

tolerate.

12.v.iv.ten. How secure is RPC/DH?

RPC/DH is flawed for several reasons:

• Information technology uses a 192-bit modulus for its public and private keys. In 1987, 192 $.25 was appropriate because for larger sizes, information technology was found that mutual cardinal generation took several minutes to complete on Motorola 68010 processors, which were still used in a pregnant number of Sun'due south installed base of systems. Notwithstanding, past 1990, advances in RISC processors produced workstation machines that could, by brute strength, derive the private key from any public key in under a day.
• It uses merely a 48-bit shared surreptitious key for encrypting the session central. This tin can be brute forced in less than a day every bit well.
• Recollect 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 than times the same password is entered, the more opportunity for someone to expect over your shoulder (or to eavesdrop on the network) to run across information technology.
• RPC/DH does a ameliorate job of authentication than AUTH_SYS, simply in that location is no support for integrity or privacy. It is obvious why privacy is desirable, merely why is integrity then important to NFS? Say we are using NFS/dh, and our aggressor in the centre intercepts a request to read a particular file. He prevents the read from proceeding. Even so, he takes the RPC/DH header, and concatenates information technology with a new NFS request to write the aforementioned file (this is known as a splicing attack). As we discussed earlier in Department 12.5.2.4, "One-way hash functions and MACs", this would not be possible if RPC/DH had integrity services.
• It's impossible to extend RPC/DH to fix the in a higher place problems.

For these reasons, many security experts volition tell you that NFS/dh is waste product of time to deploy, fifty-fifty 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 sympathize 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 before in Section 12.ane, "User-oriented network security"
• Password-based security such as what imap, telnet, and ftp offer

and then you ought to be comfortable with RPC/DH. If you aren't comfortable with any of the to a higher place, including RPC/DH, then you should exist running a very secure combination of directory service and file service. 1 combination would be NIS+ with enhanced DH security, as mentioned in Department 12.two, "How secure are NIS and NFS?" before in this chapter, and Kerberized NFS as described in the next

section.

12.5.5. RPCSEC_GSS: Generic security services for RPC

The previous section described a complete

security arrangement for NFS and RPC, and the subsection Section 12.5.4.x, "How secure is RPC/DH?" discusses its flaws. Sun decided to develop a new RPC security flavor that would accost 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 non slow development of new security mechanisms.

The new security flavor is chosen 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 improver 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 as well privacy protect the messages they exchange. GSS-API likewise permits i to "plug in" different security mechanisms or providers without changing the application that uses GSS-API. Effigy 12-ii depicts the GSS-API multiplex applications that are consumers of GSS-API, and mechanisms that are providers for GSS-API.

Effigy 12-ii. GSS-API architecture

RPCSEC_GSS leverages GSS-API capabilities to provide authentication, integrity, and privacy if the security machinery provider supports those services. Currently Kerberos V5 is the more often than not widely deployed GSS-API security provider, and it does back up all iii services. NFS over RPCSEC_GSS can apply Kerberos V5'southward capabilities. At the fourth dimension this volume was written:

• Solaris (2.6, vii, and 8) was the only known Unix operating system offer an NFS implementation that supported Kerberos V5 security.
• At to the lowest degree two PC/NFS implementations -- Hummingbird's Maestro, and Netmanage'due south Interdrive -- supported Kerberos V5 security.

12.v.v.1. Kerberos V5

The Kerberos V5 arrangement was adult at the Massachusetts Institute of Technology. It is another mechanism for enforcing security within a service, but it differs from RPC/DH in several means:

• Kerberos uses multiple levels of DES encryption to exchange keys and passwords. No public primal encryption is used.
• A Key Distribution Heart (KDC ) is required to maintain Kerberos V5 service passwords; this server must be kept safe from assault to preserve the integrity of the Kerberos system. RPC/DH uses the publickey map, which is available to all NIS clients. The data in the publickey map is encrypted using user'south login passwords, non an additional RPC/DH password.
• Kerberos V5 authentication is built into the entire service, or application, non just into the session layer. For example, you lot can use Kerberos to make the line printer spooling daemon secure. Doing so, however, requires the source lawmaking to the line printer software.
• Kerberos V5 has the notion of forwardable credentials. Think back to earlier in this chapter (see Section 12.v.4.8, "Establishing a session key") when nosotros talked about rlogin, transparent access, and the fact that when using NFS/dh, you notwithstanding had to provide a password to keylogin fifty-fifty though (or rather, because) rlogin didn't prompt for one. Kerberos V5 has replacements for programs like rlogin and telnet that work like that which they supervene upon, but also back up some actress features:
  • Kerberos V5 is used to authenticate the user, non passwords.
  • Traffic betwixt the client and server is optionally encrypted as a way to provide privacy protection.
  • Credentials can be forwarded from the customer to the server. This feature, known as a forwardable ticket granting ticket, allows the following sequence of events:
    1. The user logs into his desktop machine. He is prompted for his Unix login password, which besides happens to be his Kerberos V5 password. This results in a ticket granting ticket (TGT) being sent from the KDC to his desktop. His home directory is NFS-mounted merely exported with Kerberos V5 security (sec=krb5).
    2. The NFS filesystem uses the TGT to go an NFS service ticket from the KDC, which allows the user to be authenticated to the NFS server. The service ticket is encrypted with the NFS server'southward cardinal, which both the KDC and the NFS server know almost. The NFS server can decrypt the service ticket from the client because the server stores the server's primal in its /etc/krb5/krb5.keytab file, which is analogous to RPC/DH's /etc/.rootkey file.
    3. The user now wishes to log onto a remote organisation. He uses a Kerberized version of rlogin to practice so, passing a control-line option that indicates that he wants his TGT to be forwarded.
    4. The NFS filesystem on the remote organization must do an NFS mount of the user'due south home directory, which is all the same exported with sec=krb5. It needs an NFS service ticket to authenticate the user to the NFS server. Because the TGT has been forwarded, no password prompt to the user is necessary. Thus the user, having authenticated himself one time when he logged into his desktop, can roam freely and securely amidst the network, as he did in the days when the network was using simple host-based trust for rlogin and NFS.

12.5.5.2. SEAM: Kerberos V5 for Solaris

Sun'south Kerberos V5 implementation is chosen Sun Enterprise Authentication Mechanism (SEAM). For this affiliate to completely explain how to fix SEAM for running Kerberos V5 and NFS secured with Kerberos V5, it would accept to include as much textile as was written in this chapter about NIS and NFS/dh, and all the chapters leading up to information technology. In other words, the title of this book would be Managing NIS, Kerberos V5, and NFS. Fortunately, the SEAM documentation is well-written, and the installation fairly turnkey.

[24] Thus it is not articulate that much value could be added in this book to explain minutiae of SEAM.

[24]This appraisement is the opinion of 1 of the co-authors of this book, Mike Eisler, who was the project pb for SEAM while employed by Sun Microsystems, Inc.

However, the remainder of this department collects some practical overview information on SEAM that you might find useful every bit you approach the issue of deploying Kerberos V5. SEAM 1.0 is available for Solaris 2.6 and Solaris 7, and is packaged with the Solaris Like shooting fish in a barrel Access Server (SEAS) 3.0 production, which is unbundled from Solaris 2.6 and Solaris seven. If you lot bought a server from Sunday, you lot might find SEAS 3.0 preinstalled. At the time this book was written, SEAM one.0.1 was bachelor for Solaris 8 every bit a gratis download from Sun's website. Look for the production called Solaris 8 Admin Pack. Do non attempt to run SEAM i.0 on Solaris 8. If you upgrade to Solaris 8 from a Solaris two.6 or Solaris 7 system that has SEAM 1.0 installed, so you should immediately install SEAM 1.0.1. SEAM i.0 and SEAM 1.0.i rely on a GUI-based installation engineering science that is similar to Installshield for Windows systems. What you do not want to practice is go alee and install SEAM without reading the documentation. A couple of notes:

• SEAM 1.0 comes on the SEAS 3.0 CD-ROM. Install the SEAS 3.0 documentation kickoff, and read through the SEAM i.0 documentation.
• SEAM 1.0.1 is role of the Solaris 8 Admin Pack, and at the time this book was written, the only way to go SEAM i.0.1 was to download information technology. Yous tin download SEAM i.0.one separately from the remainder of the Admin Pack. Even so, exist warned that it comes in a self-extracting beat out script, otherwise known every bit a shar file; the term shar stands for shell archive. The shar file proceeds to run the GUI installer, and the installer does not let you install the documentation offset, considering it doesn't take the documentation. Instead, you kickoff need to download the documentation separately (which includes all the documentation of the Admin Pack, so it is a large download). In one case you've downloaded the documentation, start reading it. There is also documentation on SEAM in the Solaris 8 administration documents. It is worth reading this too.

Note that the SEAS three.0 and Admin Pack documentation are packaged in the grade of spider web pages. Equally you read the SEAM documentation, information technology should be clear that SEAM and NIS plus RPC/DH share some parallels, including:

• Both have main servers (SEAM has a master KDC, and NIS has a principal NIS server).
• Both recommend 1 or more slave servers.
• Both take a singled-out customer component.
• Both accept a client-side daemon for managing session keys (SEAM has gssd, RPC/DH has keyserv).

If you read the SEAM ane.0 documentation from the SEAS 3.0 production, the SEAM 1.0.1 documentation from the Admin Pack, and the SEAM documentation in Solaris eight, you run into that progressive releases of Solaris, from 2.6 onward, integrate more and more components of SEAM.

Table 12-ane describes the progression so far.

Table 12-1. SEAM progression

Solaris Release	Unbundled Product	SEAM Version	Features Integrated with Solaris	Features Integrated in Unbundled Production
Solaris 2.6	SEAS three.0	SEAM 1.0	RPCSEC_GSS hooks	KDC, Remote KDC assistants, Kerberized networking utilities, Kerberos customer utilities, RPCSEC_GSS, GSS-API, Kerberos V5 GSS provider, Kerberos V5 PAM module
Solaris 7	SEAS 3.0	SEAM 1.0	RPCSEC_GSS, GSS-API	KDC, Remote KDC administration, Kerberized networking utilities, Kerberos client utilities, Kerberos V5 GSS provider, Kerberos V5 PAM module
Solaris eight	Solaris 8 Admin Pack	SEAM 1.0.1	RPCSEC_GSS, GSS-API, Kerberos client utilities, Kerberos V5 GSS provider, Kerberos V5 PAM module	KDC, Remote KDC administration, Kerberized networking utilities

Presumably the progression in Table 12-1 volition keep with future versions of Solaris and other operating systems.

The 5th column of Table 12-one consistently lists "Kerberized networking utilities." These are utilities like rlogin, rsh, rcp, ftp, and telnet (and their server daemons) that have been modified to understand Kerberos V5 security. The reason they are in that location is that they facilitate the deployment of an Intranet that sends no passwords in the clear over the wire, and indeed, via forwardable TGTs, enables yous to send no passwords at all. Without these utilities, there would be less point in having strong NFS security, since passwords would often appear on your network. This is another drawback of RPC/DH: it does not add together strong security to the basic networking utilities.

By at present, we've mentioned PAM several times without explaining it. Recall that your RPC/DH password is used to decrypt your private key. If your RPC/DH password is the same as your Unix login password, so you don't need to provide your RPC/DH password separately. How does this happen? The Solaris login control has lawmaking in it to try to decrypt the user'southward individual key with the Unix login password. At present suppose you've installed Kerberos V5 and would like the system to try to use the Unix login countersign as the central that decrypts your TGT from the KDC. One way would exist for your operating system vendor to change the login control to do and then. Simply and so, you decide you'd like the su command and the desktop lock screen feature to do the same. Afterward a while, information technology gets to be a lot of utilities to maintain. A improve style is to have pluggable framework that calls security machinery specific code in shared objects and has them have care of acquiring credentials. This is what PAM does. SEAM provides a Kerberos V5 PAM module. Check out your system's documentation for data on PAM; PAM is mutual to many Unix systems.

Hither are some final recommendations for and observations about SEAM installation:

• SEAM allows you to utilise it without DNS running. Don't practise that. If you ever change your heed, you'll have to repopulate the entire principal (coordinating to an RPC/DH netname) database in the KDC.
• Information technology is better to install SEAM clients (which can be NFS clients or NFS servers) by utilizing the preconfiguration steps that the documentation talks almost, and the GUI installer tries to walk you through. Go along in mind that the preconfiguration information need but, and should only, be established once, on an NFS server. You so run the SEAM installer on each host, pointing it at the preconfigured information on an NFS mounted or automounted filesystem (usually aforementioned filesystem where the installer lives). This reduces per-host installation tedium.
• The SEAM documentation is very chore-oriented, and hence very applied. Fifty-fifty if you lot ultimately want to do things differently, practice first, and follow the documentation examples every bit close to verbatim as possible earlier you lot try something circuitous or a footling chip different.
• Do not skip any steps. SEAM is rather unforgiving if a modest, only critical pace is missed. You'll notice that you tin cutting and paste from the web-based documentation into your command crush, and if you make that a addiction, you'll stay out of problem.

12.5.five.3. Enabling Kerberized NFS

This section assumes that you've gone through the installation and configuration that the SEAM documentation describes. Enabling Kerberized NFS on a filesystem is quite simple: export and mount the filesystem with the sec=krb5 option. On the NFS server, the /etc/dfs/dfstab entry looks like this:

share -o sec=krb5,rw /export/dwelling house/thud

When a filesystem is exported with the sec=krb5 choice, clients using NFS Version 2 must mount it with the sec=krb5 option if they are to savor normal user access privileges in the filesystem. On the NFS client, add the sec=krb5 option in the automounter map entry or the /etc/vfstab entry for the filesystem:

                    automounter auto_home entry:                    thud                   -sec=krb5      bonk:/export/domicile/thud                    vfstab entry:                    bonk:/export/dwelling house/thud - /thud nfs  - no  sec=krb5                  

Equally was the instance for enabling NFS/dh (see

Section 12.5.iv.5, "Enabling NFS/dh") with NFS Version 3, the sec=krb5 pick is not necessary in the automounter map or vfstab entries.

The krb5 option uses a combination of DES symmetric key encryption and the MD5 one-way hash function to produce the RPC credentials that are sent to, and authenticated by, the NFS server.

Not only is in that location a krb5 option to sec=, just there are krbi and krbp too.

Like the krb5 option, krb5i uses Kerberos V5 to authenticate users to NFS servers when the filesystem is exported with sec=krb5i. Dissimilar krb5, it also computes an MD5-based MAC on every remote procedure call request to the server, and every response to the client. The MAC is computed on an entire message: RPC header, plus NFS arguments or results. Thus krb5i provides integrity protection, hence the trailing i in krb5i.

Like krb5 and krb5i, krb5p uses Kerberos V5 to authenticate. Like krb5i information technology uses Kerberos V5 to provide integrity. Unlike krb5 and krb5i, krb5p uses Kerberos V5's DES encryption to provide privacy. Notation that only the NFS arguments and results are encrypted; the RPC headers go in the clear. And then an assaulter could deduce which NFS operation is being performed, but non on what file, nor what the file or directory

content is.

12.five.5.v. Combining krb5, krb5i, krb5p

You lot tin can combine the krb5 * options with each other. Let'southward suppose /export/domicile on server labrador contains the home directories of security conscious folks, though some are less paranoid than others. You lot can accommodate everyone by calculation the post-obit to /etc/dfs/dfstab:

share -o sec=krb5p:krb5i:krb5,rw /export/home

This ways the clients pick any of the three flavors of krb5 when they mount the NFS filesystem. Note that this is ane case 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 to the lowest degree the Solaris 8 client) will choice from the array of security flavors that mountd returns the commencement security flavour that the client supports. And 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-two, you might want to be careful well-nigh exporting filesystems with krb5i or krb5p security enabled. If you have data that can get in the clear on the network, then never consign 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 asking 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.

12.five.six. 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 commencement 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, considering there are more client machines, and more user ids than host ids to add together to the various tables that RPC/DH and Kerberos V5 crave. Also, some NFS client implementations may not exist running Solaris viii, and may support the stronger NFS security that yous decide to switch to. So fifty-fifty subsequently y'all go your servers reconfigured to use Kerberos V5 security, it won't be applied to simply change:

share -o rw /consign/habitation

to:

share -o sec=krb5,rw /consign/home

and not expect some chaos. That you lot can combine whatever 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 take some legacy software running on some NFS clients that is stuck on older systems. Thus you tin't upgrade the client systems to an operating system that can support stronger NFS security. You lot can practice 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.

12.5.7. NFS security futures

In

Department 12.five.2.two, "Asymmetric fundamental encryption", we

mentioned the RSA public key algorithm, merely did not talk about any NFS security that uses RSA. RSA is arguably the best asymmetric key encryption algorithm known to u.s.. Information technology is the foundation of most Public Fundamental Infrastructure (PKI) products, every bit well as networking protocols like SSL/TLS and S/MIME. And so why doesn't NFS use it? The master effect with RSA is that it was patented and then royalties were due to its rights holders. Now that the patent has expired, expect to see the following features in the futurity:

• Asymmetric key technology integrated with Kerberos V5. Without disproportionate central applied science, a physical compromise of the KDC finer compromises all of the principals listed in KDC, equally it stores each user'due south symmetric key. With asymmetric primal engineering science, only the public central needs to be stored in the KDC.
• The NFS Version 4 protocol specifies an SSL-similar GSS-API machinery provider called LIPKEY as one of the 2 required security providers to RPCSEC_GSS (Kerberos V5 being the other). LIPKEY uses asymmetric key algorithms. So when NFS Version four is deployed widely, expect to run into RSA used to secure it. Similar 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, discipline to royalties. The royalty free Advanced Encryption Standard (AES) has been selected to supercede DES. AES is faster and more secure than DES. Expect to meet futurity versions of NFS run over Kerberos V5 and LIPKEY

using AES as the encryption algorithm.

---

hopkinsmaders90.blogspot.com

Source: https://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch12_05.htm

Share this post