Previous Table of Contents Next

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 has three components:

  The client's Net name
  The conversation key, encrypted with the common key
  A “window,” encrypted with the conversation key

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 rejects the client's request. Under normal circumstances, the request is not rejected because the client first synchronizes with the server before starting the RPC session.

The client's verifier contains:

  The encrypted time stamp
  An encrypted verifier of the specified window, decremented by 1

The window verifier is needed in case an outsider 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 decrypts the conversation key into some random key and uses it to try to decrypt the window and time stamp. The result is 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 public-key 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 client's computer name
  The conversation key
  The window
  The client's time stamp

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 index ID, which the server records in its credential cache
  The client's time stamp minus 1, encrypted by the conversation key

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.

Administering Diffie-Hellman Authentication

This section describes the commands used to administer Secure RPC and provides instructions for the following tasks associated with network security:

  Restarting the keyserver
  Setting up NIS+ credentials for Diffie-Hellman authentication
  Setting up NIS credentials for Diffie-Hellman authentication
  Sharing and mounting files with Diffie-Hellman authentication

Secure RPC Commands

Table 19-1 lists manual pages that provide useful reference information about Secure RPC.

Table 19-1 Secure RPC Manual Page References

Command Description
secure_rpc(3N) Description of Secure RPC library routines for secure remote procedure calls.
rpc(3N) Description of RPC library routines for secure remote procedure calls.
attributes(5) Characteristics of commands, utilities, and device drivers.

Table 19-2 lists commands used to administer Diffie-Hellman authentication.

Table 19-2 Secure RPC Commands

Command Description
chkey Change user's Secure RPC key pair.
getpublickey Retrieve public key.
getsecretkey Retrieve secret key.
keylogin Decrypt and store secret key with keyserv.
keylogout Delete stored secret key with keyserv.
keyserv Daemon for storing private encryption keys.
login Sign on to a system.
newkey Create a new Diffie-Hellman pair in the public-key database.
nisaddcred Create NIS+ credentials.
nisclient Initialize NIS+ credentials for NIS+ principals.
publickey Retrieve public or secret key.

Previous Table of Contents Next