Trust negotiation in a client/server data processing network...

Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing – Network resources access controlling

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C713S169000, C713S152000, C713S152000

Reexamination Certificate

active

06349338

ABSTRACT:

FIELD OF THE INVENTION
The invention relates to the field of client/server (also known as “distributed”) computing, where one computing device (“the client”) requests another computing device (“the server”) to perform part of the client's work.
BACKGROUND OF THE INVENTION
Client/server computing has become more and more important over the past few years in the information technology world. This type of distributed computing allows a software process (e.g., the client) running on one machine to delegate some of its work to a software process (e.g., the server) running on another machine that might be, for example, better suited to perform that work. The client and server could also be separate software processes running on the same machine.
In such client/server systems, it is very important that the client and the server develop a sufficient level of trust in each other before they engage in a meaningful interaction, because the information that may be exchanged during the client's request for server processing and/or the server's processing result which is returned to the client may be highly sensitive information. Oftentimes, the client and the server have no prior relationship with each other and thus they must enter into some type of an initial conversation in order to determine whether they can trust each other before they disclose any potentially sensitive information. A good example of where this is particularly useful is when the client is a World Wide Web browser application sending electronic commerce requests over the Internet to a World Wide Web server application. On the initial interaction between these parties, the Web client and the Web server do not have any prior relationship and the Web client, for example, may be very reluctant to provide a credit card number to the Web server over the Internet.
It is known in the prior art to exchange credentials (i.e., digitally signed assertions by the credential issuer about the credential owner) between a client and a server in order to develop trust between them. A credential is signed by using the issuer's private key and can be verified by using the issuer's public key. The credential aggregates one or more attributes of the owner, each attribute consisting of a name/value pair and describing some property of the owner asserted by the issuer. Each credential also contains the public key of the credential owner. The owner can use the corresponding private key to answer challenges or otherwise demonstrate ownership of the credential. The owner can also use the private key to sign another credential owned by a third entity.
Thus, as is well known in the prior art, credentials may be combined into chains, where the owner of one credential is the issuer of the next credential in the chain. These chains can be submitted to trace a web of trust from a known entity (the issuer of the first credential in the chain) to the submitting entity, in whom trust needs to be established. The submitting entity is the owner of the last credential in the chain. The submitting entity can demonstrate ownership of that credential by demonstrating possession of the private key mate of the public key contained therein. The other supporting credentials are owned by entities with whom the submitting entity has direct or indirect relationships, and although they are not owned by the submitting entity, the submitting entity does keep and submit copies of them. Each supporting credential contains the public key whose private key mate was used to sign the next credential in the chain.
All the submitted credentials are relevant to demonstrating a (possible indirect) relationship between the submitting entity and the known entity that issued the first credential in the chain. The nature of that relationship can be inferred by inspecting the attributes of the credentials in the chain. Multiple chains can be submitted to establish a higher degree of trust or to demonstrate additional properties of the submitting entity and its relationships with known entities.
Prior art techniques for using credentials to establish mutual trust can be divided into two basic approaches. The first approach is described by A. Frier, P. Karlton, and P. Kocher, “The SSL 3.0 Protocol”, Netscape Communications Corporation, Nov. 18, 1996; T. Dierks, C. Allen, “The TLS Protocol Version 1.0”, draft-ietf-tls-protocol-06.txt, Nov. 12, 1998; S. Farrell, “TLS Extensions for Attribute Certificate Based Authorization”, draft-ietf-tls-attr-cert-01.txt, Aug. 20, 1998. This approach will be referred to as the SSL approach, as it is used by SSL, TLS, and TLS with extensions for attribute-certificate-based authorization. In the SSL approach, the client and the server can exchange credentials as follows. The server initiates the negotiation by unilaterally disclosing a pre-selected credential. It can include a request for client credentials, including the type of credential the server can accept and, in the attribute-certificate case, a template indicating the required attributes.
The second approach is described by N. Ching, V. Jones, and M. Winslett, “Authorization in the Digital Library: Secure Access to Services across Enterprise Boundaries”, Proceedings of ADL '96 - - - Forum on Research and Technology Advances in Digital Libraries, Washington, D.C., May 1996, available at http://drl.cs.uiuc.edu/security/pubs.html; and also by M. Winslett, N. Ching, V. Jones, and I. Slepchin, “Using Digital Credentials on the World-Wide Web”, Journal of Computer Security, 5, 1997, 255-267, available at http://drl.cs.uiuc.edu/security/pubs.html. We will call this second approach the digital credentials approach. In this approach, when a request for service is made by a client to a server without adequate credentials attached, the server sends to the client a policy governing that service. A policy is a credential formula, that is, a logical combination of required credentials and expressed constraints on the attributes that they contain. Policies can be used to characterize required properties of the submitting entity and its relationships with known entities. By receiving this policy as a request for credentials, the client has the opportunity to select in private credentials to submit to authorize service. By sending policies to clients, servers off-load credential selection. The practice also enables different servers to have very different policies, requiring different client attributes and accepting credentials issued by different authorities.
Both of these two prior art approaches support the server sending a request for credentials to the client, including a characterization of credentials that would be acceptable to the server. However, the present inventors have noted deficiencies in this present state of the art as follows.
In the SSL approach, there is no opportunity for the server to authenticate any information about the client before disclosing the server's credential. The server may regard its credential as highly confidential, and thus, if the client and server fail to establish mutual trust, then the server has turned over to the client a highly sensitive (confidential) piece of information. Furthermore, if the credential disclosed by the server does not satisfy the client, the client has no opportunity to request additional credentials from the server. This can be a serious problem when the client and server have no prior relationship. In that case it is unlikely that any single credential issuer would be an acceptable authority on all server attributes of interest to all clients.
The shortcoming of prior systems based on the digital credentials approach arises with credentials that the client wishes to disclose only to servers in whom some degree of trust has already been established. Prior systems developed using the digital credentials approach have supported client-credential submission policies that partitioned services into equivalence classes and then, for each equivalence class, assigned each client credential to one of two categories. Cred

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Trust negotiation in a client/server data processing network... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Trust negotiation in a client/server data processing network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Trust negotiation in a client/server data processing network... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2960018

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.