Cryptography – Key management
Reexamination Certificate
1996-12-09
2002-04-23
Hayes, Gail (Department: 2131)
Cryptography
Key management
Reexamination Certificate
active
06377691
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to data processing systems and, more particularly, to utilizing a challenge-response authentication protocol for datagram-based or connectionless remote procedure calls.
BACKGROUND OF THE INVENTION
A “remote procedure call” (RPC) refers to a client program invoking a procedure or function of a remote server program, where the two computer-programs are typically in separate address spaces on a single computer or the two computer programs are on separate computers. After invoking the procedure, the results of the invocation (e.g., success or failure) and any output parameters are usually returned to the client program.
FIG. 1
depicts a block diagram of a conventional system for performing remote RPCs. The conventional RPC system, as depicted in
FIG. 1
, has a client computer
102
interconnected to a server computer
104
by a network
106
. The client computer contains a client program
108
, an RPC runtime facility
110
, and a transport layer
112
. The client program
108
is the originator of an RPC. The RPC runtime
110
receives a message containing a request for the RPC from the client program
108
, encrypts the message, and passes the encrypted message to the transport layer
112
. The RPC runtime
110
encrypts messages that are sent, as well as decrypts messages that are received. The encryption is performed using an encryption algorithm with an encryption key. By using the encryption algorithm with the encryption key, plain text can be encrypted, and conversely, the encrypted text can be decrypted using the same key and the same algorithm. Sometimes the encryption key is only valid for a single session or conversation between the client computer
102
and the server computer
104
. In this situation, the encryption key is referred to as a “session key.”
The transport layer
112
receives an encrypted request for an RPC from the RPC runtime
110
and transmits the encrypted request to the transport layer
118
of the server computer
104
by dividing the request into a number of packets and sending the packets across the network
106
. This technique is known as packet switching. Although the client computer
102
and the server computer
104
appear to be directly connected by the network
106
, in most circumstances, they will not be, and therefore, the packets must be routed between other, intermediate computers (“nodes”) within the network. Each node may be used for routing one or more packets between the client computer
102
and the server computer
104
. There are two techniques for sending packets across a network: virtual circuit transmission and datagram transmission. In virtual circuit transmission, the routing through the network is fixed. That is, a path (a logical connection, i.e., “a virtual circuit”) through the intermediate nodes is predetermined and all of the packets travel over this logical connection. In a datagram transmission, a single path for transmitting all the packets is not predetermined; rather, each packet can be sent on a different path. While virtual circuit transmission provides for predetermined routing decisions, datagram transmission can take advantage of real time fluctuations in network traffic and can lead to increased throughput because routing decisions are made in response to real time conditions in the network as each packet is transferred.
The server computer
104
contains a server program
114
, an RPC runtime
116
, and a transport layer
118
. The server program
114
acts as the recipient of the remote procedure call. In other words, a function of the server program
114
is remotely invoked by the client program
108
. The transport layer
118
performs a similar function to the transport layer
112
. The RPC runtime facility
116
performs encryption and decryption of messages to provide for secure communications and also performs authentication to prevent unauthorized access to the server computer
104
. One type of unauthorized access is known as replay. The term “replay” refers to a situation where an intruder listens to and records the conversation of both the client computer
102
and the server computer
104
and then replays the conversation (i.e., the messages) to violate the integrity of the system. In order to prevent replay and other types of unauthorized access during an RPC, the client computer
102
and the server computer
104
communicate using an authentication protocol that verifies the identity of the originator of the RPC (i.e., the client program being run under a particular user's account). It also verifies that the same packets are not received twice.
When an RPC is performed using a transport layer that communicates using virtual circuit transmission, various authentication protocols can be used because the client is notified when the server terminates the logical connection. That is, in a virtual circuit transmission, the transport layers form a logical connection between the RPC runtime
110
on the client computer
102
, through the intermediate nodes in the network
106
and to the RPC runtime
116
on the server computer
104
. When this logical connection is broken, the RPC runtime on both ends of the logical connection is notified from its respective transport layer. The notification of failure facilitates the use of an authentication protocol in the following way. During the normal processing of an RPC, if the transport
118
has waited for what it considers to be too long of a time without receiving a communication from the transport
112
, the transport
118
may drop the logical connection, upon the occurrence of which the server RPC runtime
116
will be notified and will discard all information relating to the session (“context information”), including the session key used to encrypt and decrypt the messages transferred during the session. In a connection-oriented RPC (i.e., an RPC over a virtual circuit connection), the client RPC runtime receives a notification that the logical connection has terminated and the client RPC runtime can then perform reauthentication and obtain another copy of the session key so that the session can resume. However, in the case of datagram transmissions, since there is no logical connection, the client RPC runtime does not receive a notification that the logical connection has terminated and the server RPC runtime has discarded its context information, so the client RPC runtime does not know to perform reauthentication and obtain the session key and thus the session cannot resume. As such, connection-oriented authentication protocols do not work when using datagram transmission.
To perform authentication for datagram-based remote procedure calls, the Kerberos protocol is typically used.
FIG. 2
depicts a block diagram of the relevant components of a conventional RPC system
200
using the Kerberos protocol. In the conventional RPC system
200
, a client computer
202
is interconnected to a server computer
204
via a network
208
and is also interconnected to an authentication server computer
206
via a network
210
. A program on the client computer
202
invokes a function of a program on the server computer
204
. The authentication server
206
is responsible for creating session keys that will be used by both the client computer
202
and the server computer
204
to encrypt and decrypt messages. The authentication server
206
sends the session keys to both the client computer
202
and the server computer
204
via its connection to the client computer
202
. Obtaining the session key from the authentication server
206
is both inflexible and time consuming, because the authentication server dictates which session key to use, and the client computer is usually connected to the authentication server via a rather slow connection.
Another disadvantage of the Kerberos authentication protocol is the manner in which it prevents replay from occurring. In the Kerberos protocol, replay is prevented by both the client computer
202
and the server computer
204
maintaining synchroni
Shah Bharat
Swift Michael M.
Hayes Gail
Klarquist & Sparkman, LLP
Microsoft Corporation
Seal James
LandOfFree
Challenge-response authentication and key exchange for a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Challenge-response authentication and key exchange for a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Challenge-response authentication and key exchange for a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2828834