 |
Description  |
|
|
BACKGROUND OF THE INVENTION
The present invention relates to improving the security of data transmission between computers using an insecure network, particularly to methods and systems for improving the integrity and security of messages transmitted from a client to a
network server and then to a destination server or from the destination server to a network server and then to the client as part of a distributed computer system.
A distributed computer system contains multiple distinct computers, which are interconnected. One simple example of a general-purpose distributed system is a networked system containing several workstations and servers interconnected through a
network. Networks are popular because they allow organizations to share information and resources. Furthermore, in a networked system, if one computer breaks, or "crashes," the others may continue to operate.
The type, cost and reliability of the manner of interconnection can be important considerations in networked systems. Large networks over relatively short distances typically use local area networks (LAN) such as an Ethernet or a Token Ring,
which permit communications between a number of different computers on one or more wires. The use of modems allows computer networks to be created over a larger area, because the connections can be made over data links such as telephone lines. Wide
area networks (WAN) typically use a combination of fiber optic and copper wire telephone lines as well as microwave links and satellites to connect several smaller LANs. Networks of networks are often referred to as internetworks.
Computer networks, particularly internetworks, can be vulnerable to security breaches. The degree of security of each component in the network differs, in part because each entity may be protected by varying layers of physical and operational
security. Furthermore, each component or network in an internetwork may be owned or controlled by different organizations whose security practices differ widely. The interconnections between the computers may be similarly insecure. Since some part of
the network may use physically insecure links, such as telephone lines or microwave links, hackers and interlopers may eavesdrop or intercept communications over the telephone line and modify them according to their wishes or copy them for later use.
Interlopers who copy login and/or command information have the potential to use that information to gain access to other computers on the network.
Network security is typically based on three general concepts. For every request to do an operation, such as execute a diagnostic routine or perform a remote login, the network 1) authenticates the request; 2) controls access via access control
criteria; and, 3) audits every request to detect unauthorized uses.
Authentication is the process of determining that an authorized user initiated the request and that the request was not modified improperly by an interloper on the way to the destination. One common example of authentication is the use of a
password at time of login. Upon receiving a username and password from the user, a host computer compares the password to a list of authorized usernames in an access control file, and if the password matches the password associated with that username,
the host computer allows access. In the situation just described, however, it is assumed that the user and host are communicating over a secure connection; otherwise, interlopers could intercept the communications from the user to the host and steal the
username and password information. The interloper could then illegally access the host at a later time by using the stolen username and password information.
In a networked system comprising multiple interconnected computers, a first computer may request service from a second or destination server through an intermediate server. This first computer is typically called a client. In order to receive
service from a destination server, the client must begin by authenticating itself to the destination server. However, because the client may be communicating to the destination server over an insecure line, the client cannot simply send a password in
the clear. Instead, the client and the destination server may engage in a multiple query and response exchange, constituting an authentication process, which will convince the destination server that the requesting client is an authorized user.
The prior art includes examples of encryption-based authentication processes that can be used to so authenticate a client to such a server. Such authentication processes can be based either on public-key or secret-key encryption systems. In a
typical secret-key authentication scheme, each authorized party possesses a secret key, which is known only by the party and is registered with a trusted third party, or authentication server. The authentication server maintains a list of registered
users and secret keys and, therefore, must be physically secure. By contrast, in a public-key authentication system, each user has a public key and a private key. The public key is posted; the private key is known only to the user. Authentication
using a public-key authentication system is attractive because it does not require a secure authentication server.
One example of a secret-key based network authentication system is the trusted third-party authentication service called Kerberos. Network services and clients requiring authentication register with Kerberos and receive a secret key, where said
key (or a pass phrase from which it can be derived) is known only to the user and a Kerberos host server. Kerberos also generates temporary session keys, which can be used to encrypt messages between two registered Kerberos principals (users or hosts).
A typical Kerberos software package is Kerberos Version 5 from Project Athena at the Massachusetts Institute of Technology (MIT). The Kerberos authentication scheme also is discussed in J. Kohl and C. Neuman, The Network Authentication Service (V5),
Request for Comments: 1510 (September 1993). Kerberos and other trusted third-party private authentication schemes can allow for speedier, secure access between two principals.
Other prior art systems have been developed to address network security issues. For example, two authentication protocols, Secure Sockets Layer (SSL) and Secure Hyper Text Transfer Protocol (S-HTTP), have been designed specifically to protect
the information being transmitted across the Internet by using encryption. Both the client and the destination server must support SSL. SSL is application independent and operates at the Transport layer, meaning that it operates with application
protocols such as HTTP, ftp, telnet, gopher, Network News Transport Protocol (NNTP), and Simple Mail Transport Protocol (SMTP). SSL supports several cryptographic algorithms to handle the authentication and encryption routines between the client and the
server.
S-HTTP is a secure extension of HTTP, a communications protocol of the World Wide Web. S-HTTP is a publicly available protocol developed by Enterprise Integration Technologies. Unlike SSL, S-HTTP is more closely related to the HTTP protocol.
Also, while SSL typically encrypts the communications link between a client and a server, S-HTTP can encrypt each message individually. In a client/server transaction under S-HTTP, the client does not need to possess a public key. Secure transactions
may take place at any time, because the sender of an S-HTTP message sends its cryptographic preferences along with the message.
A current trend in distributed system development is the concept of managed hosts. In a managed host system, a client will access a network server and, via the network server, request access to a second server, which may be referred to as the
remote host, or the managed host. In larger networks, the network server may be acting as a gateway and proxy for a large number of clients to access a large number of destination servers. In order for the transaction from a client to a destination
server to be secure, both the transactions between the client and the network server and the transactions between the network server and the destination server should be secured by a network authentication process.
In a certificate-based authentication scheme, all entities that wish to communicate with one another must register with a third party called a certificate authority. The certificate authority verifies the identity of the registering party and
issues certificates which the parties can then use to authenticate themselves to other registered parties. There are many certificate authorities offering suitable certificates of authentication including, for example, IBM's World Registry and Sun
Microsystem's SunCA.
There are a number of problems associated with simply using one type of authentication process to secure the transactions between the client and network server and those between the network server and the destination server. Use of this system,
for example, would require that the network server, all clients and all destination servers possess a certificate ultimately traceable to the same top-level certification authority. Furthermore, each individual user of a client system must be issued a
client certificate. If the client certificates were stored on the individual workstations, the client would be restricted to using only particular workstations. If the client certificates were stored on a portable media, such as diskettes, they would
be subject to loss or theft, decreasing the security of the overall network system. Moreover, client workstations may be any one of a number of different hardware devices, such as PCs or Macintosh, running a variety of different operating systems, such
as UNIX or DOS, and there is no single medium supported by all the varieties of clients. In summary, use of a certificate authentication scheme between the client and the network server would be administratively difficult to support.
If Kerberos authentication for all transactions is used, each client workstation is required to possess the software necessary to communicate with the key distribution center. This approach encounters problems including that of providing many
different versions of the software to support the many varieties of clients.
If one authentication scheme is used to secure transactions between the client and the network server, while another authentication scheme is used to secure transactions between the network server and the destination server, then in transactions
between the client and the destination server, the network server must act as a proxy for the client, and it may sometimes be undesirable to require the network server to perform client authentication. Since, by using two different authentication
schemes, the client would not be authenticating itself to the destination server directly, the network server needs to act as if it has the identity and memory of the client server. In server-to-server transactions, the user typically has logged on to
the network server using a shell program. The shell program creates records on the network server that maintain a record of the user's identity and use (i.e. time and date). As long as the user is logged on, the shell logon program exists. In
contrast, in a client-to-managed host transaction, the shell logon program is active on the client computer, but not on the server. The network server, instead, is interfacing with a key distribution center, or authentication server, on behalf of the
client. To do this, a network server configured as a World Wide Web server creates and executes transient processes (such as when an HTTP Common Gateway Interface (CGI) request is executed) to query the key distribution center. These temporary
processes must assume in some sense the identity of the user for the length of the transaction. Once their function is complete, however, these transient processes terminate and disappear, resulting in the loss of any identity or session state data they
may have acquired.
When a network server does not maintain any information on a client once it has finished processing a request by the client, the server is described as stateless. A stateless file server avoids retaining client information by deriving
information about files and positions within files from the request itself. A stateful server (e.g., one that stores file information in volatile memory) loses the information when the server crashes. In addition, if the client fails, the server may be
unaware that the client is no longer using the space allocated to retain information needed for the transactions and may be unable to reclaim the space. In contrast, following the crash of a client or server, the stateless server need only respond to
the last fully self-contained request from the client to continue the operation. In a UNIX operating environment, the UNIX processes (e.g. daemons) are sometimes stateful. Individual transient processes, however, are not persistent and, therefore,
cannot maintain state information internally.
There is a need, therefore, for a method of and system for increasing security of transactions involving multiple networked computers, and for increasing security of transactions involving a client that sends commands to a managed host via an
intermediate server through a insecure connection such as the Internet.
There is also a need for a method of and system for increasing security of transactions involving a client, a network server, and a managed host, where the client is not restricted to one of a limited subset of devices or operating systems
because of interoperability or administration concerns.
Moreover, a need exists for a method of and system for increasing security of transactions involving a client, a network server, and a managed host, where the increased security is attained by using an SSL protocol for communications between the
client and the network server, a Kerberos authentication system is used to authenticate the identity of the client to the managed host and the managed host to the client, and the client communicates with the managed host through an insecure network
connection such as the Internet.
Needs also exist to allow many varieties of clients to communicate with a destination server via a network server over an insecure network connection using authentication protocols and to allow transmission of data or commands over an insecure
computer network from a client to a destination server via a network server.
Another desire is for a system and method to allow necessary client information to pass to the network server with each transaction so that the network server may access the destination server on behalf of the client.
Further objects of the present invention will become apparent from the following drawings and detailed description of the preferred embodiments.
SUMMARY OF THE INVENTION
Systems and methods consistent in this invention increase security of data transmissions between a client, a network server and a managed host using an insecure network, such as the Internet. After establishing a secure network connection
between a client and a network server, a secure authentication protocol is used to obtain at the network server client-authenticating information from a key distribution center. The client-authenticating information is transmitted from the network
server to the client and erased from the network server. The client-identifying information is transmitted back to the network server from the client along with a message for the destination server. Permission is obtained to access the destination
server from the key distribution center over the insecure network using the secure authentication protocol. At the destination server, the authority of said client to access said destination server is validated using the message. The destination server
is accessed with the message if the client's authority is properly validated.
Establishing the secure network connection between the client and the network server can use the Secure Sockets Layer (SSL) protocol. Obtaining client-authenticating information and securing the network connection between the network server and
the destination server can use the Kerberos authentication protocol. Access to the destination server by authenticated users can be controlled by access control lists on the destination server.
A computer system consistent with the present invention, comprises a first computer server, such as a client, that issues commands over a network connection, and a second computer server, such as a network server, responsive to the first server
and for accessing a fourth server on behalf of the client. The first and second servers can communicate via the same network operable connection therebetween. The second server also has an authentication device capable of generating an authentication
request on behalf of the first server. A third computer server, such as a key distribution computer, receives the authentication request, responds to the request to authenticate the identity of the first server, and sends authentication indicator
information regarding the first server back to said second server via the network. A fourth computer server, such as a managed host, is also interconnected to the network for receiving and executing the command from the first server if the network
server transmits the authentication indicator information to the managed host and if the first server is authorized to access the fourth server.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate presently preferred embodiments of the invention and, together with the general description given above and the detailed description of
the preferred embodiments given below, serve to explain the principles of the invention.
FIG. 1 is a block diagram of one system that may be used to implement the present invention.
FIG. 2 is a more detailed block diagram of the client and network server of FIG. 1.
FIG. 3 is a more detailed block diagram of the client, network server, key distribution center, and destination server of FIG. 1.
FIG. 4 is a block diagram of another system that may be used to implement the present invention.
FIGS. 5-5a are flow charts showing the operation of the system of FIG. 4 in accordance with the present invention.
FIG. 6 is a block diagram showing additional aspects of the system of FIG. 4.
FIGS. 7-7b are flow charts showing the operation of the system of FIG. 6 in accordance with the present invention.
DETAILED DESCRIPTION OF THE INVENTION
A. First Embodiment
The method and apparatus useful to implement the present invention will first be discussed in general with reference to FIGS. 1, 2, and 3.
As shown in FIG. 1, the present invention uses a client workstation (indicated generally as client 200), which can be, by way of example only, a personal computer (PC) running Microsoft Windows, Windows95, or WindowsNT, a MacIntosh or a UNIX
workstation. Client 200 is connected to an insecure network 250 (such as the Internet) via data link 202. A network server 300, which communicates with client 200 along insecure network connection 250, can, by way of example only, be a UNIX server.
Network server 300 is connected to insecure network connection 250 via data link 204 as well as a second insecure network connection 350 via suitable data link 302 and a third insecure network connection 450 via suitable data link 304. Destination
server 500 communicates with network server 300, also through the insecure network connection 450, via data link 360. Destination server 500 can be, by way of example only, a UNIX server. A key distribution center (KDC) 400, which validates requests to
establish proper identity, is likewise in communication with network server 300 through data link 370 and insecure network connection 350.
It is understood that FIG. 1 describes an exemplary network where each of the hardware components may be implemented by conventional, commercially available computer systems. Data links 202, 204, 302, 360, and 370 can be any suitable
communications medium, such as, for example, data links using modems. Also, by way of example only, each computer or server can operate using an operating system such as UNIX.
Additionally, network server 300 and KDC 400 may contain information that can be used to compromise the security of the system, therefore, physical access to network server 300 and KDC 400 should be adequately controlled.
1. Establishing a Secure Network Connection Between a Client and a Network Server
In the embodiment of FIG. 1, client 200 and network server 300 communicate via insecure network 250. Client 200 is connected to insecure network 250 via data link 202 which, by way of example only, may be a TCP/IP network connection. Network
server 300 is connected to insecure network 250 via data link 204 which also may be a TCP/IP network connection. To enhance message privacy and integrity, client 200 and network server 300 preferably communicate using a secure authentication and/or
encryption protocol to establish a secure network connection between client 200 and network server 300. Any suitably reliable publicly available authentication protocol may be used, provided that such protocol is capable of successfully proving the
identity of network server 300 to client 200 to thereby result in confidence on the part of client 200 that future communications are with network server 300 and not some impersonating entity. The authentication protocol preferably also produces a
session key that is known only to client 200 and network server 300 and which can be used to encrypt subsequent transactions between client 200 and network server 300. One example of such an authentication protocol that has been developed specifically
for use with TCP/IP Internet connections is the publicly available Secure Sockets Layer (SSL) protocol, Version 3.0, developed by Netscape Communications Corporation.
FIG. 2 shows in more detail one embodiment of the manner in which communications can be carried out between client 200 and network server 300. As shown in FIG. 2, client 200, which can include a web browser 205, initiates a request for
authenticated secure access to the web server 305 of network server 300 as indicated by arrow 206. Client 200 may be operating any publicly available web browser software package such as, for example, Netscape Navigator. Because the request may be
transmitted in the clear across an insecure communications link, the request at 206 should not contain login or password information.
Web server 305 of network server 300 responds to the request at 206 by transmitting information back to web browser 205 that will be used to authenticate the identity of network server 300 to client 200 and support generation of additional
information which will be used to encrypt future transmissions between client 200 and network server 300. If, for example, an SSL transaction is employed in the system of FIG. 2, web server 305 sends web browser 205, as indicated by arrow 208, a
certificate that includes network server 300's public key and an identifier indicating a cryptographic algorithm supported by network server 300. To properly establish the connection, network server 300 and client 200 perform a handshake process
indicated at arrow 210 which, if successfully completed, provides both client 200 and network server 300 with a session key known only to network server 300 and client 200. This session key can be used to encrypt future transactions between network
server 300 and client 200. In the handshake process of SSL, for example, client 200 creates a session key, encrypts the session key using one of the cryptographic algorithms indicated by network server 300 in the certificate and the public key sent by
network server 300, and sends the encrypted session key to network server 300. After receiving the encrypted session key, network server 300 authenticates itself to client 200 by decrypting this session key and returning to client 200 a message
encrypted with the underlying session key.
When the handshake indicated at arrow 210 is successfully completed, client 200 and server 300 continue to use the session key to encrypt future transactions. As depicted generally in FIG. 1, the connection 202 and 204 between client 200 and
server 300 are therefore protected to the degree of security achieved by the encryption algorithm.
Once an appropriately secure network connection is established between client 200 and network server 300, server 305 now sends a login form to client 200, and as indicated at 212, client 200, returns login data consisting of the name and password
of a Kerberos principal to web server 305.
2. Authenticating a Client to a Key Distribution Center and Obtaining Client-authenticating Information from the Key Distribution Center
FIG. 3 depicts, by way of example only, the process of obtaining client-authenticating information from KDC 400 over an insecure TCP/IP network 350, such as the Internet, that will later be used to establish that network server 300 is acting on
behalf of the Kerberos user principal. Other publicly available secure authentication protocols may be used. The security of the system, however, may be enhanced further by implementing an authentication protocol that incorporates the use of
timestamps. Timestamps can be used to restrict replay attacks, or the recording of some portion of an authentication protocol sequence and use of old messages at a later date to compromise the authentication protocol.
One example of a publicly available authentication protocol using timestamps is Kerberos Version 5 developed by Project Athena at MIT. The preferred embodiment as described below assumes the use of Kerberos Version 5. The details of this
authentication procedure follow.
Once web server 305 receives encrypted login information from web browser 205 as indicated by arrow 356, network server 300 passes the Kerberos user principal name of client 200 and a request for a permission indicator to KDC 400 over insecure
network 350 as indicated by arrow 352. Upon receiving the request for a permission indicator at 352, the KDC 400 generates a KDC session key for protecting transactions between network server 300 and KDC 400.
Using client 200's Kerberos user principal name received at 352, the KDC 400 extracts client 200's secret key from key database 405, which stores secret keys used by KDC 400 and other properly registered clients. Using client 200's secret key,
the KDC 400 then encrypts one copy of the KDC session key and creates a permission indicator, which would typically include by way of example only, a timestamp, client 200's user name and network address, and another copy of the KDC session key. This
permission indicator will be used later by client 200 to authenticate itself to KDC 400. The permission indicator is encrypted with KDC 400's private key, which is known only to KDC 400; KDC 400, therefore, can later decrypt the permission indicator to
verify its authenticity.
KDC 400 then sends both the encrypted session key and the permission indicator back to the network server 300 as indicated at arrow 354. Network server 300 receives the encrypted information from KDC 400, and decrypts the KDC session key using
client 200's user key. In one embodiment, the client user key is a one-way hash of client 200's password and other information, so the network server is able to derive the user key by hashing client 200's password. Both the permission indicator and the
KDC session key are stored in credentials cache 320. Web server 305 encodes the contents of the credentials cache 320 and, as indicated at arrow 357, sends the contents of the credentials cache 320 to web browser 205. The authenticating information
that may have resided in the network server 300 is then erased or otherwise deleted. Thereafter, in order for client 200 to continue with the transaction, client 200 will have to refresh the memory of server 300. If a hacker or interloper managed to
gain access to network server 300 while information was stored in credentials cache 320, only the permission indicator and session key could be obtained, because the Kerberos password is destroyed after being used. This information would be of limited
value, however, because the permission indicator, in the preferred embodiment, would contain a date/time stamp and would become worthless after a specified period of time, usually relatively short, has elapsed.
3. Sending a Command to a Destination Server
Now that it has the encoded credentials cache information from cache 320, client 200 can send this cache information along with a message, such as a command ultimately intended for destination server 500, to the network server 300 as indicated at
arrow 358. Network server 300 decodes the encoded credentials cache information and stores the permission indicator and KDC session key in a credentials cache 330. Although this credentials cache 330 is not the same as credentials cache 320, which as
described above, the data therein is the same. In actuality, the information could be stored in the same location on the same physical storage device, although as a practical matter this is highly unlikely.
As indicated at arrow 360, network server 300 now sends the permission indicator encrypted by the session key to KDC 400, along with an authenticator and a request to access destination server 500. This authenticator contains the Kerberos user
principal name and a time stamp, encrypted using the KDC session key. KDC 400 decrypts the permission indicator using the KDC secret key to obtain the KDC session key and a validity period. If the KDC 400 decrypts successfully, the KDC is assured that
the permission indicator is the same one that it issued earlier. The KDC 400 then uses the KDC session key to decrypt the authenticator to obtain the Kerberos user principal name and a time stamp. If the time stamp is within the validity period, the
KDC 400 generates an access indicator. The access indicator typically would include the Kerberos user principal name, a validity period, and a server session key for use between network server 300 and destination server 500, all of which has been
encrypted with the private key of the destination server 500. KDC 400 then sends to network server 300 the encrypted access indicator, and a copy of the server session key encrypted using the KDC session key, as indicated at arrow 362.
Thereafter, network server 300 decrypts the copy of the server session key that is encrypted using the KDC session key. Network server 300 then encrypts the message or command, using the server session key and, as indicated at arrow 364, sends
the encrypted message along with the access indicator and a new authenticator to destination server 500 via insecure network 450. Destination server 500 uses its own private key to decrypt and obtain the server session key.
By using the server session key, | | |
