Archive for March, 2008

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.

Lost in security

Wednesday, March 5th, 2008 by hartmans

One of the last documents I’m reviewing before my term on the IESG ends is LOST, a protocol for locating the right service center to handle 9-1-1 calls. It illustrates one of the easiest security mistakes to make: insecure binding. Here’s how it works.

You know what domain you are in. You look up using U-NAPTR to convert that domain and the label “lost” into a URI. You expect the URI to be an HTTPS URI and go to the LOST server at that address.

Finding the right server is important. An attacker could cause your 9-1-1 call to be intercepted by the attacker, or could misdirect critical calls. So, how do you know you have the right server? The current spec says you follow the rules in RFC 2818. You take the hostname from the URI and expect it to be in a certificate that you get from the server you talk to. That certificate is signed by someone you trust. So, you have a binding from the hostname to the public key of the server you’re talking to.

There’s one big problem. How do you know you got the right hostname? You just got this URI out of DNS. There’s dnssec, but you’re not actually using that today. Currently in the spec, you have no way to actually secure that the DNS information you got is the one you expect.

The problem is one of binding. For authentication to be secure, you need to establish a binding from some name that you trust to the party you’re talking to. That binding needs to be trusted. With LOST, the name that you have is your domain name. However, today, there is no way to trust the binding of that name to the result from DNS, so you don’t actually have a way to authenticate that you are talking to the right party.

Problems can get even worse in situations where you don’t have a name you trust. Let’s say you have some GUI that allows you to pick the service you want to talk to in a peer-to-peer environment. The services are described by user friendly strings. You pick “Bob’s computer” from the list. How can you trust that name? What stops anyone from going into their computer and renaming it “Bob’s computer?” For systems like the web, we can come close to solving the trustable name problem because entities can prove to companies like Verisign that they are permitted to use the domain name they are using. However in systems where people get to choose their own name and where there aren’t good ways to figure out if the person who chose the name is reasonably allowed to use that name, it becomes difficult or impossible.

All hope of security is not lost in this sort of situation, but there are attacks you cannot protect against. You can do things like make sure it is the same “Bob’s computer” that you’ve talked to in the past. Assuming of course that Bob never needs to reinstall or replace his computer.

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.