Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
3.  Using Authentication Services (Tasks) Overview of Secure RPC Diffie-Hellman Authentication Implementation of Diffie-Hellman Authentication  Previous   Contents   Next 
   
 

Decrypting the Conversation Key

When the server receives the transmission from the client, the following occurs:

  1. The keyserver that is 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, which 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.

  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. The server stores the time stamp to protect against replays. The server accepts only time stamps that are chronologically greater than the last time stamp 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 authenticate the caller because it would create a deadlock. To solve this problem, the keyserver stores the secret keys by user ID (UID) and grants requests only to local root processes.


Returning the Verifier to the Client

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 time stamp minus 1, which is encrypted by the conversation key

The reason for subtracting 1 from the time stamp is to ensure that the time stamp is invalid and that it 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 transaction, 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, which is encrypted by the conversation key.

Administering Diffie-Hellman Authentication

A system administrator can implement policies that help secure the network. The level of security that is required differs with each site. This section provides instructions for some tasks that are associated with network security.

How to Restart the Keyserver

  1. Become superuser or assume an equivalent role.

  2. Verify whether the keyserv daemon (the keyserver) is running.

    # ps -ef | grep keyserv
    root   100      1  16   Apr 11    ?         0:00 /usr/sbin/keyserv
    root  2215   2211   5   09:57:28  pts/0     0:00 grep keyserv
  3. Start the keyserver if it isn't running.

    # /usr/sbin/keyserv

How to Set Up a Key in NIS+ Credentials for Diffie-Hellman Authentication

For detailed description of NIS+ security, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

  1. Become superuser or assume an equivalent role.

  2. Edit the /etc/nsswitch.conf file, and add the following line:

    publickey: nisplus
  3. Initialize the NIS+ client.

    # nisinit -cH hostname

    hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client machine.

  4. Add the client to the cred table by typing the following commands:

    # nisaddcred local
    # nisaddcred des
  5. Verify the setup by using the keylogin command.

    If you are prompted for a password, the procedure has succeeded.

Example--Setting Up a New Key for root on a NIS+ Client

The 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 machine is in the North.Abc.COM. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@North.Abc.COM
Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.)
 
Network password: xxx Press Return
Warning, password differs from login password.
Retype password: xxx Press Return
 
# keylogin
Password:
#
 
 
 
  Previous   Contents   Next