 | Level: Intermediate Mehul Joshi (mehjoshi@in.ibm.com), Staff Software Engineer, IBM
Sagar Dixit (sagar.dixit@in.ibm.com), Software Engineer, IBM
12 Feb 2008 Find out how to use Secure RPC using Data Encryption Standard (DES)
authentication on AIX® 5.3 to achieve a secure communication between the
client and server. In this article, you'll examine the setup required to initiate
Secure RPC between the client and server, DES authentication, and how to make
applications secure using the Secure RPC application programming interfaces (APIs).
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.
- 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
#
|
- Set the domain name using the
chypdom command.
- 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.
#
|
- Start the
ypserv daemon for the master NIS server.
# startsrc -s ypserv
0513-059 The ypserv Subsystem has been started. Subsystem PID is 319736.
#
|
- 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.
#
|
- 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
#
|
- Start the
ypbind daemon.
# startsrc -s ypbind
0513-059 The ypbind Subsystem has been started. Subsystem PID is 118826.
#
|
- Edit the /etc/nsswitch.conf file and add following:
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:
- Add a new user.
# mkuser userone
# passwd userone
# id useroneuid=249(userone) gid=1(staff)
|
- Start the
keyserv daemon.
# startsrc -s keyserv
0513-059 The keyserv Subsystem has been started. Subsystem PID is 344274
#
|
- 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 ...
|
- 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
|
- Update the NIS database netid maps.
# cd /var/yp
# make netid
updated netid
pushed netid
Target "netid" is up to date.
#
|
- Start a duplicate login session and log in as userone.
- Run the
keylogin command.
Run the client application now.
DES authentication
The following section outlines the steps in DES authentication:
- 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.
- 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.
- 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.
- 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.
- 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 |
- 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.
- 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 |
- 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
Get products and technologies
Discuss
- Participate in the
developerWorks blogs
and get involved in the developerWorks community.
- Participate in the 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 software engineer with IBM Systems and Technology Labs in Pune, India. He is involved with developing security and deployment of new features for NFSv4. He holds a bachelor's degree in computers science and engineering. You can reach him at sagar.dixit@in.ibm.com. |
Rate this page
| |
