Archive for the ‘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.

Moonshot at Kerberos

Thursday, October 28th, 2010 by hartmans

At The MIT Kerberos Consortium‘s 2010 conference, Josh Howlett and Sam Hartman delivered a talk on Moonshot. Slides should be up in a day or so. We reported on status and gave a brief overview.

The new material was apropos for the venue. At the bar BOF back in March at IETF 77, we received several comments on Moonshot’s limitations. It doesn’t work well for services that require rapid authentications for multiple requests. There’s not a good story for use when a Moonshot service needs to contact another service. There isn’t a good standardized mechanism for mapping in domain-specific policy.

We presented a proposal that Luke and Sam developed to optionally provide a Kerberos ticket as part of moonshot authentication. This scales from a service that simply generates its own service tickets all the way through resource domains that have many services and complex policy and provide the client a TGT. Clients can implement the feature in order to achieve better performance. Server can implement the feature in order to get delegation support within a resource domain and to get policy mapping.

Luke has prototyped a version of this service involving a service ticket. We plan on briefly mentioning a desire to have extensible fast reauthentication support at the ABFAB meeting in IETF 79. However in the interest of getting the working group off to a good start we’re going to focus on the well understand parts of the system and formally propose this extension after IETF 79.

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.

DNS Forgery Threatens Kerberos

Tuesday, August 5th, 2008 by hartmans

DNS Forgery attacks have been in the news recently in a big way: a story in the New York Times said that details of a new DNS attack will be released this week. The basic idea is that it is possible to trick a recursive name server into believing that responses provided by an attacker should be believed instead of responses provided by the real authoritative DNS server. The recursive name server passes this poisoned data along to its clients who use the information to translate names to addresses and for other DNS functions. As the Wikipedia article points out, a particularly effective target for DNS Forgery are authority records in DNS responses. I.E., if the attacker can overwrite the DNS records that specify what name servers should be consulted for a particular domain, then the attacker can capture all future DNS queries for that domain. For example, if an attacker mounted a forgery against Comcast’s name
servers targeting yahoo.com, then the attacker could control what computers all Comcast customers connect to for any yahoo.com names. The details to be released this week are expected to show how such an attack can be mounted in a number of seconds with high reliability; patches are available although there is ongoing discussion about how effective the patches are. It is quite clear that the patches do not fix the problem at a fundamental level: they are believed to make it much less likely that such an attack can be mounted or to increase the time that the attack will take.

Obviously, this attack is of concern for the global Internet. However the Kerberos community should pay particular attention. As we all know, RFC 4120 states that insecure mapping services such as DNS without DNSSec MUST NOT be used to map user input into authentication names. However, as discussed in The Role of Kerberos in Modern Information Systems, non-Microsoft Kerberos implementations use DNS to map names entered by the user into names that are used within Kerberos. So, consider an attacker that mounts a forgery and is able to modify all DNS responses for example.com. If this attacker can take over a single system registered with example.com‘s Kerberos (or learn the Kerberos key of such a system), then they can defeat Kerberos security when authenticating to any system in that Kerberos infrastructure provided that the client uses DNS. There are some core
Kerberos
services such as password changing and the KDC itself that never use DNS in this way. Microsoft implementations also do not depend on this use of DNS. However other implementations tend to use DNS even for relatively sensitive operations such as Ssh used for administrative access to a server. In other words, an easy attack that can be mounted against DNS in a number of seconds is a huge problem for Kerberos. Administrators of Kerberos infrastructure need to insure that DNS server patches are applied in their environments. Hopefully these patches will make the attack hard enough to mount that we have some time to put together a better long-term solution.

We’ve known that this use of DNS is problematic for a long time. We even have better solutions: storing aliases of hosts in KDC databases. I’ve never seen a good solution though to figure out how to get from where we are today to a secure configuration. If you don’t provide a transition strategy, then you will find it difficult to convince users to give up the mode that works in favor of the more secure mode. However at last Tuesday’s Kerberos Working Group meeting, Apple’s Love Hörnquist Ã…strand proposed a solution that I think will work. Love proposed that the client learn from the KDC whether a realm supports KDC aliases and has its database properly populated. If the KDC indicates aliases are available, then the client does not use DNS for mapping. The essential bit I had missed before is that this is a realm-by-realm transition. If my client is going to talk to a particular KDC, the question I care about is whether that KDC supports aliases. I had thought you needed some sort of global
transition in the past. Adopting Love’s proposal will take work, especially surrounding APIs such as krb5_sname_to_princ, but doing this work seems critical.

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.

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.