Kerberos 1.8 testing releases are already available in Debian Squeeze and Ubuntu Lucid. I will be updating Debian to the final release soon, but everything discussed here should already work in both Debian and Ubuntu. I don’t know about the state of other distributions, although given how heavily Redhat was involved in the process, I’m sure they have 1.8 internally.

One of the frustrating problems with previous versions of Kerberos was the need to key hosts before they could run Kerberized services. An administrator needed to set up a keytab and securely get it on the machine. That creates problems for automated installs of services, virtual services in the cloud, and environments where people installing servers are not the same as those running the Kerberos realm. Kerberos 1.8 still requires servers be keyed, but the need for the administrator is removed. Anonymous Kerberos provides a way for a machine to authenticate to Kerberos without an existing account. That page shows how the Kerberos administration server can be configured to permit machines to create their own keytabs. Anonymous Kerberos does require pkinit be configured and that the client know the public key of the KDC. However it is easy to build the KDC public key into an auto installer image or place it onto a USB key.

I think it would be really neat to build a Debian image for Amazon EC2 that would show how easy it is to boot a virtual machine, have it register itself with a Kerberos realm, use something like remctl to request a work load and then begin serving that work load. The work load could include both clients for distributed computation or even services provided to the world, all secured by Kerberos with automatic bootstrapping. I don’t know if I’ll have time to put this together, but if someone were interested in helping or paying for the work it would be much more likely to happen.

I believe the links above are enough that you should be able to get Anonymous Kerberos working and minimally configured. If not, feel free to send questions; I’ll focus more on updating the public instructions than on providing individual help, but I’m definitely interested in making this easy to use.

I already wrote about Active Directory enhancements. Painless Security was also involved in a project to secure Kerberos against offline dictionary attacks. I’m very happy that this project made the 1.7 release. To be truly useful, it will require integration from OS vendors into PAM modules and the like. I’ll discuss my plans for doing that in Debian in a future post.

Despite a lot of new features, initial signs are that 1.7 is going to be a relatively stable release. It has been in Debian unstable for over a month and at this point is working quite well.

The project has brought together a lot of players: it wouldn’t have been possible without the efforts of Microsoft, Samba, Novell and several others I’m probably forgetting. It’s great to see such an interest in interoperability that all these parties can work together.

For me, it has been a different approach. I’m used to doing a fair bit of design work up front, understanding what is being delivered, and then working on the code. For a variety of reasons we took a different approach here. Every morning I’d wake up to a new chunk of code to review, evaluate and present to the Kerberos development community. I’d describe the design of the code in order to seek comments and if changes were justified, we’d work to make them. For much of the project, code was coming in faster than I could evaluate it. This meant it was a high-stress and exhilarating project. In other words, it was great fun!

There’s one thing that worries me about this focus on Active Directory. Sure, everyone needs to work with Microsoft. First, it is a market reality. Secondly, Microsoft has brought some great innovative thinking to the realm of network security and we should all take advantage of it. However, it seems that most of the players are only focused on supporting Microsoft features and are ceding the entire space to Microsoft. No one else is working on open standards for expressing authorization. The entire PAC structure, how entities are named, how they belong to groups and how this all interacts in a directory is defined by Microsoft. As a result, Microsoft is in a position to add new technology. However with the current approaches, no one else has this ability. That means, Microsoft will always be one step ahead.

I think it is important that that we all look at how we can embrace and extend Microsoft technology, while maintaining the ability to work together and to work with Microsoft. Doing this is going to require a lot of work but is essential for the continued innovation of network security.

The next challenge is to get people other than me to start contributing content. I have gotten people with active project proposals to start writing them up on the wiki. However I am currently the only one writing content such as policy proposals, descriptions of the organization, etc. Bootstrapping something like this is hard; the resource needs to be useful enough that people remember it, but for that to happen, it needs to be something people remember to add content to.

Once we get people to start looking at the resource and contributing, we have a lot of important community discussions planned. We want to open up a bunch of questions about coding practices. We also want to provide guidelines for how to conduct code reviews and have information on interface stability.

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.

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.

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.