Archive for the ‘Standards’ Category

At IETF 88, we held a plenary discussion of how we could harden the Internet against ongoing monitoring and survalence. There were no significant surprises in what people said about monitoring. So, we had an opportunity to focus on what the IETF as a standards organization responsible for technical standards that drive the Internet can do about this problem. I think we made amazing progress.

The IETF works by consensus. We discuss issues, and see if there’s some position that can gain a rough consensus of the participants in the discussion. After a couple of hours of discussion, Russ Housley asked several consensus questions. The sense of the room is that we should treat these incidents of monitoring as an attack and include them in the threats we try and counter with security features in our protocols. The room believes that encryption, even without authentication has value in fighting these attacks. There was support for the idea of end-to-end encryption is valuable even when there are middle boxes. IETF decisions made in meetings are confirmed on public mailing lists, so the sense of the room is not final. Also, note that I did not capture the exact wording of the questions that were posed.

This is huge. There is very strong organizational agreement that we’re going to take work in this space as seriously. Now that we’ve decided pervasive monitoring is an attack, anyone can ask how a proposed protocol (or change to a protocol) counters that attack. If it doesn’t handle the attack and there is a way to address the attack, then we will be in a stronger position arguing the threat could be addressed. In addition, the commitment to encryption providing value without authentication will be useful in providing privacy and minimizing fingerprinting by passive attackers.

The IETF is only one part of the solution. We can work on the standards that describe how systems interact. However, implementations, policy makers, operators and users will also play a role in securing the Internet against pervasive attacks.

The ABFAB working group, which will be standardizing technologies that Moonshot depends on, had its first meeting at IETF 79 in Beijing, China. The meeting was quite productive. Because the meeting was the first of the working group, there were some introductory presentations. A group of authors are putting together a proposed architecture document; we presented the current state of our work. However things have evolved significantly since the working group meeting and I think it will make more sense to wait a couple of weeks to discuss the architecture document.

Most of the time was spent on two presentations. The first was the status of the GSS mechanism. We discussed issues that were discovered while implementing the EAP GSS-API mechanism. Discussion in the room tended to support the proposals made in the slides. A few issues will need to come to the list. We had the most interesting discussion of SAML AAA integration.

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.

Meanwhile, at last month’s Moonshot meeting in Copenhagen, an initial version of the technology was demonstrated. We’re still working through some of the administrative details needed before we can release the code for public review. There have been several exciting discussions both on the Moonshot implementation list and on the ABFAB list over the past few weeks.

Please see here for a briefing paper including snapshots of all our specs as well as an updated use case paper. This paper was presented at the end of April at the Internet2 Spring Members meeting. This is a great snapshot of Project Moonshot at the end of last month.

There are two other approaches that are likely to come up tonight; see this message for details. These mechanisms require significantly lower infrastructure than Moonshot, but do not provide all the benefits. One question is whether there is a continuum of use-cases depending on what level of investment in client changes are made.

At IETF 77, we’re having a get together to discuss federated authentication beyond the web. The meeting will be in the Mahattan room starting at 9 PM US Pacific time. I think audio streaming will be available; I will post a link closer to the meeting time.

In the last entry, I mentioned that a preliminary spec would be available; see the preliminary EAP GSS-API mechanism. A use case paper and slide set are being reviewed internally and should be ready early next week. We may even have preliminary versions of the binding between RADIUS and SAML available before IETF.

There have been a number of great discussions on the moonshot-community list and with others interested in the broader area.

Recently, I’ve been working on an exciting project with JaNet(UK) on a project to bring federated authentication to non-web applications. I’ve worked on authentication projects a lot, although this is the first federation project I’ve worked on. The big difference appears to be an emphasis on credential independence: the subject (person trying to authenticate) and service will not share a common credential type. Within their organization, the subject and their identity provider share a credential. Then, the federation has some credential mechanism such that the user’s organization and the service share some (probably completely different) type of credential. The other emphasis is on providing personalization.

