Introduction

Remote procedure call (RPC) is a technique for constructing distributed, client-server-based applications. Secure RPC provides communication between the client and server so that applications can authenticate with each other to establish the identity of the communicating party before allowing or making any RPC calls.

The following are some of the different security mechanisms offered by Secure RPC protocol for the purpose of authentication:

• UNIX® authentication (AUTH_UNIX)
• Data Encryption Standard (DES) authentication (AUTH_DES)
• RPCSEC_GSS APIs

This article discusses how to use Secure RPC with AUTH_DES authentication security mechanism. AUTH_DES authentication involves the use of both a credential as well as a verifier. They both offer a strong security authentication in client-server-based applications. When using Secure RPC with AUTH_DES authentication, all users are required to have a pair of public and private keys and a unique netname in the form of os.uid@domainname (for example, unix.204@in.ibm.com). You can use Network Information Service (NIS) to provide each user with the public and private key pairs and the netname. The basic steps needed for NIS setup are covered in the Configuring NIS server section. See the Resources for additional details.

Setup required for DES authentication

Before you can successfully run a Secure RPC client or server application, you need to obtain a network name or netname (independent operating system name) and public and private keys. If you already have an NIS server configured, you can skip the first six steps in the Configuring NIS server section.

Configuring NIS server

Do the following to configure an NIS server. Configuring an NIS server also enables it as an NIS client.

1. Make sure the requisite filesets of NIS are installed.

   # lslpp -l |grep nis bos.net.nis.client 5.3.0.61 COMMITTED Network Information Service bos.net.nis.server 5.3.0.61 COMMITTED Network Information Service bos.rte.filesystem 5.3.0.50 COMMITTED Filesystem Administration #

   
   
2. Set the domain name using the chypdom command.

   # chypdom -B in.ibm.com

   
   
3. Create the master NIS server using the ypinit command.

   # ypinit -q -o -m Building /var/yp/in.ibm.com/ypservers... Running /var/yp/Makefile... updated passwd updated group 0+1 records in. 0+1 records out. updated hosts could not find /etc/ethers could not find /etc/networks updated rpc updated services updated protocols updated netgroup could not find /etc/bootparams WARNING: Group writable directory /var/spool WARNING: Group writable directory /var/spool/mqueue /var/yp/in.ibm.com/mail.aliases: 4 aliases, longest 9 bytes, 57 bytes total updated aliases updated publickey could not find /etc/netmasks Target "all" is up to date. adfsaix5.in.ibm.com has been set up as a NIS master server without any errors. If there are running slave NIS servers, run yppush now for any data bases which have been changed. If there are no running slaves, run ypinit on those hosts which are to be slave servers. #

   
   
4. Start the ypserv daemon for the master NIS server.

   # startsrc -s ypserv 0513-059 The ypserv Subsystem has been started. Subsystem PID is 319736. #

   
   
5. In order for the password updates to work, start yppasswdd.

   # startsrc -s yppasswdd 0513-059 The yppasswdd Subsystem has been started. Subsystem PID is 233490. #

   
   
6. Verify that inetd and portmap daemons are running. If not, start the daemons.

   # lssrc -s inetd Subsystem Group PID Status inetd tcpip 204900 active # lssrc -s portmap Subsystem Group PID Status portmap portmap 159886 active #

   
   
7. Start the ypbind daemon.

   # startsrc -s ypbind 0513-059 The ypbind Subsystem has been started. Subsystem PID is 118826. #

   
   
8. Edit the /etc/nsswitch.conf file and add following:

   publickey: nis

   
   

You can now start the application server program.

Creating user netnames and public and private key pairs

After setting up NIS, do the following for each user:

1. Add a new user.

   # mkuser userone # passwd userone # id useroneuid=249(userone) gid=1(staff)

   
   
2. Start the keyserv daemon.

   # startsrc -s keyserv 0513-059 The keyserv Subsystem has been started. Subsystem PID is 344274 #

   
   
3. Create a public and secret key for userone and add it to the publickey database.

   # newkey -u userone -s nis Updating nis publickey database. Adding new key for unix.208@in.ibm.com. Enter userone's login password: Please wait for the database to get updated ...

   
   
4. Make the netid file.

   # mknetid -p /etc/passwd | tee /etc/netid unix.0@in.ibm.com 0:0,2,3,7,8,10,11,55001,55002 unix.1@in.ibm.com 1:1 unix.2@in.ibm.com 2:2,3,4 unix.3@in.ibm.com 3:3 unix.4@in.ibm.com 4:4 unix.5@in.ibm.com 5:5 unix.100@in.ibm.com 100:100 unix.9@in.ibm.com 9:-2 unix.11@in.ibm.com 11:11,9 unix.6@in.ibm.com 6:12 unix.200@in.ibm.com 200:13 unix.203@in.ibm.com 203:1 unix.204@in.ibm.com 204:1,201 unix.249@in.ibm.com 249:1

   
   
5. Update the NIS database netid maps.

   # cd /var/yp # make netid updated netid pushed netid Target "netid" is up to date. #

   
   
6. Start a duplicate login session and log in as userone.
7. Run the keylogin command.

   # keylogin Password: #

   
   

Run the client application now.

DES authentication

The following section outlines the steps in DES authentication:

1. Generating public and secret keys

   Each user using Secure RPC with DES authentication is supposed to have a pair of public and secret keys. This can be achieved by using the newkey command, as previously shown. The system administrator runs the newkey command for each user to generate unique public and secret keys for the user who wants to use DES authentication. The public and secret keys are stored in a public database (/etc/publickey file). The secret key is stored in encrypted form in the same database. To change the key pair, use the chkey command.

