Touching Base with the GGF's Security Area

Over the last 10 years of Grid evolution, the GGF has been the center of gravity for identifying security challenges and associated scalability issues - focusing on specific technical requirements through end user feedback, and ushering the best protocols and techniques into standardization. This month, the Globus Consortium Journal caught up with GGF Security Area Directors - Olle Mulmo and Dane Skow - to get their take on where the security action is in the Grid community today, and the specific challenges that the GGF and its broad community base are working hard to reconcile.

GCJ: Where do you see the most activity right now with Grid security?

Mulmo: It's in two places primarily. First, it's in the authorization space - how to better do distributed access control that map to user's needs in regard to finer-grained authorization. That is, to easily constrain and describe who has access to what. Scaling that is not easy because the finer-grained you get, the more complex the whole configuration and usage and protocols. The complexity just explodes as you scale and distribute.

The second is finding replacements or additions in the identity space. To date, we have used X.509 certificates. PKI is good, but it has its limitations, and there are other ways of identifying yourself. In an enterprise world, for instance, if you already have your Active Directory with user names and passwords for all your users, why should you set up something different because you're doing Grid?

GCJ: Tell us a little more about the limitations / challenges with certificates?

Mulmo: First, users can't handle them properly. They don't understand them. Typically, they choose the null password to protect their credentials, so they don't have to type it in. Or they choose a bad password. Second, these certificates and keys are spread all over where people need access, Internet kiosks and the like, and then they're left around. Also, the whole management and handling of certificates is complex. They have their purpose -- and we wouldn't have come as far as we have come today if it weren't for these things -- but we're looking for additional ways to make the management aspect of certificates hidden underneath something less complex.

In particular, if you look in the academic space, there's a big upheaval right now around single sign-on technologies based on Shibboleth, which is an Internet2 technology. There are at least five or six efforts to combine Grid and Shib currently underway (including NCSA), and all of them are looking at ways to combine these technologies from different points of view. At GGF-16 in Athens a couple of weeks ago, these teams organized a workshop to discover how their efforts are overlapping, and how they are complementary. Production Grids are interested in scaling up significantly today, and the question is what additional management tools they need to help in building the security infrastructure.

GCJ: You mentioned that there were four or five protocols or methodologies for credential management. Do you see anything rising to the top?

Mulmo: Not really - they all have their strengths and they all have their weaknesses. From an inter-organizational perspective, I think it will be hard to do anything other than PKI for a number of years to come, and today's Grid middlewares are heavy on PKI as well. This causes a technology gap for intra-organizational deployment, such as inside an enterprise, where you already have some other authentication mechanism deployed and want to make use of it. I know of one deployment where they use the MyProxy technology as an online certificate issuer that is connected to their enterprise Active Directory tree. This means that for the users, they still see the same username and password that they are accustomed to, but their Grid, based on open source software, uses PKI. So I think we will see less and less of certificates in the hands of the end users, but when you lift the covers, they will probably be there for quite some time.

There's a lot of talk around SAML, which would be more like getting tokens or tickets from someone and saying that whoever sends this request is authorized to do it because I, as the issuer, say so. That is another complementary thing to look at; because that means that you could now scale down the PKI to one of these certificates per corporation and do all the signing at the corporate boundary. I'm not saying it's particularly good or bad. The point is there's a bunch of ideas that are out there, and we'll probably see a mix of everything. One size doesn't fit all - but which size you as an organization choose should not matter to your external collaborators and customers.

GCJ: Is there collaboration today between the GGF and the Liberty Alliance? Is Liberty driving the SAML standard?

Mulmo: SAML is being specified in OASIS, and Liberty is one of the users of SAML. We don't have any direct collaboration between GGF and Liberty, but we do have a strong liaison with OASIS and some other standardization organizations, such as IETF and DMTF. And now recently, EGA.

GCJ: Dane - you have a lot of experience with TeraGrid. Can you tell us a bit about how some of the security efforts that are being driven in GGF are being implemented in the TeraGrid environment?

Skow: TeraGrid is what I think a number of the commercial Grids and the enterprise Grid environments are going to be like. You see a user community that's used to their own security infrastructures. So tying into their current patterns and allowing for a translation into Grid protocols is one of the approaches that we're taking through the portals and the X.509 and the security translation. We're federating people into groups with identity sources at many of the major institutions and then with identity sources at our partner Grid.

