CHAPTER 19
Using Authentication Services

See DES Encryption

See Diffie-Hellman Authentication

See Kerberos Version 4

See The Pluggable Authentication Module (PAM) Framework

SECURE RPC IS A METHOD OF PROVIDING ADDITIONAL SECURITY THAT AUTHENTICATES THE host and the user making a request. Secure RPC uses either Diffie-Hellman or Kerberos authentication. Both of these authentication mechanisms use DES (data encryption standard) encryption. Applications that use Secure RPC include NFS and the NIS+ name service.

The NFS software enables several hosts to share files over the network. The clients have access to the file systems that the server exports to the clients. Users logged in to the client system can access the file systems by mounting them from the server. To the user on the client system, the files seem to be local. One of the most common uses of the NFS environment is to enable systems to be installed in offices while keeping all user files in a central location. Some features of the NFS system, such as the -nosuid mount option, can be used to prohibit the opening of devices as well as file systems.

The NFS environment can use Secure RPC to authenticate users who make requests over the network. This combination is known as Secure NFS. The authentication mechanism, AUTH_DH, uses DES encryption with Diffie-Hellman authentication to ensure authorized access. The AUTH_DH mechanism has also been called AUTH_DES. The AUTH_KERB4 mechanism uses DES encryption with Kerberos authentication. This mechanism has also been called AUTH_KERB.

This chapter describes the following elements of Secure RPC:

•  Data Encryption Standard (DES) encryption

•  Diffie-Hellman authentication

•  Kerberos Version 4

•  Pluggable Authentication Module (PAM)

DES Encryption

The data encryption standard (DES) functions use a 56-bit key to encrypt user data. If two credential users (or principals) know the same DES key, they can communicate in private, using the key to encipher and decipher text. DES is a relatively fast encryption mechanism. A DES chip makes the encryption even faster; if the chip is not present, though, a software implementation is substituted.

The risk of using just DES is that, with enough time, an intruder can collect enough cipher-text messages encrypted with the same key to be able to discover the key and decipher the messages. For this reason, security systems such as Secure RPC change the keys frequently.

Diffie-Hellman Authentication

The Diffie-Hellman method of authenticating a user is non-trivial for an intruder to crack. The client and the server each has its own private key (sometimes called a secret key) which they use together with the public key to devise a common key. They use the common key to communicate with each other, using an agreed-upon encryption/decryption function such as DES. This method was identified as DES authentication in previous Solaris releases.

Authentication is based on the capability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time. Because Diffie-Hellman depends on the current times matching, the keyserver program first synchronizes the time between the client and server.

The public and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the public key map, and NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users.

The system administrator is responsible for setting up NIS or NIS+ tables and generating a public key and a private key for each user. The private key is stored encrypted with the user's password. This makes the private key known only to the user.

How Diffie-Hellman Authentication Works

This section describes the series of transactions in a client-server session using DH authorization (AUTH_DH).

Generating the Public and Secret Keys

Some time before a transaction, the administrator runs either the newkey or nisaddcred commands that 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. To change the key pair, use the chkey command.

Running the keylogin Command

Normally, the login password is identical to the secure RPC password. In this case, a keylogin is not required. If the passwords are different, the users have to log in and then do an explicit keylogin.

The keylogin program prompts the user for a secure RPC password and uses the password to decrypt the secret key. The keylogin program then passes the decrypted secret key to a program called the keyserver. 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 the passwords are the same, the login process passes the secret key to the keyserver. If the passwords are required to be different and the user must always run keylogin, then the keylogin program may be included in the user's environment configuration file such as ~/.login, ~/.cshrc, or ~/.profile, so that it runs automatically whenever the user logs in.

Generating the Conversion Key

When the user initiates a transaction with a server:

1.  The keyserver randomly generates a conversation key.

2.  The kernel uses the conversation key to encrypt the client's time stamp (among other things).

3.  The keyserver looks up the server's public key in the public-key database (see the publickey(4) manual page).

4.  The keyserver uses the client's secret key and the server's public key to create a common key.

5.  The keyserver encrypts the conversation key with the common key.