2. Running the keylogin command

   Once the public and secret keys of the users are created, they must log in and run the keylogin command anytime they wish to run the Secure RPC application. The keylogin command contacts the NIS server to get the users encrypted key. keylogin then prompts the user for the Secure RPC password and then decrypts the secret key of that user. Since the mapping in the /etc/keylogin file is between the users netname and the public and secret key pairs, you need to find the netname before you can match it to the key pair. The mapping between the netname and the uid of the user (gid) is maintained in the /etc/netid file.

   The keylogin command then passes on the decrypted secret key to the local keyserver daemon, which stores the decrypted secret key with itself until the user runs a Secure RPC transaction.

   The /etc/publickey and the /etc/netid files mentioned in here are not used directly. They are converted and maintained in a database map by NIS. This is transparent to the user as you configure the /etc/nsswitch.conf file to look up the publickey information in NIS and keylogin contacts the NIS server.

3. Getting the common key

   Every time a user logs in and starts a session with a remote Secure RPC application server, they get a new session key, which is called a common key. The common key is a shared key between the client and the server application that has been created by the Diffie-Hellman Encryption method. This process makes use of the client and server public and private key pairs. For more information on the Diffie-Hellman method, see the Resources section.

4. Generating conversation key

   After generating a common key, the keyserver program randomly generates a conversation key. This key is used to encrypt a client timestamp (among other things). The conversation key is encrypted using the common key, which has been generated above.

5. Actual contact of client to the server

   The contact and exchange of information between the client and the server begins with the client formatting a packet, as shown below, and sending it to the server. The window is the maximum allowable drift between the client clock and the server clock. If the drift exceeds the window time, then the server starts rejecting client credentials and resynchronization is needed. Together, the timestamp and the window determine the expiration time of the credential. Once the credential expires, the server asks the client for a fresh connection.

   The verifier is used to make the communication more secure.

   
   
   

   Credential
   Client's netname
   Conversation key encrypted by common key
   Window encrypted by conversation key
   Verifier
   Timestamp and (window-1) encrypted by conversation key

   
   
   
6. Decrypting the conversation key

   On receiving the transmission from the client, the keyserver (on the server) looks for the public key of the client in server publickey database. Then the server generates a common key using its secret key and client public key by following the same procedure as was followed by the client. This key is the same as the common key generated by the client. The server is now able to decrypt the conversation key. Then using the decrypted conversation key, the server decrypts the client timestamp.

7. Storing the information on the server

   The following information is stored in a table on the server. The first three are stored for future use, while the client timestamp is stored to protect against replays.

   
   
   

   Client's netname

   Conversation key

   Window

   Client's timestamp

   
   
   
8. Client authentication of the server

   The client authenticates the server based on the verifier that the server sends to the client. This verifier includes the client timestamp - 1 (encrypted by conversation key) and the index ID in the server table for this client connection. On receiving the verifier and the server sent timestamp, the client knows that the server was able to correctly decrypt the conversation key and that it is correctly authenticated.

   After the first transaction, the client sends the table index ID in its subsequent transmissions to the server. It also sends the timestamp encrypted by the conversation key (which now both server and client know). In reply, the server sends client timestamp-1 encrypted by the conversation key.

Summary

In this article, you learned how to configure the environment for running Secure RPC applications using DES authentication. You also received an introduction on the basics of the DES authentication process and examined a code snippet of a Secure RPC application.

Resources

Learn

• AUTH_DES authentication: You can view a simple client and server program using secure RPC with AUTH_DES authentication.
  
  
• Communications Programming Concepts : Read this page for the RPC authentication protocol and the authentication types
  
  
• Network Information Services (NIS and NIS+) Guide: Read this guide for information on NIS and how to configure simple and more complex NIS scenarios
  
  
• Diffie-Hellman method: This method ensures that the client and server have the same common key.
  
  
• Administrating NIS+ credentials: This link gives a very detailed explanation about the credentials in NIS+. Much of the same is also applicable to NIS
  
  
• AIX and UNIX: The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
  
  
• New to AIX and UNIX?: Visit the New to AIX and UNIX page to learn more about AIX and UNIX.
  
  
• AIX Wiki: Discover a collaborative environment for technical information related to AIX.
  
  
• Search the AIX and UNIX library by topic:
  • System administration
  • Application development
  • Performance
  • Porting
  • Security
  • Tips
  • Tools and utilities
  • Java technology
  • Linux®
  • Open source
  
  
• Safari bookstore: Visit this e-reference library to find specific technical resources.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  
• Podcasts: Tune in and catch up with IBM technical experts.
  
  

Get products and technologies

• AIX 5L Expansion Pack and Web Download Pack: Start downloading now.
  
  
• IBM trial software: Build your next development project with software for download directly from developerWorks.
  
  

Discuss

• Participate in the developerWorks blogs and get involved in the developerWorks community.
  
  
• Participate in the AIX and UNIX forums:
  • AIX—technical forum
  • AIX for Developers Forum
  • Cluster Systems Management
  • IBM Support Assistant
  • Performance Tools—technical
  • Virtualization—technical
  • More AIX and UNIX forums
  
  

About the authors

Mehul Joshi is a staff software engineer with IBM Systems and Technology Labs in Pune, India. He has been working with IBM since March 2004. He currently works with the General Parallel File System development team. He has previously worked on the Storage Area Network Filesystem and SPKM. You can reach him at mehjoshi@in.ibm.com.

Sagar Dixit is a System Software Engineer with IBM India - Systems and Technology Labs in Pune, India. He has been working with IBM since July 2006 and currently works with the Network File System development team. He is involved with developing security and deployment related new features for NFSv4. He holds a Bachelors degree in computers science engineering. You can reach him at sagar.dixit@in.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Setup required for DES authentication
• Configuring NIS server
• Creating user netnames and public and private key pairs
• DES authentication
• Summary
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into AIX and UNIX on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers