Archive for the ‘Consortium’ Category

Integrating Kerberos into your Application Released

Sunday, August 3rd, 2008 by hartmans

Painless Security has been working with The Interisle Consulting Group and the MIT Kerberos Consortium on the consortium’s paper on how to integrate Kerberos into applications. The paper is now available to the public. The paper gives an overview of GSS-API, SASL and the raw Kerberos messages. It talks about what you hope to get out of integrating Kerberos into an application. Then it discusses several issues to consider when planning your Kerberos integration, including naming, intermediaries and other complicated issues. Finally, the paper points to several examples of application integration.

I think the paper will be useful; I know it covers a lot of issues I have run into over the years. WhenI first heard about the plan for this paper, I expected that it would involve a walk-through of how to integrate Kerberos into some simple application. Other people expected this too: the most consistent comment we’ve received is that there is no tutorial. The paper does point to tutorials for GSS-API in C and Java, but does not include a tutorial ofits own. The reason for this is that it seemed there are already tutorials out there. However there didn’t seem to be an overview to help people choose between SASL and GSS-API, to understand the hard issues and to give best practice advice in avoiding common pitfalls.

I’m very interested in feedback on the paper. I’d especially love to get feedback from those new to the Kerberos community; the comments we’ve received to date are all from people who have been at this for years.

Board Meeting and Roadmap

Friday, April 11th, 2008 by hartmans

Monday, the consortium board met at Google. As I discussed, I presented a plan for the consortium road map. The road map presentation went reasonably well. The board generally seemed to support the road map and they gave useful feedback on ways to improve it. The specifics will be in the board notes, which will come out shortly on the consortium site. However I’d like to point to a few specific changes that need to happen to the road map as a result of the meeting.

It’s power, stupid! The section on mobile devices discusses the mobile environment in terms of CPU, memory and networking. That’s missing the most critical factor to consider when looking at mobile platforms: power consumption. “Oops,” is all I can say. I certainly was aware of the importance of power and of how both network and CPU utilization are an important fact or in power utilization. I just completely failed to talk about it when discussing the road map. That clearly needs to be fixed.

There was an enlightening discussion about the difference between web services interactions and Kerberos interactions. Slava Kavsan pointed out that Kerberos is missing three things that are important in B2B web services environments. There is no policy exchange where the relying party can explain what information it will need from the security infrastructure. The client does not have an opportunity to provide its preferences to the KDC in order to describe what information it wants disclosed. The KDC does not provide different relying parties with different information. Also, there is no standardized format for describing any useful claims about a subject in Kerberos. I touch on some of these issues at IETF 64 in 2005. I think that an interesting question for the consortium will be how to deal with these issues. Is it better to extend Kerberos, or to combine Kerberos with something else? I think that it is important that
if Kerberos is combined it is done in such a way that it works for all GSS applications and for web services. So, extending Kerberos is probably harder. You have to decide when to go get a new ticket and have APIs both in GSS-API and Kerberos for doing that. However some of the application integration may be easier. Combining Kerberos with something else, where Kerberos handles the authentication and some other provider handles assertions about identity may be easier from an API standpoint for web services applications. It seems like you’re going to lose a lot of the flexibility of Kerberos though if you do that. Will you lose the caching of credentials? Will you be able to take advantage of new Kerberos extensions in such a system? I think looking at these issues will be a critical upcoming challenge for the consortium.

Grand Vision, Grand Future

Wednesday, March 26th, 2008 by hartmans

So far, consortium priority setting has focused on short and medium term goals. The consortium proposal itself talks about long term visions of Kerberos and about where we want to move things. We’ve kept that in mind as we look at the short and medium-term work we’ve been planning; it is all consistent with the future vision. However, no single sponsor wants to prioritize the long-term visions. Ultimately though it’s our job as the consortium to drive that effort and get to the long-term vision we want to see.

I’ll be taking the first step in that process at our next board meeting. I will be presenting a road map plan four our long-term technical direction. We will propose a series of projects to advance kerberos on the web; to advance kerberos on mobile platforms; and to improve the maintainability, sustainability and security of Kerberos. The goal will be to make steady progress on each of these fronts. I’m currently in the middle of coming up with an initial proposal for these priorities.

First Consortium Board Meeting

Sunday, December 16th, 2007 by hartmans

Last Tuesday, December 11, the MIT Kerberos Consortium had its first board meeting. Paul Armstrong gave detailed notes of the meeting. In a few cases, particularly dealing with parties not present at the meeting, Paul dropped some qualifiers and claimed that things were definitely true when I only stated that I suspected they were true. Such is life with raw notes.

The board did succeed in its goal of providing us priorities for our work. I think the board will work well together and will work well with the rest of the consortium staff.

I was expecting our priorities to focus mostly on technical projects. However the board surprised me; much of the work is on documentation, process and on promoting Kerberos. I actually think this is going to be good for the community and the technology but it was not quite what I expected going into the meeting. The board definitely seems to understand the value of standardization activity and working together with multiple vendors.

Some projects we’ll start now; some projects we will explore and report back to the board on in March.

MIT Launches Kerberos Consortium

Thursday, September 27th, 2007 by hartmans

Today, MIT announced the launch of the MIT Kerberos Consortium. The consortium will gather a group of interested sponsors around Kerberos and related technology. Kerberos has grown too large for one small team of MIT. In order for the pace of progress to increase, we need support from developers, users and support providers.

At the event, I discussed the technical direction for Kerberos. Within enterprise environment, Kerberos has achieved the goal of being painless. Many people use Kerberos on traditional computers without knowing they are doing so and without it getting in the way of them doing their work. Our challenge is to take this level of success and extend it to other devices, environments and solution provider communities.

Outside of the enterprise environment, Kerberos has had success in some specific product areas. Cable Labs has specified its use for VOIP applications in their networks. Microsoft has used Kerberos to back Xbox Live. However optimizing Kerberos for these non-enterprise environments has taken a lot of work. We need to learn from this effort and expand the protocol and implementation to make it easier. One environment where we have particular trouble is the web–both within an organization and especially over the open internet.

Kerberos works well on computers with traditional processing power, input devices and reasonably good network connectivity. We’ve had reports in the IETF that Kerberos requires a lot of processing power for sensor networks. Kerberos,especially in a cross-realm environment, is chatty as a network protocol. Try it some time over GPRS with moderate packet loss and a number of KDCs. At least MIT Kerberos does not perform very quickly in this environment. We need to think a lot about how user interface should work for mobile devices and other environments without standard desktop input/output. What do you want to do about passwords? How do you want to interact with the user to select identity?

Finally we have a lot of work to do in order to help developers of products understand Kerberos. There is not a lot written about using Kerberos in your product or protocol. The API documentation is in need of improvement. Best practices are not documented as well as they should be.

The consortium will work with its members to set priorities and allocate funding. Work will include improvements to MIT Kerberos, standards development and development of documentation. MIT Kerberos will remain an open-source project open to contribution both from consortium members and anyone else with time and skill. The consortium members will set priorities for how the consortium funds are used. Other contributors can of course choose what they want to work on in the context of the open-source project. The project will retain technical independence; consortium members can set priorities for funding but cannot force particular technical decisions.