Implementation of Diffie-Hellman Authentication

This section describes the series of transactions in a client-server
session that use Diffie-Hellman authentication (AUTH_DH).

Generating the Public Keys and Secret Keys for
Secure RPC

Sometime 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.

Running the keylogin Command
for Secure RPC

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.

The 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.

Generating the Conversation Key for Secure RPC

When 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 publickey(4) 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.

Initially Contacting the Server in Secure RPC

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

The 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.

The client's verifier contains the following:

The encrypted timestamp

An encrypted verifier of the specified window, which is decremented
by 1

The 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.

Decrypting the Conversation Key in 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.

The 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.

Storing Information on the Server in Secure RPC

After 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

The 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.

Note –

Implicit 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.

Returning the Verifier to the Client in Secure
RPC

The 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.

Authenticating the Server in Secure RPC

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.

Handling Transactions in Secure RPC

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.