Wrong-headed impersonation

James Kobielus's blog also includes a report on his interview with Eve Mahler.  I think there are two issues raised that deserve discussion.  The first concerns what Eve calls the “human absent” scenario:

“She focused on the centricity of the user in the data flow during a login attempt, distinguishing between the “human present” interaction mode (i.e., the actual human user/subject is online during the transaction, responding to prompts, selecting i-cards, deciding whether or not to disclose this or that personal attribute to this or that relying party), vs. the “human absent” interaction (i.e., the human user/subject is not actually online during the transaction on which they are a principal, but, instead, an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on their behalf).

“She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the “human present” mode, which, as Eve stated memorably, means that the “user's policy is in their brain.” By contrast, she pointed out, Liberty's ID-WSF was developed to support both the “human present” and “human absent” modes.

The essence here is her notion that “an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on [the user's] behalf”.

On behalf of…

I'm going to make a categorical statement.  No one and no service should ever act in a peron's identity or employ their credentials when they're not present.  Ever.

It's not that there aren't use cases for which this might seem to be desireable.  For example, let's look at the problem of linkback spam, in which fake sites fill bloggers’ comment queues with garbage.  Suppose, one day, we come up with authenticated linkbacks.  Wouldn't you want the linkback service to be able to log in with your identity?

Another example – given to me by someone who thought it was really definitive - was that of the OnStar notification system.  Suppose you're driving, are involved in an accident, and lose consciousness.  You want your OnStar system to call on your behalf so help will be dispatched.  Clearly you can't participate.  Similarly, hospital scenarios provide all kind of grist for the ”human absent” mill.  But should OnStar or a hospital system actually be acting “as you”?

Last-century systems supported exactly this kind of behavior.  We called it “impersonation”.  And anyone who has done practical security work will tell you how many problems this caused, and how wrong-headed it is.  If you give some service the ability to simply appear to be you, you are open to all kinds of attacks – and we've seen them all around us.

Put another way, I don't want OnStar to be be able to act on my behalf with respect to very many things.  I don't want it to be able to remove money from my bank account.  I don't want it buying gifts, or controlling my insurance, or doing anything else other than calling for help.

So what I really want is for OnStar to identify itself as Onstar, and for Kim to identify himself as Kim.  Then Kim can give OnStar a Delegation Coupon allowing it to call for help on my behalf.  The coupon should be very restrictive.  And if the service does something improper, that impropriety will clearly be associated with the service's own identity, not with Kim.

There is no user-absent scenario 

In otherwords, there is no user-absent scenario.  There is a user is present and delegates authority scenario.  After all, how can a user delegate authority if she isn't present???

CardSpace is built on this principle.  A delegated authority coupon is just a set of claims.  CardSpace facilitates the exchange of any claims you want – including delegation claims.  So using CardSpace, someone can build a system allowing users to delegate authority to a service which can then operate – as itself – presenting delegation tokens whenever appropriate.

This is the right way to do things from a security point of view.  We need to move beyond the idea of omnipotent services running behind the curtain, which is what we have come up with in the past, to a truly secure model where the user consciously delegates and systems demonstrate this in an auditable fashion.

Surely it is obvious this is the best way to reduce everyone's exposure and liability.  The user has less exposure because she controls what she delegates.  The service has less exposure because it operates under specific and explicit permissioning, and insider attacks are significantly mitigated.

As much as I think Liberty represented a step forward when it first stepped up to the plate, it needs to embrace the user-centric model and replace the more monolithic “on behalf of” mechanisms with a proper approach to delegation under the control of the affected parties.

 

10 thoughts on “Wrong-headed impersonation

  1. In otherwords, there is no user-absent scenario. There is a user is present and delegates authority scenario. After all, how can a user delegate authority if she isn’t present??? That's fine as long as one of the rightss that can be delegated is ability to delegate further. And I'm guessing that that's what Eve is really talking about. Not delegating 100% of her rights to some agent, but delegating sufficient rights that the agent can act as a more-or-less first class entity, negotiating and delegating on my behalf.

    In fact the only (obvious) rightg that I should not be able to delegate is the right of revocation….

  2. Yes, I agree with what you say about delegating further, provided that is what the user initially envisages. But there is a big difference here. The service is not acting AS the user. It is acting on its own with proof of delegation by the user. It has its own identity and I can hold it accountable for what it does. Another way to put this: the service (as a user) is present – and has some tokens a person (as a user) has given it when the user was present.

    So in my view CardSpace is the proper paradigm for user control. And WS-Trust, with the principal ability to convey MULTIPLE tokens (one for the service, and delegation tokens from the user) is the right infrastructure for the service.

  3. For an example of user-absent scenarios, look at grid computing. In this scenario, a researcher is going to launch a long-running batch job into the computing grid. Such a job may run for days and the researcher needs to go home and feed the dog and may be absent if a particular stage in the job requires authentication. The grid folks have invented a “proxy certificate” for this case. While it's still the case that a user is present when their “main” identity is used, the purpose of the proxy cert is to delegate authentication to an agent in their absence such that if that agent is compromised, all the researcher loses is that temporary credential.

    Perhaps this doesn't count as a “no user absent scenario”. Nevertheless, I think it's certainly relevant to discussions about delegation.

  4. Pingback: Kim Cameron’s Identity Weblog » Drilling further into delegation

  5. Pingback: Links » Delegation and Identity Management

  6. Pingback: 0xDECAFBAD » Blog posting delegation and third-party auth

  7. Pingback: Kim Cameron’s Identity Weblog » Blog posting delegation and third-party auth

  8. Pingback: Kim Cameron’s Identity Weblog » Services should use their own credentials, not mine

  9. Pingback: dale olds’ virtualsoul » A Field Trip to the Planetarium: Delegation, Authorization Documents, and Auditing

  10. Pingback: NOVELL: Cool Blogs » Blog Archive » A Field Trip to the Planetarium: Delegation, Authorization Documents, and Auditing

Leave a Reply