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.

Comments

[Eric Norman]

Methinks there's a more genreal slew of questions about RPs trusting OpenID providers.

Given that a user is allowed to have an OP of his own choosing, which includes one he operates himself, how much does an RP "trust" information that it receives from that OP? Cf. malicious user under threat models.

[Chris]

Bob, great questions/suppositions... Please excuse some responses:

1) is the answer SSO or more? It would seem that the 1.1 spec is intended for exactly that, and the 2.0 spec is out there still because (IMHO) the answer to your question has not been decided upon (please correct me if I'm wrong). 2) I'd say that's a 'yes', 3) if the answer to 1) is right, I'd say no. if not, great question. 4) Humm, that's a lot of different trust scenarios, but the first one is the question - what trust model does the community really believe OpenID will solve. 5) Seems that the only thing is that someone has been able to authenticate against a valid OpenID enabled URL.

I don't think the 2.0 spec is a solution looking for a problem - the 2.0 spec solves a great many issues. To me the question is - whether or not the community wants to support the added complexity of the 2.0 spec to solve the problems it solves. the 1.1 spec is perfect for SSO scenario, with little or no trust model, IMHO.

[Crosbie Fitch]

Identity is an abstract concept.

It is required for continuity of authorisation, and accrual of reputation.

To be in possession of an identity means to be able to demonstrate possession, e.g. to have a key that enables such demonstration.

It is supposed that it is easy to privately manufacture a new identity and an associated key such that only the keyholder (and those they subsequently authorise by providing copies of the keys to) can demonstrate possession.

Continuity?
E.g. whoever demonstrates possession of identity X today is just as authorised to represent X as whoever demonstrated possession of identity X last week or last year.

On a web site, it is assumed that users of a web browser session are able to control access to the browser during that session (and any operation authentic to the session), and that if the session can convey demonstration of possession of an identity, that all operations performed by the session are consequently operations performed by the identity - and able to be treated and recorded as such.

Understandably, one should be able to demonstrate possession of an identity without revealing a key.

Note that an identity needn't correspond to a single person, nor any person at all.

It is possible that rather than require identities to be portable, users create ad hoc identities with alleged authorisation, and then later when they have privileged access to their other identity (or identities) can adopt the ad hoc ones they created.

Questions answered for a hypothetical identity system:

1. What are the assets to be protected?

Exclusive possession of an identity, against theft or imitation by unauthorised agents.

2. What are the services to be offered?

Exclusive ability to demonstrate authorised possession of one or more identities.

3. What quality of protection is claimed for these services

Protection of identity and its accrued reputation if any.

4. What is the threat model?

Impostors wishing to assume an identity, e.g. to directly exploit its reputation or to indirectly benefit from harming its reputation.

5. What is the trust model?

Each prospective identity possessor trusts public source code of software (and hardware) of privately possessed computer to create an autonomous agent representing an identity.

All such possessors trust that the software is able to achieve its objectives (by inspection and its evident resilience to continuous attack).

There are no central authorities or other agencies with elevated levels of trust upon which this system relies. This doesn't preclude highly trusted agencies demonstrating possession of identities that consequently become highly trusted identities.

[Bob Blakley]

Crosbie, I take the first part of your answer to be a long way of saying that one goal of OpenID is to protect against theft of the keys with which users demonstrate their control over OpenID URLs. This is consistent with your answer to

"1. What are the assets to be protected?"

... which is:

"Exclusive possession of an identity, against theft or imitation by unauthorised agents."

"Possession" isn't an asset. An identity might be an asset, but since it's "an abstract concept" it's not clear how one would assign it worth or how one would protect it. "An identifier" would at least be concrete, and it would be possible to tell whether or not it had been protected. I will observe here that if the only asset to be protected is an identifier (or even an "identity", whatever that might mean), this means that the end user is the only one for whom OpenID offers any protection - Identity Providers and Relying Parties have no assets at stake. Do you in fact believe this?

"2. What are the services to be offered?
Exclusive ability to demonstrate authorised possession of one or more identities."

This is a service offered to users. By whom is it offered? The Identity Provider? Are there other services offered to the user? Are there no services offered to Relying Parties or Identity Providers?

"3. What quality of protection is claimed for these services?
Protection of identity and its accrued reputation if any."

This isn't an answer. How strong is this protection? Can it be broken by an administrator of the IDP? By a hacker with knowledge of the IDP's code? By a national intelligence agency with sophisticated cryptanalytic capability? If the protection is broken, are any indemnities offered to the user as compensation? What happens if the IDP goes out of business? And so on....

"4. What is the threat model?
Impostors wishing to assume an identity, e.g. to directly exploit its reputation or to indirectly benefit from harming its reputation."

Who are these impostors? Script kiddies? Agents of national intelligence services? Professional programmers? Administrators in the employ of the Relying Party or Identity Provider? Programmers in the employ of the vendor providing the user's desktop operating system?

"5. What is the trust model?
Each prospective identity possessor trusts public source code of software (and hardware) of privately possessed computer to create an autonomous agent representing an identity. All such possessors trust that the software is able to achieve its objectives (by inspection and its evident resilience to continuous attack)."

