Painless Security

This week we started an experiment to try and improve team work and get people involved in each others’ projects. We stuck everyone in a conference room from 11 to 4 on Tuesday. However it wasn’t a meeting, it was a work session. Preliminary results from the first instance were very positive. We were all working on presentations for the upcoming consortium board meeting, and it proved an excellent opportunity to confirm that various presentations were consistent with each other. Another group of people was working on understanding how to effectively use our new project management tool. Still a third group was working on the website. People floated back and forth between these groups. I will be interested to see how this works when people are working on more technical than administrative issues.

I mentioned shortly after the consortium launch that one of the tasks on our plate was to open up MIT Kerberos as a project. We had some promising initial meetings but I needed to put together a proposal with some concrete policies. I’ve taken a stab at that. In particular I’m proposing to create K5Wiki, a place to coordinate activities related to MIT Kerberos Development. We already have a thriving mailing list culture for discussing things. We don’t have a good way to make public documents such as project proposals, project designs, release time lines and roadmaps available. I hope that this wiki can accomplish some of that. Other efforts are under way to make available details of what consortium staff are working on at least for members of the consortium. Together these two efforts will significantly improve transparency.

Currently K5Wiki is a proposal I’m making to the community. We’ll have a discussion on krbdev@mit.edu and see whether the community likes it. If not, I hope someone has good ideas for alternatives.

!

I wrote about the challenge of securing high-performance connections in NFS. One of the technologies that will be important to making that working is channel binding. You perform some application layer authentication and then bind it to a high performance cryptographic channel at a lower layer. The framework document describing how channel binding works has been published.

The document describes channel binding as a concept and gives requirements for how to use lower level cryptographic channels such as IPsec. The document doesn’t define specific details of any given channel but does outline what would need to be done. Work is on going in the BTNS working group of the IETF to specify this for IPsec.

The document goes on to discuss how applications can use these channels. The SASL working group has defined a binding for GSS-API binding that supports channel binding. That has been a good validation of the design.
We will also work on using this in NFS, which should continue to validate the approach.
I’m very excited at the progress we’ve made with this concept.

There’s a new feature in Mac OS X 10.5 called Back to my Mac. It allows you to connect from one mac to another for screen sharing, shared folders or other features . The authentication behind this new feature is Peer to Peer Kerberos. Each Mac runs a local KDC. Each user on the Mac has a Kerberos principal. The Mac generates a realm name starting with LKDC: that contains the hash of a public key created for the machine. A KDC location plugin allows the Mac to find out how to contact the appropriate KDC for one of these peer-to-peer realms. Then, normal Kerberos authentication can take place. The MIT Kerberos team worked with Apple to design this feature. It provided several of UI and security challenges and was an interesting partnership.

This mechanism effectively allows the benefits of Kerberos such as caching of tickets to be used by everyone not just those in an enterprise. Like any other Kerberos authentication, the mechanism can be expanded to support other authentication schemes such as smart cards or authentication tokens in addition to passwords. It makes it easier for programmers because the same security mechanisms can be used both for enterprise security and for peer-to-peer security.

In terms of Kerberos deployment, this is a huge step forward. Apple join the set of companies that are using strong security in consumer-facing products.

The most interesting thing to take away from this is that infrastructure security systems like Kerberos can be easy to use. Users don’t know that they have set up a Kerberos realm or even that they are using Kerberos. I think this will be a good response to claims that good security is too hard to use or deploy. Instead we should focus on writing the necessary user interface to make the security easy to use so that it doesn’t get in the way.

I’ve glossed over an important technical issue. It turns out knowing what realm you need to use in order to contact a particular machine in a secure manner is hard. There are several solutions with different tradeoffs. I don’t know which one Apple ultimately ended up picking. If It is interesting to people I can discuss the design of systems like this and the tradeoffs. Right now, though, I’m focused on the security usability implications of the high level experience. I’d like to think Alexandra Ellwood for research that helped form a basis for this article.

According to this article, Vista SP1 changes the behavior of how Windows authenticates when dealing with a remote Kerberos realm. Based on the fix, I’m guessing that the domain_realm mapping behavior has changed. Can anyone guess what’s happening in this situation and whether we care about the issue?

Last week was an eye-opening experience at least for those of us on the core team. I think we began to really appreciate how much of a shift this is going to be and how many small things were involved.

A lot of our release process is focused around being efficient for a small team. We’re going to need to introduce significant communications in order to make sure people not at MIT understand what is going on and are sufficiently involved in the process. I think the big challenge of this effort will be to find a way to do so without bogging down an already manpower-intensive release process to the point where it does not meet our efficiency goals.

There were a couple of issues that popped up during the KFW 3.2.2 discussion last week. First, a long-standing process has been to give the release engineer flexibility to defer requests to pull specific changes into a point release. The release engineer is responsible for deciding that some change was submitted to the point release too late and will need to wait until the next point release. They make a tradeoff between the value of the fix and the possibility that the fix will break something. There hasn’t previously been a notification of the decision to defer a pull-up request; there has been no need. However we ran into a situation where we needed such a mechanism. We’ve agreed to update our procedures.

MIT has had a long term policy of treating release schedules as confidential. We don’t want to get into a situation where someone is depending on a release coming out by a specific date, we have to slip and they run into trouble. We have worked with specific close partners to learn dependencies on our schedule and where possible we have met those dependencies. We have a good track record of meeting partner dependencies that we’ve committed to. However especially in the case of KFW, this model is inadequate. External contributors need to know when testing needs to happen. Being much more public about release schedules will be important for the consortium and for other external contributors as well. This is proving to be a bit rough to implement. However I think we made good progress on understanding what needs to happen last week; the challenge is to put it into practice for future releases.

MIT Kerberos has largely been developed by a small group of people at any one time. We accept code from outside sources like Sun, Novell and the University of Michigan. However we spend a lot of time making that code fit our standards and design constraints. Few people outside of MIT are involved in setting policy or focusing on the overall architecture of the product beyond the few projects they care about. This needs to change.

At the same time as we were putting together the consortium launch last week, several members of the core team were meeting to discuss how we work with outside contributors. First, it’s clear that we need to get some. We need to interest people outside of MIT in dedicating significant time to working on MIT Kerberos and to caring about the product as a whole rather than just one subsystem or feature. Part of doing this will be offering these people real influence and the ability not to block on MIT to get their work done.

We need to work on opening our processes and establishing clear policies and procedures for decision making. Over the next few weeks I hope to be presenting proposed policies for review. We also need to work on opening up our description of what projects are being worked on and on release processes. MIT and the consortium will control what priorities our staff focus on, but the rest of the community needs to be able to review how we plan to accomplish these tasks and work on tasks of their own.

We came to a few basic decisions at the meetings. First, MIT is not a special customer of MIT Kerberos. We will design a product that is right for all our users. MIT is a customer; we will try to make MIT happy but not at the expense of our other users. We also decided that we need to be careful to make projects available for public review and make sure that projects receive positive support before they are implemented.

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.