System Administration Guide

Overview of Secure RPC

Secure RPC is a method of authentication that authenticates both the host and the user making a request. Secure RPC uses either Diffie-Hellman or Kerberos authentication. Both of these authentication mechanisms use DES encryption. Applications that use Secure RPC include NFS and the NIS+ name service.

NFS Services and Secure RPC

The NFS software enables several hosts to share files over the network. Under the NFS system, a server holds the data and resources for several clients. The clients have access to the file systems that the server exports to the clients. Users logged in to the client machine can access the file systems by mounting them from the server. To the user on the client machine, it appears as if the files were local to the client. One of the most common uses of the NFS environment is to allow 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 by unauthorized users.

The NFS environment uses Secure RPC to authenticate users who make requests over the network. This 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 is has also been called AUTH_KERB.

The NFS Administration Guide describes how to set up and administer Secure NFS. Setting up the NIS+ tables and entering names in the cred table are discussed in Solaris Naming Administration Guide. See "Implementation of Diffie-Hellman Authentication" for an outline of the steps involved in RPC authentication.

DES Encryption

The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt a secret key. 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; but if the chip is not present, a software implementation is substituted.

The risk of using just the DES key 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 NFS 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 ability 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. Make sure you synchronize the time on the client and the server.

The public and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey 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.

Implementation of Diffie-Hellman Authentication

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

Generating the Public and Secret Keys

Sometime prior to a transaction, the administrator runs either the newkey or nisaddcred commands that generates 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 a keylogin explicitly.

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 Conversation 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) man 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.

First Contact with the Server

The transmission including the encrypted time stamp 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 window is the difference the client says should be allowed between the server's clock and the client's time stamp. If the difference between the server's clock and the time stamp is greater than the window, the server would reject the client's request. Under normal circumstances this will not happen because the client first synchronizes with the server before starting the RPC session.

The client's verifier contains:

The window verifier is needed in case somebody wants to impersonate a user and writes a program that, instead of filling in the encrypted fields of the credential and verifier, just stuffs in random bits. The server will decrypt the conversation key into some random key and use it to try to decrypt the window and the time stamp. The result will be random numbers. After a few thousand trials, however, there is a good chance that the random window/time stamp pair will pass the authentication system. The window verifier makes guessing the right credential much more difficult.

Decrypting the Conversation Key

When the server receives the transmission from the client:

  1. The keyserver local to the server looks up the client's public key in the publickey database.

  2. The keyserver uses the client's public key and the server's secret key to deduce the common key--the same common key computed by the client. (Only the server and the client can calculate the common key because doing so requires knowing one secret key or the other.)

  3. The kernel uses the common key to decrypt the conversation key.

  4. The kernel calls the keyserver to decrypt the client's time stamp with the decrypted conversation key.

Storing Information on the Server

After the server decrypts the client's time stamp, it stores four items of information in a credential table:

The server stores the first three items for future use. It stores the time stamp to protect against replays. The server accepts only time stamps that are chronologically greater than the last one seen, so any replayed transactions are guaranteed to be rejected.


Note -

Implicit in these procedures is the name of the caller, who must be authenticated in some manner. The keyserver cannot use DES authentication to do this because it would create a deadlock. To solve this problem, the keyserver stores the secret keys by UID and grants requests only to local root processes.


Verifier Returned to the Client

The server returns a verifier to the client, which includes:

The reason for subtracting 1 from the time stamp is to ensure that the time stamp is invalid and cannot be reused as a client verifier.

Client Authenticates the Server

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 time stamp the client sent.

Additional Transactions

With every transaction after the first, the client returns the index ID to the server in its second transaction and sends another encrypted time stamp. The server sends back the client's time stamp minus 1, encrypted by the conversation key.

Kerberos Version 4

Kerberos is an authentication system that was developed at the Massachusetts Institute of Technology. Kerberos uses DES encryption to authenticate a user when logging in to the system. Authentication is based on the ability 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. Kerberos Version 4 is supported in the Solaris 2.6 release.

Kerberos works by authenticating the user's login password. A user enters the kinit command, which acquires a ticket that is valid for the time of the session (or eight hours, the default session time) from the Kerberos authentication server. When the user logs out, the ticket can be destroyed (using the kdestroy command).

The Kerberos software is available from MIT project Athena, and is not part of the SunOS 5.x software. SunOS 5.x software provides:

"Implementation of Kerberos Authentication with NFS" gives an overview of how the Kerberos authentication procedure works.


Note -

Solaris provides the ability to connect to the Kerberos functionality. It does not provide the Kerberos package. However, you can ftp Kerberos 4 source from athena-dist.mit.edu using anonymous as a username and your email address as a password. The source is located in the pub/kerberos directory.


Implementation of Kerberos Authentication with NFS

The following process assumes that the Kerberos key distribution center (KDC) is already installed on the network, using publicly available sources from MIT project Athena.

  1. The /usr/sbin/kerbd daemon must be running on the NFS client and server.

    This daemon is normally started when needed by inetd. The rpcinfo command can be used to make sure that the kerbd service is registered. kerbd is the user-mode daemon. It interfaces with the kernel RPC and the KDC. It generates and validates authentication tickets.

  2. The system administrator sets up the NFS server to use Kerberos authentication.

    The MIT Kerberos software is used to register the principal names in the Kerberos key distribution center (KDC) on the Kerberos server. The following entries are required:

    • root.hostname (required for each NFS client)

    • nfs.hostname (required for each NFS server)

  3. The user mounts the shared file system.

    The user on the client must get a ticket for root on the client to mount the shared file system.

  4. The user logs in to the Kerberos service, using the kinit command.

    The Kerberos authentication server authenticates the request, and grants a ticket for the ticket-granting service.

  5. The user accesses the mounted directory.

    The kerbd daemon automatically secures a ticket on behalf of the client for the NFS server exporting the file system. At this point, there are two valid tickets, the original ticket-granting ticket and one for the server.

  6. The user destroys the tickets at the end of the session to prevent them from being compromised.

    The kdestroy command destroys the user's active Kerberos authorization tickets by writing zeros to the file that contains the tickets. You can put the kdestroy command in your .logout file, so that all Kerberos tickets are automatically destroyed when you log out of the system.

  7. If tickets have been destroyed before the session has finished, the user must request a new ticket with the kinit command.