People don't "trust" code. They might trust the developer of code to have built in some set of protections. But there are many other things they have to rely on - for example: does the operator of the relying party website (a human) trust the user (another human) not to attempt to use the OpenID URL string to execute a buffer overflow or other attack by sending a maliciously constructed string instead of a "safe" URL? If so, why? Does the operator of the OpenID Provider (a human) trust the operator of the relying party (another human) not to send maliciously constructed URLs? Do either the operator of the RP or the operator of the IDP (humans) trust the user (another human) not to share passwords? And so on....

"There are no central authorities or other agencies with elevated levels of trust upon which this system relies. This doesn't preclude highly trusted agencies demonstrating possession of identities that consequently become highly trusted identities."

If this is true, on what basis does the relying party accept the OpenID provider's assurance that the user controls a URL? Try this thought experiment. Imagine that I build an OpenID provider which doesn't ever check passwords. It goes through all the OpenID protocol steps, but whenever it gets a password from a user it simply accepts that password as valid and assures the relying party that the user authenticated successfully. Is this acceptable behavior? If not, then the relying party is trusting the identity provider not to do this.

[Crosbie Fitch]

Bob,

"before we start arguing about whether OpenID 2.0 is the answer"

I have not been arguing about whether OpenID 2.0 is the answer.

I have tried to provide answers about a hypothetical solution.

I'll address the points you raise later.

[Crosbie Fitch]

The first part of my answer was an attempt to give an idea of my perspective and approach to identity systems.

I have a hypothetical 'open identity system' in mind (I consider would be superior to OpenID). I'm interested to know whether if I apply your questions to it, whether my answers about it would appear satisfactory to you.

1.1 On the protection of assets

As to what constitutes an asset, it's not particularly relevant in this context. Identity is an asset perhaps in the same way that a company's good will is an asset.

You ask "What are the assets to be protected"? This assumes there are assets to be protected. If identity is an asset, then it is the asset that is to be protected. Even if it isn't an asset it is still to be protected.

Let's not get too hung up on 'possession' either. We possess identities as we possess names, reflections, reputations, bodies and shadows. Many people use the term 'possession' to refer to those material things that can be possessed, but that doesn't define possession.

'Possessing an identity' shouldn't infer that there is some discrete object that wholly encapsulates an 'identity'. There may well be discrete objects that serve as keys to identities or partial repositories of constituent data.

As to who is protected. I don't think there is anything to be protected by an identity system apart from the identity. The users of identities must look to other systems for protection beyond that of the identity.

Users and 'relying parties' may well have many assets at stake (beyond identities), but their protection should not be in the remit of an identity system. Even the security of the communications channel between them is outside its remit. If a system provides the user with a key and a safe, then the system secures the safe against considerable brute force attack, and lock picking. It may be useful to enable the user to authenticate the key and safe (so they don't insert the key in a fake safe, and can't be conned into accepting a fake key in place of the genuine one). An identity system would probably take some steps to persuade the user to adopt measures to secure local communication with a local identity system agent, and possibly even provide such measures. However, for user-to-user communication it is not up to the identity system to secure it, nor even to authenticate each user to the other. It can only indicate whether any communication with a particular identity is occurring, e.g. "Someone at the other end of the teletype is able to hold a discussion sufficient to demonstrate possession of identity X. This system cannot guarantee that the telecommunication is free of eavesdropping, nor that the possessor of the identity is free of duress, nor that your communication with them will not be unnoticeably interrupted or modified by an impostor, nor that the possessor of the identity did not obtain it by deception".

2.1 On the offering of services - by whom?

This is a public service, collaboratively produced, and collectively provided. There are no distinguished 'identity providers'. Each participant is involved in the provision of the identity system. Each participant possesses one or more identities (though the data representing such identities is likely to be distributed over the participants with whose identities each such identity has encountered).

3.1 On the strength of protection

The public is the IDP. The public is the threat. The source code is open, public, and free.

If such a system lasts longer than a snowball in hell then the protection is strong enough.

4.1 Who threatens?

Everyone must be considered a potential threat, however, it is assumed that the majority of users wish to preserve the security of the system.

5.1 Trusting code.

Our computers are our agents that we entrust to facilitate dealings between ourselves and others via the Internet.

You may feel that a priori only sentient beings can be trusted, however I'm extending trust to include human artifacts such as autonomous software agents installed on personal computers.

Just as we may trust a branch to support our weight, so we may trust a software component of an identity system to be functionally secure. This requires trust in all aspects: the integrity of the source code, the compiler, the operating system, the hardware, and physical access to the machine. A human user needs to be able to assure themselves of the security of all of these aspects.

Users can trust collaboratively developed software whose source is publicly visible to all interested and relying parties. This similarly applies to compilers, operating systems and PCs.

Users can trust that those most interested in securing their identity (those identities their identities have relations with) are those who collectively maintain it.

A system that requires trust be delegated to one or more remote parties, even supposedly distinguished, seems to be a prima facie demonstration that it is an untrustworthy system.

[savas]

So far in this series of posts about passwords, I’ve returned to the idea that as a technology, passwords have a both material and methodological aspects. That is, how you use the technology is as important as how advanced its parts are. So far, this discussion of improving passwords has largely focussed on the material side, namely OAuth and OpenID, and password interfaces. These improvements happen at the will and ability of the people making web and desktop applications. As such, users will always be waiting for them to happen if they haven’t already. This post takes things to the methodological side, which is more the user’s domain, by describing the rules I use to make strong yet memorable passwords that are unique for each account.