This chapter provides information about how to use Secure RPC to authenticate a host and a user across an NFS mount. The following is a list of the topics in this chapter.Overview of Secure RPC Administering Secure RPC (Task Map) Secure RPCdescriptionauthenticationSecure RPCauthenticationname servicesNIS+ name serviceauthenticationNIS name serviceauthenticationAUTH_DES authenticationAUTH_DH authenticationaccessSecure RPC authenticationSecure RPC (Remote Procedure Call) protects remote procedures with an authentication mechanism. The Diffie-Hellman authentication mechanism authenticates both the host and the user who is making a request for a service. The authentication mechanism uses Data Encryption Standard (DES) encryption. Applications that use Secure RPC include NFS and the name services, NIS and NIS+.authenticationuse with NFSNFS file systemsauthenticationfile systemssecurityauthentication and NFSfile systemsNFSAUTH_DH authenticationand NFSNFS enables several hosts to share files over the network. Under the NFS service, a server holds the data and resources for several clients. The clients have access to the file systems that the server shares with the clients. Users who are logged in to the client systems can access the file systems by mounting the file systems from the server. To the user on the client system, it appears as if the files are local to the client. One of the most common uses of NFS allows systems to be installed in offices, while storing all user files in a central location. Some features of the NFS service, such as the nosuid option to the mount command, can be used to prohibit the opening of devices and file systems by unauthorized users.Secure NFSThe NFS service uses Secure RPC to authenticate users who make requests over the network. This process is known as Secure NFS. The Diffie-Hellman authentication mechanism, AUTH_DH, uses DES encryption to ensure authorized access. The AUTH_DH mechanism has also been called AUTH_DES. For more information, see the following:To set up and administer Secure NFS, see Administering the Secure NFS System in System Administration Guide: Network Services. To set up the NIS+ tables and enter names in the cred table, see System Administration Guide: Naming and Directory Services (NIS+). For an outline of the transactions that are involved in RPC authentication, see Implementation of Diffie-Hellman Authentication. Data Encryption StandardDES encryption DES encryptionSecure NFS encryptionDES algorithm The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt data. If two credential users or principals know the same DES key, they can communicate in private by using the key to encipher and decipher text. DES is a relatively fast encryption mechanism. A DES chip makes the encryption even faster. However, if the chip is not present, a software implementation is substituted.encryptingSecure NFSThe risk of using just the DES key is that an intruder can collect enough cipher-text messages that were encrypted with the same key to be able to discover the key and decipher the messages. For this reason, security systems such as Secure NFS need to change the keys frequently. Kerberos authenticationand Secure RPCSecure RPCand KerberosKerberos is an authentication system that was developed at MIT. Some encryption in Kerberos is based on DES. Kerberos V4 support is no longer supplied as part of Secure RPC. However, a client-side and server-side implementation of Kerberos V5, which uses RPCSEC_GSS, is included with this release. For more information, see Chapter 21, Introduction to the Kerberos Service. authenticationDH authentication Diffie-Hellman authenticationDH authentication DH authenticationdescription private keyssecret keys cred databaseDH authentication public keysDH authentication and publickey mapDH authentication common keysDH authentication and The Diffie-Hellman (DH) method of authenticating a user is nontrivial for an intruder to crack. The client and the server have their own private key, which they use with the public key to devise a common key. The private key is also known as the secret key. The client and the server use the common key to communicate with each other. The common key is encrypted with an agreed-upon encryption function, such as DES.Authentication is based on the ability of the sending system to use the common key to encrypt the current time. Then, the receiving system can decrypt and check against its current time. The time on the client and the server must be synchronized. For more information, see Managing Network Time Protocol (Tasks) in System Administration Guide: Network Services./etc/publickey fileDH authentication anddatabasespublickey for Secure RPCdatabasescred for Secure RPCThe public keys and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map. NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users.NIS+ name servicecred tablecred tableDH authentication andThe system administrator is responsible for setting up NIS maps or NIS+ tables, and for generating a public key and a private key for each user. The private key is stored in encrypted form with the user's password. This process makes the private key known only to the user.accesssecurityNFS client-server securityNFS client-server NFS file systemsproviding client-server security clientsAUTH_DH client-server session authenticationAUTH_DH client-server session public key cryptographyAUTH_DH client-server session securityDH authentication serversAUTH_DH client-server session Secure RPCimplementation of administeringNFS client-server file security commandsSecure RPC commandsThis section describes the series of transactions in a client-server session that use Diffie-Hellman authentication (AUTH_DH).public key cryptographygenerating keysusing Diffie-Hellmansecret keysgenerating for Secure RPCgeneratingNFS secret keyschangingNFS secret keysdatabasesNFS secret keysdecryptingNFS secret keysnewkey commandgenerating keysnisaddcred commandgenerating keyspublic key cryptographyNFS secret keyspublic key cryptographydatabase of public keys for Secure RPCchkey commandpublic key cryptographychanging NFS public keys and secret keysSometime prior to a transaction, the administrator runs either the newkey or the nisaddcred command to generate a public key and a secret key. Each user has a unique public key and secret key. The public key is stored in a public database. The secret key is stored in encrypted form in the same database. The chkey command changes the key pair. decryptingsecret keys passwordssecret-key decryption for Secure RPC logging inand AUTH_DH Normally, the login password is identical to the Secure RPC password. In this case, the keylogin command is not required. However, if the passwords are different, the users have to log in and then run the keylogin command.keyserverdescriptionkeylogin commanduse for Secure RPCSecure RPCkeyserverThe keylogin command prompts the user for a Secure RPC password. The command then uses the password to decrypt the secret key. The keylogin command then passes the decrypted secret key to the keyserver program. The keyserver is an RPC service with a local instance on every computer. The keyserver saves the decrypted secret key and waits for the user to initiate a Secure RPC transaction with a server.If both the login password and the RPC password are the same, the login process passes the secret key to the keyserver. If the passwords are required to be different, then the user must always run the keylogin command. When the keylogin command is included in the user's environment configuration file, such as the ~/.login, ~/.cshrc, or ~/.profile file, the keylogin command runs automatically whenever the user logs in. conversation keysgenerating in secure RPCpublic key cryptographygenerating keysconversation keys for Secure NFSWhen the user initiates a transaction with a server, the following occurs:The keyserver randomly generates a conversation key. The kernel uses the conversation key, plus other material, to encrypt the client's timestamp. The keyserver looks up the server's public key in the public key database. For more information, see the publickey4 man page. The keyserver uses the client's secret key and the server's public key to create a common key. The keyserver encrypts the conversation key with the common key. The transmission, which includes the encrypted timestamp and the encrypted conversation key, is then sent to the server. The transmission includes a credential and a verifier. The credential contains three components:The client's network name The conversation key, which is encrypted with the common key A “window,” which is encrypted with the conversation key credentialdescriptionThe window is the difference in time that the client says should be allowed between the server's clock and the client's timestamp. If the difference between the server's clock and the timestamp is greater than the window, the server rejects the client's request. Under normal circumstances, this rejection does not happen, because the client first synchronizes with the server before starting the RPC session.verifiersdescriptionThe client's verifier contains the following:The encrypted timestamp An encrypted verifier of the specified window, which is decremented by 1 verifierswindowwindow verifierThe window verifier is needed in case somebody wants to impersonate a user. The impersonator can write a program that, instead of filling in the encrypted fields of the credential and verifier, just inserts random bits. The server decrypts the conversation key into some random key. The server then uses the key to try to decrypt the window and the timestamp. The result is random numbers. After a few thousand trials, however, the random window/timestamp pair is likely to pass the authentication system. The window verifier lessens the chance that a fake credential could be authenticated. conversation keysdecrypting in secure RPC decryptingconversation keys for Secure RPC When the server receives the transmission from the client, the following occurs:The keyserver that is local to the server looks up the client's public key in the public key database. common keyscalculatingpublic key cryptographycommon keyscalculationThe keyserver uses the client's public key and the server's secret key to deduce the common key. The common key is the same common key that is computed by the client. Only the server and the client can calculate the common key because the calculation requires knowing one of the secret keys. The kernel uses the common key to decrypt the conversation key. The kernel calls the keyserver to decrypt the client's timestamp with the decrypted conversation key. cred tableinformation stored by serverAfter the server decrypts the client's timestamp, the server stores four items of information in a credential table:The client's computer name The conversation key The window The client's timestamp replayed transactionsThe server stores the first three items for future use. The server stores the client's timestamp to protect against replays. The server accepts only timestamps that are chronologically greater than the last timestamp seen. As a result, any replayed transactions are guaranteed to be rejected.remote loginssecurity andImplicit in these transactions is the name of the caller, who must be authenticated in some manner. The keyserver cannot use DES authentication to authenticate the caller because the use of DES by the keyserver would create a deadlock. To avoid a deadlock, the keyserver stores the secret keys by user ID (UID) and grants requests only to local root processes. verifiersreturned to NFS clientThe server returns a verifier to the client, which includes the following:The index ID, which the server records in its credential cache The client's timestamp minus 1, which is encrypted by the conversation key The reason for subtracting 1 from the client's timestamp is to ensure that the timestamp is out of date. An out-of-date timestamp cannot be reused as a client verifier. The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what timestamp the client sent. With every transaction after the first transaction, the client returns the index ID to the server in its next transaction. The client also sends another encrypted timestamp. The server sends back the client's timestamp minus 1, which is encrypted by the conversation key. task mapsadministering Secure RPC administeringSecure RPC task map The following task map points to procedures that configure Secure RPC for NIS, NIS+, and NFS.Task Description For Instructions 1. Start the keyserver. Ensures that keys can be created so that users can be authenticated. How to Restart the Secure RPC Keyserver 2. Set up credentials on an NIS+ host. Ensures that the root user on a host can be authenticated in an NIS+ environment. How to Set Up a Diffie-Hellman Key for an NIS+ Host 3. Give an NIS+ user a key. Enables a user to be authenticated in an NIS+ environment. How to Set Up a Diffie-Hellman Key for an NIS+ User 4. Set up credentials on an NIS host. Ensures that the root user on a host can be authenticated in an NIS environment. How to Set Up a Diffie-Hellman Key for an NIS Host 5. Give an NIS user a key. Enables a user to be authenticated in an NIS environment. How to Set Up a Diffie-Hellman Key for an NIS User 6. Share NFS files with authentication. Enables an NFS server to securely protect shared file systems using authentication. How to Share NFS Files With Diffie-Hellman Authentication addingDH authentication to mounted file systemsBy requiring authentication for use of mounted NFS file systems, you increase the security of your network. startingSecure RPC keyserver keyserverstarting daemonskeyserv keyserv daemon &rolePAstep;service management facilityenabling keyserversvcs commandlisting keyserver serviceVerify that the keyserv daemon is running.# svcs \*keyserv\* STATE STIME FMRI disabled Dec_14 svc:/network/rpc/keyserv svcadm commandenabling keyserver daemonEnable the keyserver service if the service is not online.# svcadm enable network/rpc/keyserv configuringDH key in NIS+ DH authenticationconfiguring in NIS+ addingkeys for DH authentication mech_dh mechanismsecure RPC GSS-APIcredentials in secure RPC This procedure should be done on every host in the NIS+ domain. After root has run the keylogin command, the server has GSS-API acceptor credentials for mech_dh and the client has GSS-API initiator credentials.For a detailed description of NIS+ security, see System Administration Guide: Naming and Directory Services (NIS+). &rolePAstep;Enable the publickey table in the name service.Add the following line to the /etc/nsswitch.conf file:publickey: nisplus Initialize the NIS+ client.# nisinit -cH hostnamewhere hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client system. databasescred for Secure RPCcred databaseadding client credentialnisaddcred commandadding client credentialAdd the client to the cred table.Type the following commands: # nisaddcred local # nisaddcred des Verify the setup by using the keylogin command.keylogin commandverifying DH authentication setupIf you are prompted for a password, the procedure has succeeded.# keylogin Password: DH authenticationfor NIS+ clientThe following example uses the host pluto to set up earth as an NIS+ client. You can ignore the warnings. The keylogin command is accepted, verifying that earth is correctly set up as a secure NIS+ client.# nisinit -cH pluto NIS Server/Client setup utility. This system is in the example.com. directory. Setting up NIS+ client ... All done. # nisaddcred local # nisaddcred des DES principal name : unix.earth@example.com Adding new key for unix.earth@example.com (earth.example.com.) Network password:<Type password> Warning, password differs from login password. Retype password: <Retype password> # keylogin Password: <Type password> # configuringDH key for NIS+ user This procedure should be done on every user in the NIS+ domain. &rolePAstep;cred databaseadding user credentialNIS+ name servicecred databaseAdd the user to the cred table on the root master server.Type the following command:# nisaddcred -p unix.UID@domain-name -P username.domain-name. desNote that, in this case, the username.domain-name must end with a dot (.). Verify the setup by logging in as the client and typing the keylogin command. NIS+ name serviceadding authenticated user In the following example, a key for Diffie-Hellman authentication is given to the user jdoe.# nisaddcred -p unix.1234@example.com -P jdoe.example.com. des DES principal name : unix.1234@example.com Adding new key for unix.1234@example.com (jdoe.example.com.) Password: <Type password> Retype password:<Retype password> # rlogin rootmaster -l jdoe % keylogin Password: <Type password> % configuringDH key in NIS DH authenticationconfiguring in NIS DH authenticationfor NIS client This procedure should be done on every host in the NIS domain. &rolePAstep;Enable the publickey map in the name service.Add the following line to the /etc/nsswitch.conf file:publickey: nis computingDH keyCreate a new key pair by using the newkey command.# newkey -h hostnamewhere hostname is the name of the client. In the following example, earth is set up as a secure NIS client.# newkey -h earth Adding new key for unix.earth@example.com New Password: <Type password> Retype password:<Retype password> Please wait for the database to get updated... Your new key has been successfully stored away. # configuringDH key for NIS user keyscreating DH key for NIS user newkey commandcreating key for NIS user This procedure should be done for every user in the NIS domain. Only system administrators, when logged in to the NIS master server, can generate a new key for a user. &rolePAstep;Create a new key for a user.# newkey -u usernamewhere username is the name of the user. The system prompts for a password. You can type a generic password. The private key is stored in an encrypted form by using the generic password. user proceduresencrypting NIS user's private keyencryptingprivate key of NIS userchkey commandTell the user to log in and type the chkey -p command.This command allows users to re-encrypt their private keys with a password known only to the user.The chkey command can be used to create a new key pair for a user. In this example, superuser sets up the key.# newkey -u jdoe Adding new key for unix.12345@example.com New Password: <Type password> Retype password:<Retype password> Please wait for the database to get updated... Your new key has been successfully stored away. #user procedureschkey commandThen the user jdoe re-encrypts the key with a private password.% chkey -p Updating nis publickey database. Reencrypting key for unix.12345@example.com Please enter the Secure-RPC password for jdoe:<Type password> Please enter the login password for jdoe: <Type password> Sending key change request to centralexample... DH authenticationsharing files with filessharing with DH authentication sharing fileswith DH authentication This procedure protects shared file systems on an NFS server by requiring authentication for access. Diffie-Hellman public key authentication must be enabled on the network. To enable authentication on the network, do one of the following:How to Set Up a Diffie-Hellman Key for an NIS+ Host How to Set Up a Diffie-Hellman Key for an NIS Host Become superuser or assume a role that includes the System Management profile.The System Administrator role includes the System Management profile. To create the role and assign the role to a user, see Configuring RBAC (Task Map). NFS file systemssecure access with AUTH_DHauthenticationNFS-mounted filesOn the NFS server, share a file system with Diffie-Hellman authentication.# share -F nfs -o sec=dh /filesystemwhere filesystem is the file system that is being shared.The o sec=dh option means that AUTH_DH authentication is now required to access the file system. authenticationNFS-mounted filesDH authenticationmounting files withfilesmounting with DH authenticationmountingfiles with DH authenticationOn an NFS client, mount a file system with Diffie-Hellman authentication.# mount -F nfs -o sec=dh server:filesystem mount-pointserverIs the name of the system that is sharing filesystem filesystemIs the name of the file system that is being shared, such as opt mount-pointIs the name of the mount point, such as /opt The o sec=dh option mounts the file system with AUTH_DH authentication.