For Grid professionals, managing credentials, certificates and private keys across multiple administrative domains can get pretty complicated and tough to scale. This month, Jim Basney -- Senior Research Scientist for the National Center for Supercomputing Applications (NCSA) -- traces the evolution of single sign-on Grid security directions and the momentum of the MyProxy security credentials project.

GCJ: What Grid efforts are you working with primarily today?

Basney: I work on TeraGrid, but through the MyProxy project I have interactions with a lot of Grid projects including FusionGrid, Earth System Grid, EGEE and LHC Computing Grid.

GCJ: So where are you seeing the most action in Grid security today?

Basney: I see a lot of action in four areas, the first being credential management, where MyProxy plays a big role. The second area would be the web single sign-on, browser-based authentication efforts. Third would be authorization services for large Grids. And the fourth would be site security. We have been doing work with MyProxy in each of these areas.

GCJ: Give our readers a run-down on MyProxy, and why it’s relevant to Grid security discussions.

Basney: MyProxy is a component of the Globus Toolkit. It is a credential management service. We focus on X.509 proxy certificates, which are used in the Globus Toolkit security infrastructure. The proxy certificates provide single sign-on. So at the start of your Grid session, you unlock your private key and create a proxy credential that you can use throughout the day for your Grid interactions. Proxy certificates also allow delegation so that you can empower remote terminal sessions, remote jobs, and remote services to act on your behalf on the Grid. So you’re delegating some rights to those services.

If you don’t use MyProxy, the way you would interact with Grid credentials is by managing these files that have a private key and a certificate. MyProxy provides a secure service where you can store and manage your Grid credentials, your certificates and private keys.

GCJ: Is there a CA that owns the MyProxy repository of certificates?

Basney: The MyProxy service can operate in two modes. One is as an online CA. It’s similar to the Kerberos CA. You authenticate to the MyProxy service and the CA component will issue a short-lived certificate immediately that is typically good for 12 hours.

Alternatively, you can get a certificate from an existing CA and then store either that certificate directly or a proxy certificate from that original certificate into the MyProxy service, and that uses MyProxy’s repository functionality. This way, you have your credential from any CA stored in the MyProxy repository and you can later retrieve these proxy credentials from the repository when you need them for different sessions or for different sites where you log on.

GCJ: Do you turn a server into a MyProxy server, or is it just a service that would run on a server?

Basney: It’s a service that would run on a server. Typically, it runs on a dedicated server because it requires high security in that you’re storing your private keys on this dedicated secure server rather than storing them on desktops or on multipurpose systems that are potentially more vulnerable to compromise.

GCJ: Who developed MyProxy? Have there been any new technical directions?

Basney: MyProxy was originally developed by Jason Novotny, Steve Tuecke and Von Welch in 2000 and we have continued development on it since then. In the past year, some exciting developments include the online CA capability that I mentioned previously. That was developed as a contribution to MyProxy by Monte Goode at Lawrence Berkeley National Laboratory, as part of his work on the FusionGrid.

Prior to that, MyProxy was a credential repository but didn’t have the ability to issue new credentials to users. It required a separate CA. This new CA functionality gives additional flexibility, doesn’t require you to have a separate CA, and gives you online CA capability where you don’t have long-lived certificates to manage.

Something else that has been developed in MyProxy over the past year has been a number of mechanisms that allow integration with existing site authentication infrastructure. For example, MyProxy has been integrated with One Time Password hardware token authentication at NERSC and NCSA for issuing Grid credentials. We use PAM ("pluggable authentication modules" ) and SASL ("simple authentication and security layer") which are two very standard mechanisms for plugging into UNIX authentication.

One of the reasons we like to plug MyProxy in to the different systems is to get closer to this holy grail of single sign-on, where I don’t have different islands of single sign-on – a Grid single sign-on, a web single sign-on, a Kerberos single sign-on. With one single sign-on, I can retrieve additional credentials for the different security protocols as required. Some of this work, integrating with PAM and SASL, was inspired and assisted through NMI GRIDS Center and its work with the LTER Grid pilot study.

GCJ: Do you see MyProxy in pervasive use with Globus users or with Grid computing users across the board?

Basney: MyProxy is in wide use for most of the major Grid projects, from TeraGrid to the LHC Computing Grid, FusionGrid, the European EGEE, and Earth System Grid. It’s often the big projects that are able to put up the infrastructure to support a secure MyProxy service, to give users this capability to administer credentials.

In MyProxy’s six-year project lifetime, it’s continued to be used widely in a number of different cases. It’s popular as a web portal Grid security mechanism. The major Grid portal toolkits, which are GridPort, OGCE, and GridSphere, all interoperate with MyProxy so that users can authenticate to the portal and get their Grid credentials. It’s also used for managing credentials for FusionGrid and for the different TeraGrid sites.

Another popular use of MyProxy is for renewing short-term credentials for long-lived jobs. This is a use that’s really pioneered by the European Grids, starting with EU DataGrid and now EGEE and the LHC Computing Grid. When you submit your job, the job manager service can go and refresh the job’s credentials as needed as the job runs. This is preferable to giving the job a very long-lived credential with the longer-lived exposure.

GCJ: Are you getting any feedback regarding security vulnerability concerns with the Grid efforts that you’re working on?

Basney: People are very concerned about long-lived private keys, where users have keys that are good for one to three years, and they’ve copied them to different systems. The danger is if one of those systems is compromised, that key can be used by the attacker. To combat that potential vulnerability, the online CA work has been inspired to issue short-lived credentials with short-lived keys.

Another security concern that we hear about revolves around site security. Especially with Grids, as we’re encouraging more collaborative work between sites and enabling that through single sign-on and making it easy for connecting sites together for large computations or sharing data -- there’s a concern that an attacker could get in and benefit from those connections. Theoretically, an attack at one site could easily spread to other sites.

We’ve been looking at work with intrusion detection systems and adaptable security. The idea is to maintain the openness of our sites and encourage the collaborative nature of our sites, but have the ability to detect when something’s going wrong and when it would be wise to temporarily shut off some links or change our security posture until the threat is over.

GCJ: Tell us more about the Mithril project and Dependable Grids projects you’re involved with.

Basney: The Mithril project is funded by the Office of Naval Research, through the NCASSR (National Center for Advanced Secure Systems Research) here at NCSA. This project is looking at how to have adaptable site security when you want to maintain an open, distributed, collaborative environment across administrative domains and across sites. We’re looking at a model of, first, hardening systems to prevent compromises, detecting compromises when they occur, and then responding by having adaptable mechanisms that change the authentication requirements for a site, service or account on the fly.

The Dependable Grids project brings together Grid and dependability researchers at the University of Verginia. They have a system called Willow that we’re building on. Again, we want to have this adaptability and survivability so that when the Grid is under attack, we can change the level of service that’s provided until the attack is dealt with.

GCJ: How frequent are attacks on Grid environments now?

Basney: I’m not aware of a lot of hacking specifically targeted toward Grid infrastructure. Attacks we see primarily target the more common underlying infrastructure like Microsoft Windows, Linux or SSH. Sometimes security incidents are labeled “Grid incidents” when then really involve the underlying software running at Grid sites.

GCJ: Any thoughts about Grid security that you’d direct to our enterprise / commercial readers?

Basney: One lesson that I think could carry over well into the commercial realm is that there’s not one single security solution that will fit in all cases. To support secure collaboration, you need translation services and bridging services between different security mechanisms and protocols and credential formats. I think we’re seeing a lot of good work in web services bridge between X.509 PKI credentials and SAML credentials.

close window