For web applications, there are a lot of options to achieve this: Information Card, Open ID, SAML, and OAuth all provide solutions in this space. However there are not good options for non-web applications. If you out-source your mail and chat infrastructure but want to use your own chat client or IMAP client, then you will not get the same federation benefits you can get with the web. If you’re using usernames and passwords and don’t mind the potential problems with your out-sourcing provider being able to impersonate all your users, you can simply synchronize usernames and passwords. Within an enterprise, you can do better using Kerberos. JaNet(UK) runs the UK Access Federation, which is a SAML-based web single-sign-on federation. In order to better meet the needs of their customers they’d like to expand this offering to non-web applications. This demand is apparently shared across the European academic community. I suspect there is also some demand in the US academic community and in enterprise situations.

With the web, it turns out that you have a convenient platform for interactions with the identity provider: you can simply direct a web browser to the identity provider and need not specify the user interaction with the web browser at all. This is seen as a significant branding and usability advantage. With other environments, it becomes necessary to specify the interaction with the identity provider. Consider an automated client that wishes to examine a mail box and provide advanced mail sorting or aggregation. That automated client cannot directly use a web browser. OAuth solves this issue with an enrollment step that does typically involve a web browser that produces a consumer key and an authentication step that does not. However for non-web clients it seems like avoiding reliance on the browser authentication will be important. It turns out we already have widely used technologies that do this: the Extensible Authentication Protocol (EAP) mediates the interaction between a subject and identity provider for obtaining network access. It also turns out that we have fairly good technologies for abstract security services within non-web applications: thanks to Kerberos and Active Director, many application protocols and a fair number of applications support GSS-API. JaNet(UK) proposes to combine these technologies with SAML in order to produce a solution for federation beyond the web.

I prepared a feasibility analysis of this proposal. At a technical level, the proposal is sound. There’s a lot of standardization and implementation work, but there appears to be sufficient motivation to form the seeds of a standards activity and put together a proof-of-concept implementation. However, the big question is “Will anyone use it?” In particular, to be useful beyond fairly small communities, support from client vendors and application framework vendors will be needed. It’s taken massive money and around 20 years to get Kerberos support to a point where it is effective within an enterprise. Moonshot can leverage that work to a large extent, but moonshot may also have greater usability and penetration goals.

It’s interesting that I’m advocating EAP for application layer authentication. When I was a Security AD, I made a strong statement that EAP must only be used for network access. I’ve been fairly consistent about that since then. I think there are two huge problems with using EAP for application authentication. The first is that EAP only authenticates the home realm; it does not authenticate what service you’re going to. So you might try to connect to your e-mail and end up giving something access to your stored files and pictures instead. That is, EAP has a phishing exposure in the federated context. If the only thing you can get by using EAP is network access, that exposure is only moderate. However in a fully federated environment that is a huge exposure. Moonshot will address this problem by using EAP channel binding and by doing the necessary work to make that a viable solution. The second concern is that interoperability is reduced when you have multiple authentication approaches for the same problem. If EAP is going to be used for application authentication, we need to understand how it relates to the rest of the application authentication metasystem. Moonshot proposes such a relationship, addressing my objection.

Moonshot is designed to work well with the objectives of the Identity Metasystem and its laws of identity. It uses a different technology, but does have an approach for dealing with claims-based identity and hopefully will have a user experience very similar to the identity metasystem. It uses a different underlying technology. However one of the main beliefs behind the identity metasystem is that is the user experience and universal interoperability that is important, not any specific technology. In its domain, the technologies Moonshot selects will be a better fit than a web services stack.

It’s strange not to be working on Kerberos; Moonshot uses some Kerberos technology, but its core is definitely not today’s Kerberos. In some ways it is fun to be working on something new. There’s one aspect of Kerberos I really miss: Moonshot has nothing like tickets. There’s no place to remember state or exchange to directly involve the client in what the server learns. My analysis talks about ways to make Moonshot more like Kerberos; there are some potential advantages, but so far, the tradeoffs do not justify changes.

We’re hoping to have a bar BOF at IETF 77 and a BOF in the summer at IETF 78.

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.