Archive for the ‘MIT Kerberos’ Category

Bad Hair Day for Kerberos

Friday, December 3rd, 2010 by hartmans

Tuesday, MIT Kerberos had a bad hair day—one of those days where you’re looking through your hair and realize that it’s turned to Medusa’s snakes while you weren’t looking. Apparently, since the introduction of RC4, MIT Kerberos has had significant problems handling checksums. Recall that when Kerberos talks about checksums it’s conflating two things: unkeyed checksums like SHA-1 and message authentication codes like HMAC-SHA1 used with an AES key derivation. The protocol doesn’t have a well defined concept of an unkeyed checksum, although it does have the concept of checksums like CRC32 that ignore their keys and can be modified by an attacker. One way of looking at it is that checksums were over-abstracted and generalized. Around the time that 3DES was introduced, there was a belief that we’d have a generalized mechanism for introducing new crypto systems. By the time RFC 3961 actually got written, we’d realized that we could not abstract things quite as far as we’d done for 3DES. The code however was written as part of adding 3DES support.

There are two major classes of problem. The first is that the 3DES (and I believe AES) checksums don’t actually depend on the crypto system: they’re just HMACs. They do end up needing to perform encryption operations as part of key derivation. However the code permitted these checksums to be used with any key, not just the kind of key that was intended. In a nice abstract way, the operations of the crypto system associated with the key were used rather than those of the crypto system loosely associated with the checksum. I guess that’s good: feeding a 128-bit key into 3DES might kind of confuse 3DES which expects a 168-bit key. On the other hand, RC4 has a block size of 1 because it is a stream cipher. For various reasons, that means that regardless of what RC4 key you start with, if you use the 3DES checksum with that key, there are only 256 possible outpus for the HMAC. Sadly, that’s not a lot of work for the attacker. To make matters worse, one of the common interfaces for choosing the right checksum to use was to enumerate through the set of available checksums and pick the first one that would accept the kind of key in question. Unfortunately, 3DES came before RC4 and there are some cases where the wrong checksum would be used.

Another serious set of problems stems from the handling of unkeyed checksums. It’s important to check and make sure that a received checksum is keyed if you are in a context where an attacker could have modified it. Using an md5 outside of encrypted text to integrity protect a message doesn’t make sense. Some of the code was not good about checking this.

What worries me most about this set of issues is how many new vulnerabilities were introduced recently. The set of things you can do with 1.6 based on these errors was significant, but not nearly as impressive as 1.7. A whole new set of attacks were added for the 1.8 release. In my mind, the most serious attack was added for the 1.7 release. A remote attacker can send an integrity-protected GSS-API token using an unkeyed checksum. Since there’s no key the attacker doesn’t need to worry about not knowing it. However the checksum verifies, and the code is happy to go forward.

I think we need to take a close look at how we got here and what went wrong. The fact that multiple future releases made the problem worse made it clear that we produced a set of APIs where doing the worng thing is easier than doing the right thing. It seems like there is something important to fix here about our existing APIs and documentation. It might be possible to add tests or things to look for when adding new crypto systems. However I also think there is an important lesson to take away at a design level. Right now I don’t know what the answers our, but I encourage the community to think closely about this issue.

I’m speaking about MIT Kerberos because I’m familiar with the details there. However it’s my understanding that the entire Kerberos community has been thinking about checksums lately, and MIT is not the only implementation with improvements to make here.

Kerberos 1.8: Anonymous and the Cloud

Thursday, March 11th, 2010 by hartmans

The Kerberos team recently released Kerberos 5 1.8. This is the first of a couple of posts talking about features in the new release and how they significantly enhance what you can do with Kerberos. Before I get to that though, I’d like to wax excited for a moment on the development process. There is much more of a community actively involved in the development process. As with the last release, MIT, Painless Security and PADL Software made contributions along with a number of others.. However the biggest change is the number of parties actively working with each other on designs, design reviews, testing and debugging. There was also a lot more real-time collaboration. It was great to see people from Sun, Debian and Redhat all actively bringing their prospectives to the discussion. My thanks to the Kerberos Consortium for pulling everyone together and for livening up the development process.

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.

Kerberos 1.7

Thursday, June 4th, 2009 by hartmans

MIT Kerberos 1.7 is released. I think this release really takes MIT Kerberos forward both for end sites and for system integrators. There are a lot of code quality improvements and bug fixes. For sites, this release allows changes to flow from one KDC to another on an ongoing basis rather than waiting for periodic refreshes. In addition, the domain-realm referral project allows information mapping hosts to domains to be configured in one place rather than on each client.

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.

Kerberos and Active Directory

Thursday, January 15th, 2009 by hartmans

The Kerberos Consortium, Padl Software, Interisle and Painless Security have been working on adding support for various Active Directory features into MIT Kerberos’s upcoming 1.7 release. I think this project will bring a lot of much needed functionality to MIT Kerberos, and will support the use of Kerberos as a tool in other larger systems.

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.

Paternity leave

Wednesday, March 5th, 2008 by hartmans

Apoligies for the lack of content. I was on paternity leave celebrating the birth of my first child from January 23 until February 25. I’m still catching up from the backlog.

Moving towards open process

Monday, January 14th, 2008 by hartmans

I wrote about initial efforts to set up more open and transparent process for MIT Kerberos. We approved that content at one of our December release meetings, although we ran into snags surrounding choice of software. However we’re up and running now.

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.

Sticking Everyone in a Room

Friday, November 30th, 2007 by hartmans

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.

Opening Kerberos Policies and Development

Friday, November 23rd, 2007 by hartmans

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.

Struggles in Transparency: KFW 3.2.2

Monday, October 22nd, 2007 by hartmans

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.

Opening the Development Process

Monday, October 1st, 2007 by hartmans

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.