GCJ: TeraGrid uses some pretty advanced networking with direct backplane communication and dedicated lines, correct? Are there any unique things going on over there on the networking side that introduce greater complexity for Grid security with TeraGrid?

Skow: The major thing is we have these high bandwidth pipes that we want to make sure are well-utilized. So we tend to push the applications up towards the high end of the performance curves. But in terms of the security issues and tools that we use, it's very similar.

GCJ: Is the ESnet your CA?

Skow: There are actually six internal CAs to TeraGrid, including ESnet. Most of the large supercomputer centers run one themselves. We're also joining this TAGPMA to try and integrate the set of CAs that we recognize into the global federation there.

And then we're just now investigating the ties into the Shibboleth community and the university infrastructure there. As Olle mentioned, I think we're going to see growth in the interest and ability for people to have identities local to their home base and authenticate locally, and then interact, through a variety of means, globally using the PKI infrastructure. This is a challenge because we have a system now that works fine on tens and maybe even hundreds of CAs, but if we get to the system where every major university in the world identifies its own people and every major business identifies its own people, we're going to have thousands or tens of thousands of identity sources.

GCJ: Is role-based access starting to form with Grid applications or Grid services? In the commercial world you're hearing a lot about Ajax and different people using the P-languages (Perl, Python, PHP) and accessing multiple services, and you hear about composite applications that talk to multiple services. How do you give different users different access to different services with the same applications?

Mulmo: That sort of activity is definitely happening -- though I would label it, at best, ad hoc. In terms of currently deployed software, we're not using anything that is really standardized. Now it's just a question of learning it as much as possible before nailing down on paper what we want and move towards broadly adopted standards to do the same thing.

The model that is most commonly used is where the virtual organization itself will manage these access controls internally. It's self-managed. Basically, being a member of this or that group inside the VO determines access control.

In regards to P-languages, that's definitely in discussion. I haven't seen it in and around GGF yet. It's probably one of the next things that we'll see, especially in the context of work flow, where you want one application to have different access control depending on what state the application is in and where in the work flow it currently is. There is experimental software for that out there, and there are applications that are built up in and around that concept.

The challenge is, in order to implement them, you typically need some central coordinator. And if there's one thing that we try to avoid in Grid computing, it's centralized control or a single point of anything.

GCJ: Tell us about the performance of Firewall Issues Research Group within the GGF. Can you give us an overview of the challenges that they're addressing?

Mulmo: It's one of the very successful groups that have managed to get together people from both industry and research. There has been a really good mix of people that have presented use cases.

They are interested in anything that may come in the way between your application and yourself out there on the network, any middle boxes, as they call it. Anything that can interfere with you communicating or your application communicating to a service somewhere. In particular, with really large data transfers, how do you get speed through a virus-checking firewall? Or, if you open up channels, how do you talk to these firewalls and say you want more or less a direct transfer from here to there in a transparent yet trustworthy manner?

So the firewall interest group is trying to cover a bunch of issues that arise in Grid computing scenarios. The aim is to provide a rigorous set of requirements and then churn them together with IETF down the road.

GCJ: Have there been any notable Grid security breaches that you're aware of, or has Grid security been relatively successful so far?

Skow: There are certainly people participating in the Grid and doing Grid activities that have had compromised machines. The method of attack, to date, has predominantly been the standard methods and not exploiting the Grid technology directly. My feeling is that attack frequency correlates with awareness of the attacker community and the popularity of the technology, and that we're getting some benefit now because Grid is still relatively obscure. Once it gets more and more mainstream, then the attraction will get larger too.

GCJ: What are the key problems you see in the Grid security space?

Skow: I'd say there are two real key problems. One, what's the equivalent of your personal wallet that you can have well-contained, you know what's in it, and you're confident it's under your control. That speaks to this kind of secure core, trusted computing core technology that is being worked on.

Second, how do you establish trust in limited steps moving forward? You have a certain level of engagement when you buy groceries at a grocery store that is different than the identifier you use when you're dealing with the IRS for the taxes. So it's levels of capability that you give away when you give out the trust. Coming up with that framework is, I think, turning out to be one of the key challenges.

close window