Blogger: Gerry Gebel
For an interesting discussion of identity provider business models, privacy, and user centric identity, please check out the transcript of an interview of Bob Blakley did with Dave Witzel of Forum One Communications. He was also interviewed for the inaugural Bandit podcast. Check it out!
Blogger: Mike Neuenschwander
Melissa Lafsky, editor of freakonomics.com, recently posted on the debate, mystery, and hype surrounding OpenID. Refreshingly, she’s not buying in to any side of the debate; she simply wants to know whether OpenID can do anything useful, namely aid in the war on identity theft. Bob Blakely posed the question in a more general sense when he asked proponents of the technology “what is OpenID for?”
As Melissa points out, there’s plenty of debate over the technical merits and business models for OpenID. For those of you that want to dive in to the minutia of it all, I recommend starting with this post from Stefan Brands and this response from David Recordon. And never one to miss an opportunity to market my own musings, I highly recommend checking out my posts here and here.
But technical issues aside, I think it’s more important for people to understand a few concepts about what OpenID actually is, since it’s not immediately obvious. For one thing, although the name is catchy, OpenID isn’t an ID. Also, it’s not necessarily a single sign-on (SSO) protocol. OpenID is a protocol for “proving” control of an Internet address. The idea is that you log into something you control on the Internet; then using OpenID you can provide evidence to others that you have a verified relationship with the thing you logged into. The following example should clarify how this works:
OpenID-Inspired Bridge Buying
So the question is, under what context would you take such a deal? If you knew the caller also owned the ACME bridge owner verification service you would justifiably be suspicious. But if you already had a good relationship with the verification service, it might be a pretty good thing.
Currently, OpenID doesn’t include a mechanism for setting up a suitable context for most purposes (bridge buying or otherwise). Sure, we can invent one. But remember that really smart people have worked on trust problems for years. Things get much trickier once you start adding trust; in fact the protocol starts to look a lot like the also-rans that preceded OpenID.
Blogger: Bob Blakley
There’s been a bit of a dust-up over OpenID recently in the blogosphere. First Eugene and Vlad Tsyrklevitch published a paper at BlackHat 2007 outlining a bunch of weaknesses in OpenID. Then Stefan Brands amplified the critique in a long blog post. David Recordon fired back in a post of his own, in which he expresses confidence that OpenID 2.0 will fix all of OpenID’s problems. I have less confidence than David, but I’ll leave that topic for later. What I’d like to do first is talk about getting the horse before the cart.
What I’d really like to see, as a security guy, is a problem statement and a risk analysis. Specifically, before we start arguing about whether OpenID 2.0 is the answer, I’d like to know the following things about the question:
1. What are the assets to be protected?
What do OpenID’s designers intend it to be used to protect? Blog comment lists? Blog entries? Persistent consumer accounts on commercial servers? Persistent employee accounts on corporate servers?
2. What are the services to be offered?
What services do OpenID’s designers intend it to offer? Authentication of users as the legitimate possessors of OpenID URLs? Linkage of OpenID URLs to user accounts on web-facing systems? Linkage of OpenID URLs to user attribute information (e.g. Information Cards)?
3. What quality of protection is claimed for these services?
Is the OpenID protocol intended to protect against phishing? Is it intended to protect against man-in-the-middle attacks? Is it intended to protect against attempts by one OpenID party to induce another party to execute malicious code? Is it intended to protect against session-splicing or session hijacking? Is it intended to protect against active or passive wiretapping?
4. What is the threat model?
What threats is OpenID designed to protect against? Accidental failures at a participating party? Malicious behavior by users? Malicious behavior by relying parties? Malicious behavior by OpenID providers? Wiretappers? Hackers attempting to penetrate a relying party? Hackers attempting to penetrate a provider? Hackers attempting to penetrate a client system? Cryptanalysts?
5. What is the trust model?
Who trusts whom to do what? Does the user trust the OpenID provider to actually check his password? Does the provider trust the relying party not to send maliciously constructed OpenID URL strings? Does the relying party trust the provider not to reissue OpenID URLs to different parties at different times? Does the relying party trust any particular OpenID provider to issue OpenID URL strings in a particular part of the namespace (e.g. “.gov”?)
All the arguments about OpenID are entertaining, but the claims and counterclaims are very difficult to evaluate in the absence of a coherent problem statement which includes answers to questions like these. The OpenID 2.0 Specification signally fails to address these issues; in this sense it’s a solution looking for a problem.
Blogger: Bob Blakley
At Catalyst North America in San Francisco, I noted in my “New-School Identity Systems” talk that OpenID does not define the relationship between usernames and the names of the OpenID servers which authenticate the owners of those usernames. I went on to predict that this would cause security problems.
A number of participants came up to me after the presentation and assured me that I was wrong, and that the lack of a defined set of trust anchor names and a defined set of rules for which portions of the user namespace each trust anchor was responsible for doesn’t create security issues with OpenID.
They were wrong and I was right; Eugene and Vlad Tsyrklevitch give details of the attacks I predicted in this paper from Black Hat 2007. Their “Step 2” and “Step 4” attacks are precisely the sorts of things I’ve been expecting to see. Thanks to Pamela Dingle for pointing me to the text of the paper, which I’d heard of but not seen until this morning. There’s an accompanying presentation here.
Blogger: Bob Blakley
Paul Madsen, commenting on my recent post regarding the Catalyst user-centric identity interop, argues that the event didn’t demonstrate the existence of a metasystem. Robin Wilton agrees with him, as does Gerald Buechelt, who adds his criterion for what would constitute a metasystem:
“Even though there have been a number of different products and projects that successfully worked together, this technology is a far cry from being an identity meta-system. Multiple-protocol interop on the wire would be a true metasystem, and is a goal that various systems -- Liberty, OpenID, and Windows CardSpace included -- would need to work on together. Concordia is (probably more than) a first step towards this goal.”
Even if it were true that there was only one protocol demonstrated on the wire at the Catalyst interop event (which it is not; for example, a variety of different protocols were used to authenticate Identity Selectors to IDPs), I reject the assertion that you can’t have a metasystem without protocol diversity.
It was not a longing for different bitstreams on the wire which gave rise to the desire for an identity metasystem – it was a real honest-to-God human need: “I want to be able to visit different sites without having to create a new account at every site, and I want to do this in a way which doesn’t involve publishing everything about myself to everybody in the world”.
Meeting this need required the identity community to invent at least one set of protocols which enabled different identity systems (not “protocols”) to work together to allow users to carry their identity information around with them.
The fact that it ties multiple systems together is why it’s called a meta-system. Notice that it’s not called a “meta-protocol”.
At the Catalyst interop event we saw users exporting managed cards from different Identity Provider systems into the same Identity Selector system. We saw users using cards from the same Identity Provider system with different Relying Party systems. We saw users authenticating to different Identity Provider Systems with the same (OpenID) credential. We saw several configurations of these components working together with no Microsoft CardSpace components involved at all.
If the Liberty community and the WS-* community want to keep arguing with one another about whose protocols need to be in the mix before we call that mix a metasystem, I suppose there’s nothing that can stop them from doing that. But the argument doesn’t help actual people or actual businesses get any interesting work done.
The participants in the Catalyst interop did help actual people and actual businesses get interesting work done. That’s why OSIS is organizing more interops in the future; bringing Liberty-compliant components to these events and working with the other participants to make them interoperate with everyone else’s technologies would be much more useful than whining about how many protocols must dance on the head of a pin before we’re allowed to call it a meta-pin.
Incidentally, as both Gerald and Jeff Bohren note, the Catalyst interop was the second such event OSIS has organized. I mentioned the first – held at IIW 2007a – in my initial posting. I participated in the IIW inteorp and did not summarize it here only because Dale Olds has already posted an extensive and excellent writeup of the event.
When I read the first few lines of Sun’s press release announcement support of OpenID, I almost quit reading because it seemed un-newsworthy. And for you PR folks writing press releases, here’s the kind of stuff that triggers my “so what” response: “Through its new initiative, Sun is exploring what changes and practices are needed to make OpenID applicable to a broader spectrum of business and IT challenges.” Alert the media!
But Sun’s use of OpenID as an outward-facing registry of their workforce is an interesting move. Few businesses will trust just any old OpenID provider; rather, businesses will likely accept only OpenIDs (if any) from a provider on a whitelist. By tying a corporate identity to an OpenID, the relying party can improve the assurance of the issuer and make inferences however they may.
OK, still not huge news, but Sun’s initiative has incited the right kind of dialogue among OpenID enthusiasts. Tim Bray blogged on Sun’s forthcoming OpenID provider, which reinvigorated the identity gang mailing list. I’m convinced that the actual solution won’t be nearly as rosy as Tim portrays it. I’m not sure, for example, just how confident you can be that someone holding one of these OpenID’s is really a Sun employee (or just a contractor or former executive). But in my view, Sun’s pushing OpenID in the right direction.
In fact, I’d like to see these ideas taken much further. The Diffie-Hellman qualities of OpenID can be put to much better use than the SSO use cases so often cited. It’s as if the OpenID community serendipitously stumbled onto something that is of great value and has yet to realize it. I alluded to this in a previous post. Although the name “OpenID” is catchy, it’d be better if we didn’t think of OpenID’s as IDs; and it’d be better not to think of the URIs associated with OpenIDs as usernames. And it would be great if people could have a dozen or so of these things at their disposal.
I recently published a report at Burton Group called, “In Search of the Internet Identity System: Contrasting the Federation Approaches of SAML, WS-Trust, and OpenID,” in which I proposed an alternative use of OpenID. Here’s an excerpt:
OpenID Is for Showoffs
Although its proponents tout SSO as the most important feature of OpenID, the standard can be put to better use. The proofs in OpenID allow for a certain kind of interaction that is of great value on the Internet. Roughly, OpenID enables a person to demonstrate control over a given web property to a stranger (who understands OpenID). It’s a web version of showing someone you own a car by hitting the “unlock” button on your key fob. Although this might seem a high-tech form of showing off, it can also be used in reputation systems. For example, a user may demonstrate control over a dozen popular websites to gain access to an exclusive site. The user may also demonstrate ownership of a particular reputation (on eBay, for example).
OpenID not only demonstrates a relationship, but to a degree, projects the status of a relationship, because the demonstration is dynamic (not based on historical certification). Once a user can demonstrate control over a resource (such as reputation), the user can then offer it as collateral in forming a new relationship. Accordingly, in the hands of astute architects, OpenID may be used to reduce risk in relationships. (For more information, see the post “Law of Relational Risk” on the Burton Group Identity and Privacy Strategies blog.)
In short, OpenID may be a convenient, scalable way to project high quality signals to perfect strangers. (For background on the topic of signaling, have a look at the work of Judith Donath). Using OpenID in this way may also satisfy the need for multi-factor identity that I pointed out in my post on the law of relational risk:
… single sign-on (SSO) efforts are often misguided. In the interest of promoting relational continuity, the more authenticated connections the better—particularly if the user can parlay these authentications into improved reputation. Recognition of participants based on multiple channels of connectivity would be the method for improving identity assurance rather than on a single login event.
To me, these are important elements for creating functional online relations and societies. At Catalyst, we’ll be proposing other pieces of a technical architecture to support relational and social processes important to social trust. So if you have any thoughts on the subject, please drop a comment on this post!
[posted by Mike Neuenschwander]
