Negotiating Trust on the Grid

Story posted September 13, 2005

Faculty Fellow Marianne Winslett is developing a way to broker access to grid resources that will be less cumbersome for users and administrators

Grids connect researchers with far-flung computers, data stores, instruments, and visualization technologies, enabling them to tap the resources they need when they need them. While grids promise to be a boon to researchers, their dynamic, multi-organization nature introduces challenges for both users and administrators. How do you determine who can access grid-connected resources? How do you prevent unauthorized access? How do you provide privacy for the users?

Currently, access control is provided by issuing individual users with identity certificates and local accounts for each resource site. But as the number of users and the number of resources both increase, this approach grows more and more unwieldy, forcing users to juggle multiple certificates and burdening each resource site with the task of issuing and managing accounts.

Policy-based access control is simpler for both users and administrators. For example, rather than issuing passwords to the thousands of graduate students, doctoral candidates, and post-docs across the country who frequently need to access high-performance computing resources, NCSA could decide that any graduate students, doctoral student, or post-doc currently enrolled at or employed by an accredited higher-education institution can access the IBM p690 computing resource. The would-be users will just need to prove ownership of an appropriate credential issued by their institution before they are granted access, a process that is easier to administer than the management of thousands of accounts. The policy-based access is also easier for the users, who don't have to remember multiple accounts and passwords to access resources at different sites or to access multiple resources at the same site.

Marianne Winslett, a University of Illinois professor of computer science, is collaborating with NCSA grid researchers Jim Basney and Von Welch to explore such a technique for brokering access to grid resources. Winslett's project is supported by the UIUC/NCSA Faculty Fellows Program.

Winslett has been working with researchers at the Internet Security Research Lab at Brigham Young University on an automated security agent, called TrustBuilder, that uses a trust-negotiation process to broker access to information and resources. During this process, the client requesting access and the server brokering access exchange digital credentials and policies as they gradually build trust in one another.

Currently, using trust negotiation to perform access control involves embedding trust negotiation facilities, such as TrustBuilder, into the protocols that wish to use it. To simplify the integration of these technologies with protocols and applications that do not support trust negotiation natively, Winslett has worked with Basney and Welch to develop the Traust service. Traust is a stand-alone authorization service that allows users to use automated trust negotiation to establish trust in a previously unknown resource provider and then negotiate for cryptographic tokens, which grant access to legacy resources.

This type of automated negotiation is applicable to many problems, not just the challenge of accessing grid resources. Whenever the source of information or a resource and the individuals seeking access begin as strangers to one another, identity-based security approaches will obviously fall short, while a policy-based strategy using Traust and TrustBuilder can enable qualified individuals to get the information and resources they need, when they are needed.

Consider the electrical power grid, for example, a system of myriad interconnected companies and individuals. The ability to share information could be critical in preventing a local problem from cascading into a massive blackout like the one that left much of the Northeast in darkness on Aug. 14, 2003.

Imagine that an employee at a local power provider notices a potential problem. To better understand the situation, she needs information from ComEd, the company that supplies her company with power. If ComEd has a server equipped to broker information access, the exchange might go something like this:

• The employee goes to a ComEd website. At least, it looks like the ComEd site. But should she just take that on faith? It's critical both that the information she receives is accurate and that she not reveal sensitive information to an unauthorized party. First her Traust client asks for proof that it is communicating with ComEd.
• The server provides a digital copy of ComEd's Federal Energy Regulatory Commission certification.
• Satisfied, the client requests access to information on ComEd's power grid
• ComEd's server sends back the policy on who can access this information. Various credentials are required.
• The client sends some of the required credentials, but before sending the rest it will need to see a copy of ComEd's audit policy.
• The ComEd server sends the audit policy.
• Satisfied, the client sends the remaining required credentials.
• Satisfied, the ComEd server generates a temporary password that will allow access to the requested information and returns it to the employee's Traust client.

The entire back-and-forth negotiation takes place in just a second and without requiring the step-by-step input of the user.

Consider a disaster response scenario. In a crisis, the right people will need fast access to the right information. But how can you know in advance who those people will be? It's unlikely that a comprehensive list of official personnel and potential volunteers can be created and maintained. It's only during the crisis that it will be apparent who needs access to what information.

In the aftermath of an earthquake, for example, a rescue dog handler is ready to volunteer. He knows the state has established a website where qualified volunteers can find information.

When he visits the site, the Traust client asks for proof that it is communicating with a government-certified disaster coordinator. The appropriate credentials are provided, so the client trusts that it is safe to request information. Now it's the server's turn to negotiate trust, asking for various credentials that are needed before the information can be provided. The client trusts the server sufficiently to send some credentials, but isn't ready yet to provide more sensitive information (a driver's license or Social Security number, for example). So the client negotiates again, asking to see a privacy policy. Once the privacy policy is received and deemed acceptable, the client proceeds to provide the remaining required credentials. Finally a password is sent to the client, enabling the volunteer to access the critical information.

The providers and users of grid resources have similar concerns. Resource providers need to be able to specify and enforce restrictions on access and usage, while users need to be able to locate the resources, understand the policies about their use, and use the resources with some level of privacy (such as restricting access to their data). Both the resource providers and the users want the process of exchanging information and creating trust to be easy, secure, and ubiquitous.

Currently, the Traust prototype works with standalone clients. The team is working to embed TrustBuilder into Grid FTP so its operation would be invisible to users, and development is continuing on making the trust negotiation engine more robust.

For more information:
http://dais.cs.uiuc.edu/trustbuilder/
http://dais.cs.uiuc.edu/traust/