Burton Group Identity Blog

When PKI meets the real world

Blogger: Gerry Gebel

This is for all of you out there that still think PKI is the solution to all identity management problems. I relayed this story to a few folks at DIDW this week and they encouraged me to post it to the blog, so here goes.

A couple years ago I was visiting a prospective client in London with one of my colleagues. As is typical, we entered the office building and went up to the desk to check in and get our visitor badges. As I was waiting, I couldn’t help but notice the activity occurring next to me between two other receptionists. It quickly became evident that one of them was having trouble logging on to her PC. At first they were intently examining the screen, reading an error message and the conversation went something like this:

===
Receptionist A: “But I gave it the smart card and entered my password, what does it want now?”

More intense scrutiny of the error message and then Receptionist A shifts her attention to the keyboard…

Receptionist B: “What are you looking for?”

Receptionist A: “Where is the public key?”

===

Perhaps you have your own humorous stories to share - or what your organization did to avoid similar end user dissonance when deploying complex technologies.

Freakonomics of OpenID

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

• Imagine your telephone rings and you answer “hello, who’s this?”

• A voice on the other end says “I own a bridge and I would like to sell you that bridge”;

• You say “Interesting. But who are you?”

• The caller responds “I’m the bridge owner; I’m going to pass you to someone who will verify that I own the bridge.”

• You hear some Muzak and a couple of weird clicking noises; you notice the Caller ID on your phone says “ACME bridge verification.” Then another voice answers the phone and you say “who is this?”

• You hear a voice that says, “I’m the Acme bridge ownership verification service; the guy you just talked to in fact owns that bridge. Thank you for your time.”

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.

There’s a Lott to be said… For Oracle’s recent acquisition of Bridgestream

Blogger: Kevin Kampman

When I became involved with the role management industry about four years ago, it was a tiny and highly specialized market, tainted by difficulties and the potential for failure. This was due in part to its focus on access related information, particularly for role mining. In order to improve role management’s probability of success, it was clear that something needed to change. The solution was to associate business responsibilities with access rights.

About this time, I became familiar with Bridgestream and its founder, Ms. Juanita Lott. Unlike its competition, Bridgstream’s product architecture was very HR-oriented and incorporated business structure and responsibilities into the solution. This was a result of her previous HR background with a software development firm. She had a vision to address the shortcomings in organizational management tools, and turned to role management as a viable solution to address the association of resources and responsibilities. Although her involvement in Bridgestream has diminished, her influence is noteworthy. 

Today, the playing field is much more level. Role management vendors all acknowledge the requirement to address business responsibilities and their alignment with technical privileges. Additionally, role management is integrally aligned with identity management solutions, a perspective that also evolved as the market became more established. In our research, role management projects are much more likely to succeed as a result of their engagement with the business community.

The potential acquisition of Bridgestream by Oracle has been a rumor since early this year. Acquisitions in the identity management space are common, but unknown for role management, until now. The Bridgestream acquisition underscores the growing importance of roles as part of a comprehensive identity management solution; it is certain that we will see additional attention to and expansion of these capabilities. At this point, it is fitting to recognize the pioneers of role management and their respective organizations. They all had a vision for role management and have seen it through to fruition.

What is OpenID for?

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.