Unifying the experience of online identity

Jon Udel zeros in on the problem of web sites that introduce “novel” authentication schemes once these schemes start to proliferate.   I had the same concerns when I set out the seventh law of identity (consistent experience).  Jon says:

Several months ago my bank implemented an anti-phishing scheme called Site ID, and now my mortgage company has gone to a similar scheme called PassMark. Both required an enrollment procedure in which I had to choose private questions and give answers (e.g., mother’s maiden name) and then choose (and label) an image. The question-and-answer protocol mainly beefs up name/password security, and secondarily deters phishing — because I’d notice if a site I believed to be my bank or mortgage company suddenly didn’t use that protocol. The primary anti-phishing feature is the named image. The idea is that now I’ll be suspicious if one of these sites doesn’t show me the image and label that I chose.

When you’re talking about a single site, this idea arguably make sense. But it starts to break down when applied across sites. In my case, there’s dissonance created by different variants of the protocol: PassMark versus Site ID. Then there’s the fact that these aren’t my images, they’re generic clip art with no personal significance to me. Another variant of this approach, the Yahoo! Sign-In Seal, does allow me to choose a personally meaningful image — but only to verify Yahoo! sites.

These fragmentary approaches can’t provide the grounded and consistent experience that we so desperately need. One subtle aspect of that consistency, highlighted in Richard Turner’s CardSpace screencast, is the visual gestalt that’s created by the set of cards you hold. In the CardSpace identity selector, the images you see always appear together and form a pattern. Presumably the same will be true in the Higgins-based identity selector, though I haven’t seen that yet.

I can’t say for sure, because none of us is yet having this experience with our banks and mortgage companies, but the use of that pattern across interactions with many sites should provide that grounded and consistent experience. Note that the images forming that pattern can be personalized, as Kevin Hammond discusses in this item (via Kim Cameron) about adding a handmade image to a self-issued card. Can you do something similar with a managed card issued by an identity provider? I imagine it’s possible, but I’m not sure, maybe somebody on the CardSpace team can answer that.

In any event, the general problem isn’t just that PassMark or Site ID or Sign-In Seal are different schemes. Even if one of those were suddenly to become the standard used everywhere, the subjective feeling would still be that each site manages a piece of your identity but that nothing brings it all together under your control. We must have, and I’m increasingly hopeful that we will have, diverse and interoperable identity selectors, identity providers, relying parties, and trust protocols. But every participant in the identity metasystem must also have a set of core properties that are invariant. One of the key invariant properties is that it must bring your experience of online identity together and place it under your control.

The “novel authentication” approach used by PassMark and others doesn't scale any better than the “pocket full of dongles” solutions proposed by Dongle queens or – for that matter – than conventional usernames and passwords. 

So far Information Cards are the only technology that both prevents phishing and avoids the novel authentication and multiple dongle problems.

By the way – if what Jon calls the “dissonance” problem that arises from the use of different images and questions on web sites were to be overcome by reusing the same images and questions everywhere, things would only get worse!

Once sites begin to share the same “novel authentication” model, you no longer have novel authentication. 

In fact you return full circle to the deepest phishing problems.  Why? 

If you went to an evil site and set up your reusable images and questions, you would have taught the evil site how to impersonate you at legitimage sites.   Thus in spite of lots of effort, and lots of illusions, you would end up further behind than when you started.

Denial mobs & the Cyberwar on Estonia

Ross Mayfield of Socialtext writes more explicitly about the same possible social-technical phenomena I hinted at in my recent piece on Cyber-attack against Estonia:

The latest thread of the Cyberwar attack against Estonia, as covered in the NY Times, an interview in Cnet with an expert from Arbor Networks and a post Kim Cameron raise an interesting question.  It is unlikely that the Russian government can be directly linked to the massive coordinated and sophisticated denial of service attack on Estonia. It is also possible that such attack could self-organize with the right conditions.  Is a large part of our future dealing with hacktavists as denial mobs?

Given the right conditions that make a central resource a target, a decentralized attack could be decentralized in its coordination as well.  Estonia may be the first nation state to be attacked at the scale of war, but it isn't just nations at threat.  The largest bank in Estonia, in one of the top markets for e-banking, has losses in excess of $1M.  Small amount relatively, but the overall economic cost is far from known.

If a multinational corporation did something to spark widespread outrage, such an attack could emerge against it as a net-dependent institution.  Then we would be asking ourselves if the attack was economic warfare from a nation or terrorist organization.  But it also could be a lesser, and illegal, form of grassroots activism.  None of this is particularly new, but less in concept.

But what is new are tools, that cut both ways, for easy group forming and conversation. 

Identity management survey

Marcus Lasance has a sterling reputation in identity management, having contributed to its evolution for many years now.  

He was well known as managing director of MaxWare (recently acquired by SAP) and is now involved with Siemens.  For those not familiar with the European landscape, both of these companies have done extraordinary identity work.

Marcus has put together an identity management survey that I promise isn't an advertising gimmick, and has offered to share the results with the blogosphere, so why not help out?  I did.  Now I'm going to pass the URL on to some of my friends in the Microsoft IT department, since they will have more relevant answers than I do as an architect.  You may want to answer it directly, or pass it on to your IT colleagues.

UPDATE:  Many people have reported problems with the first version of this link (which apparently thanked me for my survey response…  At least you know I tried it!)  I think the new link fixes the problem.   

Roland Dobbins on DDoS attacks and mitigations

Roland Dobbins has written to point out that the recent Russian cyber-attacks on Estonia are not the first launched by one state against another (he cites incidents during the Balkan confict, as well as China versus Japan).

Then he gives us an overview of DDoS attacks and mitigations:

DoS attacks are easy to trace as long as Service Providers (SPs) have the proper instrumentation and telemetry enabled on their routers – NetFlow is the most common way of doing this, along  with various open-source and commercial tools (nfdump/ nfsen, Panoptis, Arbor, Lancope, Narus, Q1).

Most DDoS attacks these days aren't spoofed, because a) there's no need, given the zillions of botted computers out there available for use as attack platforms and b) because many SPs have implemented antispoofing technologies such as uRPF, iACLs, etc.

However, antispoofing (BCP38/BCP84) isn't universally deployed, and so the ability to spoof combined with DNS servers which are misconfigured as open recursors means that attackers can launch very large (up to 25gb/sec that I know of) spoofed DDoS attacks, due to the amplification factor of the open DNS recursors.

There are various mitigation techniques employed such as  destination-based (destroys the village in order to save it) and/or source-based remotely-triggered blackholing (S/RTBH), plan old iACLs, and dedicated DDoS mitigation appliances; there's a lot of information-sharing and coordinated mitigation which takes place in the SP community, as well.

But there isn't nearly enough of any of these things, especially in the developing world.

Russian cyber-attacks on Estonia

Here is a report from the Guardian on what it calls the first cyber assault on a state. 

Whether it's the first or not, this type of attack is something we have known was going to be inevitable, something that was destined to become a standard characteristic of political conflict.

I came across the report while browsing a must-read new identity site called blindside (more on that later…).  Here are some excerpts from the Guardian's piece:

A three-week wave of massive cyber-attacks on the small Baltic country of Estonia, the first known incidence of such an assault on a state, is causing alarm across the western alliance, with Nato urgently examining the offensive and its implications.

While Russia and Estonia are embroiled in their worst dispute since the collapse of the Soviet Union, a row that erupted at the end of last month over the Estonians’ removal of the Bronze Soldier Soviet war memorial in central Tallinn, the country has been subjected to a barrage of cyber warfare, disabling the websites of government ministries, political parties, newspapers, banks, and companies.

Nato has dispatched some of its top cyber-terrorism experts to Tallinn to investigate and to help the Estonians beef up their electronic defences.
“This is an operational security issue, something we're taking very seriously,” said an official at Nato headquarters in Brussels. “It goes to the heart of the alliance's modus operandi.”

“Frankly it is clear that what happened in Estonia in the cyber-attacks is not acceptable and a very serious disturbance,” said a senior EU official…

“Not a single Nato defence minister would define a cyber-attack as a clear military action at present. However, this matter needs to be resolved in the near future…”

Estonia, a country of 1.4 million people, including a large ethnic Russian minority, is one of the most wired societies in Europe and a pioneer in the development of “e-government”. Being highly dependent on computers, it is also highly vulnerable to cyber-attack.

It is fascinating to think about how this kind of attack could be resisted:

With their reputation for electronic prowess, the Estonians have been quick to marshal their defences, mainly by closing down the sites under attack to foreign internet addresses, in order to try to keep them accessible to domestic users…

Attacks have apparently been launched from all over the world:

The crisis unleashed a wave of so-called DDoS, or Distributed Denial of Service, attacks, where websites are suddenly swamped by tens of thousands of visits, jamming and disabling them by overcrowding the bandwidths for the servers running the sites…

The attacks have been pouring in from all over the world, but Estonian officials and computer security experts say that, particularly in the early phase, some attackers were identified by their internet addresses – many of which were Russian, and some of which were from Russian state institutions…

“We have been lucky to survive this,” said Mikko Maddis, Estonia's defence ministry spokesman. “People started to fight a cyber-war against it right away. Ways were found to eliminate the attacker.”

I don't know enough about denial of service attacks to know how difficult it is to trace them. after the fact.  But presumably, since there is no need to receive responses in order to be successful in DOS, the attacker can spoof his source address with no problem.  This can't make things any easier.

Estonian officials say that one of the masterminds of the cyber-campaign, identified from his online name, is connected to the Russian security service. A 19-year-old was arrested in Tallinn at the weekend for his alleged involvement…

Expert opinion is divided on whether the identity of the cyber-warriors can be ascertained properly…

(A) Nato official familiar with the experts’ work said it was easy for them, with other organisations and internet providers, to track, trace, and identify the attackers.

But Mikko Hyppoenen, a Finnish expert, told the Helsingin Sanomat newspaper that it would be difficult to prove the Russian state's responsibility, and that the Kremlin could inflict much more serious cyber-damage if it chose to.  (More here…)

There was huge loss of life and bitterness between Russia and Estonia during the second world war, and there are still nationalist forces within Russia who would see this statue as symbolic of that historical reality.  It is perhaps not impossible that the DOS was mounted by individuals with those leanings rather than being government sponsored.  Someone with a clear target in mind, and the right technical collaborators, and who could muster bottoms up participation by thousands of sympathizers could likely put this kind of attack in place almost as quickly as a nation state.

Age verification roundup

by Tateru NinoTateru Nino at Second Life Insider has done a roundup of age verification issues arising from Second Life's experiment in controlling access to adult content. 

There's a lot of talk about age/identity verification going on, so I've done a pile of reading of material and logs (thanks for everyone who has provided links, logs and other information to source from) and condensed them into a not inconsiderable bulleted list, below the fold.Longer than your hand, people. Grab a cup of coffee.

  • Credit cards do not provide proof of age. In some areas and with some card providers you can obtain a credit card compatible card before you can talk.
  • Verification costs. It will be available at a token fee for premium account holders, but the brunt of the verification costs apparently will be borne by basic account holders. Linden Lab is passing along the costs of verification.
  • Mobile phones do not provide proof of age. In the UK, more children under 12 possess a mobile phone than adults over 18. In the USA, almost 50% of children have a mobile phone.
  • Driver's licences are not as widely held as you might think. Particularly the old, infirm or handicapped may not possess them. Areas with highly developed public transport systems, or poorer nations may have low penetration of these credentials.
  • Online verification does not verify the person, only the validity of the documentation that person provides. The person need not provide their own documentation for verification to be successful. Therefore, this system can only realistically be used to shift blame and does not constitute a method of verification or trust.
  • The status of a minor who has provided false verification information can (apparently) no longer be contested. If it says they're of a certain age, would it be harassing behavior to attempt to challenge that?
  • Linden Lab is apparently wishes to use a third-party company to keep verification costs down, and to prevent access to or storage of verification information by Linden Lab employees.
  • The age at which you are considered to be permitted to access ‘adult content’ varies from country to country. In most, the age varies between 12 and 25. A very few jurisdictions do not permit it under any circumstances. In most US Jurisdictions the age for the apparent class of adult content Linden Lab intends to grant access to would be 21, not 18.
  • Having taken steps to attempt to verify the age of a user, and then granted them access to adult content, does Linden Lab them become liable if you are still not eligible to be transmitted adult content in your jurisdiction? Does it even matter if the age/identity is accurate or not?
  • The verification provider may not demand or require any information from you. However, they are under no obligation to provide verification for you if you do not willingly provide it.
  • Integrity Services was initially given as the verification provider, however there is good cause to believe that the provider will change before plans go ahead.
  • Merely requesting an SIN identification from a Canadian citizen constitutes a legal offense. This policy may extend to other forms of identifying information in various countries.
  • Linden Lab provides only very vague guidelines for what does and does not constitute ‘adult content’. These are “adult content is that which is overtly, graphically, or explicitly sexual in nature or intensely violent”, which obviously leaves a lot of open questions.
  • The guidelines of most nations are vague on what constitutes adult content. In some cases, certain kinds of political content may fall under this classification. In India, “scenes that are a threat to the integrity to the nation, and those which disturb the friendly peace between nations” are classifiable as adult content.
  • Flagging parcels that contain adult content is mandatory.
  • Adult content flagged parcels must be within Mature sims.
  • It is inevitable that the judgement of an individual based on their own society's and community's standards and norms will unintentionally disagree with the judgement of one or more other residents or Linden Lab staff members. What will happen then? Will Linden Lab exercise editorial control, or assign punishments or penalties?
  • Verification may not be accessible to Linden Lab or verification service employees but must be archived for a period of time that may changed or extended by law before that that period expires. Can it be extended by other means (eg: Company policy?).
  • Archived verification data may be accessed during an audit. Who can initiate an audit of this data, and under what circumstances?
  • Will this archived verification data be subject to the European Union's DPA legislation, as would be required if any EU citizen's data is stored/archived?
  • Do you know what your nation's policy is on providing your passport number to overseas third parties?
  • The Second Life website already requests that users state using a check box that they are over the age of 18. By checking this box, users are making a statement that may be held as truth in a court of law. In short, they can and will be held responsible if this statement is later shown to be untrue. Why is it necessary for Linden Lab to perform an expensive operation like this that appears to only increase their overall legal exposure? What are we missing?

The author concludes:

Whew. What did I miss?

Jeff Bohren on role of CardSpace

Jeff Bohren at BMC Software has an interesting take on CardSpace and TEG – as well as other related matters.  And in this posting he says that BMC Software will be participating in the interoperability event at the next Burton Catalyst.  This really adds to the momentum. 

There will be a User Centric interoperability event at the next Burton Catalyst in SF. This will bring together several IdM vendors and open source projects to demonstrate interoperability between different implementations of Cardspace/InfoCard and OpenID. BMC Software will be participating. We will also have a hospitality suite the following night. I will be there so if you want to drop by I would be glad to talk with you about IdM issues.

Mike Jones from Microsoft has some great Cardspace/InfoCard resources on his blog. If you are interested in this area, you should definitely check this out. You should also check out Pamela Dingle’s introduction to Cardspace.

Microsoft has recently announced that they have sold over 40 million copies of Vista in the first 100 days since its release. Obviously not all of those are installed and in use, but this still a lot of users. And every one of them is a potential Cardspace user.

If IE isn’t your cup of tea, there are several other option available. Xmldap.org has a plug-in for Firefox. I gave it a try, but for some reason I could not use it to do InfoCard authentication to Kim Cameron’s blog, which you can obviously do with CardSpace.

There has been a recent spurt of debate over at the TEG mailing list about Cardspace. I don’t want to waste TEG bandwidth on what is really a tangential issue, so here is my take on the value of Cardspace/InfoCard.

The best way to think of the value of Self-Issued InfoCards is to think of them as analogous in feature to end-user SSL client certificates. In essence they are a holder-of-key style authentication that can be used by itself or in conjunction with a password based authentication to dramatically improve the security of the authentication process. Like client certificates, InfoCards authenticate the computer the user is on, not the user. They further have the advantage of presenting a very user friendly graphical mechanism to select what identity should be used.

While all InfoCard implementations have this value, Cardspace goes further and adds additional features to thwart phishing, man-in-the-middle-attacks, and software key loggers. If the US banks where smart, they would adopt InfoCard as their solution to comply with FFIEC guidance for on-line banking. Cardspace/InfoCard could be used as a second factor of authentication to use for financially sensitive transactions. Not as a replacement for passwords, but as a supplement. And best of all (to the bank) there is zero cost on a per user basis.

For enterprises there is an important potential value for InfoCards, and it has nothing to do with internal authentication. The value is by using InfoCards, an employee of a company can easily choose different identities depending on whether he is representing the company in a specific transaction or not. It has to do with separating personal from professional personas. A company could issue a managed InfoCard to each employee for use for their professional persona and establish best practices for using their self-issued InfoCards for personal business. Now you can do this without InfoCards by creating multiple IDs, but as a practice no one does that.

Update 5-24-07

Shibboleth just announced that they will add support for Cardspace/Infocard in the Shibboleth architecture. Kim Cameron's thoughts about it are here and Mike Jone's comments are here. This is a great development. The Shibboleth project has a great deal of respect and mind share in the identity community.

I'm not sure I agree that InfoCards authenticate the computer the user is on, and not the user.  I think that depends on whether they are combined with a challenge such as a one-time password.  I hope Jeff writes more about what he means by this.

Separation of powers

Paul Madsen is being his amusing self over at ConnectID:

Doesn't the principle of ‘Separation of Powers‘ forbid Kim playing both the legislative and judicial roles, i.e. writing the ‘laws’, and then adjuticating on compliance?

Certainly makes for efficient government.

To which Eric Norman replies:

Well, it never stopped Murphy from sitting in judgement about his law.

Of course this is all about what I claim are laws of computer science, not legal edicts, and the phenomena described are measurable.  We should really end up agreeing about how systems behave, even if we finally disagree about how they should behave. 

Ben Laurie on Selective Disclosure (Part 2)

In introducing people to his Selective Disclosure paper, Google's Ben Laurie says: 

In fact, there are many ways CardSpace could violate the laws, but there is one which it is currently inherently incapable of satisfying, which is the 4th law – the law of directed identity – which says, once you’ve fought your way through the jargon, that your data should not be linkable.

Ben doesn't like the term “omni-directional identifier”, which is certainly his prerogative.  But speaking of jargon, note that according to the Oxford English Dictionary, Ben's word “linkable” doesn't actually exist… 

Meanwhile “omni-directional” is a real word from the field of telecommunications (isn't that what we are working in?)  It means “of equal sensitivity or power in all directions”.  Similarly, “unidirectional” means “moving or operating in a single direction”.

So I think the Fourth Law is precise enough:

A universal identity system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

The word “discovery” is again used in the technical sense of making it possible to locate and rendezvous with other entities.   The goal here is to embrace the range of use cases I discussed in part one. 

Ben argues that CardSpace breaks this Fourth Law.  In this he is wrong.  I suspect he is confusing CardSpace, which is just a way of selecting between identity providers, and the identity providers themselves.  Let's get that really straight.

CardSpace is one component of the Identity Metasystem – by which I mean a distributed mesh of parties asserting and depending upon identity.  CardSpace informs the user about the identity providers that can satisfy a given relying party request, and provides a mechanism to tell the user what information must be released to the relying party in order to gain admission to the site.  But the identity selector does not itself make assertions or sign them cryptographically, or do anything that introduces linkability or traceability.  If linkability is introduced, it is because of the choice of the identity provider people use with the the system, and of the cryptographic systems they employ.  

Privacy characteristics of the self-asserted Identity Provider 

While CardSpace is an identity selector, we have built it to include a self-asserted identity provider as a way to bootstrap the system.   So what are the privacy characteristics of this provider?

  • It emits no identifiers that allow the identity of the user on one system to be linked to the identity of the user on any other.  
  • A different signing key is used at each site visited so keys and signatures cannot be correlated.
  • Relying parties cannot collude with this identity provider because it is run by the user. 

So the Identity Provider that ships with CardSpace does not break the Fourth Law either.

Managed Card Providers 

Now let's talk about managed card providers, and think about other systems such as Liberty or Shibboleth or OpenID or SAML or WS-Federation in browser mode. 

These systems always identify the relying party to the identity provider.  They do so because they need to tell the identity provider how to redirect the client's browser back to the relying party.  So they are what I call panoptical by design.  There is zero collusion required for the identity provider to know what is being asserted where – that knowledge is designed right into the system.

CardSpace breaks with this paradigm, and I hope Ben comes to recognize this. 

To support use cases where we do NOT want linkability, CardSpace hides the identity of the relying party from the identity provider.  If we had built it without this feature, it too would have been “panoptical by design”.  But we didn't do that.  We built it to conform with the Fourth Law.  In other words, CardSpace does not provide unnecessary handles to facilitate linkability.

How does CardSpace hide the identity of the relying party?  It associates some random information – unknown to the identity provider – with each Information Card.  Then it hashes this random information (let's call it a “salt”) with the identity of the site being visited.  That is conveyed to the identity provider instead of the identity of the site.  We call it the “Client Pseudonym”.  Unlike a Liberty Alliance client pseudomym, the identity provider doesn't know what relying party a client pseudonym is associated with. 

The identity provider can use this value to determine that the user is returning to some site she has visited before, but has no idea which site that would be.  Two users going to the same site would have cards containing different random information.  Meanwhile, the Relying Party does not see the client pseudonym and has no way of calculating what client pseudonym is associated with a given user.   

The question now becomes that of how identity providers behave.  Given that suddenly they have no visibility onto the relying party, is linkability still possible?  I'll discuss this next.

Shibboleth adds CardSpace support

Here is news from Internet2 and Shibboleth, the open-source software for building multilateral federations that has become especially popular in the academic world (more information on Shibboleth here). 

ANN ARBOR, Mich. – May 23, 2007 –  Adding information card support to Shibboleth, the most widely-deployed federated authentication architecture, would enable interoperability with Windows CardSpace which provides critical support for secure user-centric authentication and identity information exchange for web-based applications. By enabling this interoperability, Microsoft and Internet2 aim to help users exchange personal identity information more safely and easily. In doing so, institutions can more effectively leverage their existing and future investments in their identity management solutions and build a closer, safer relationship with their users.

“As more and more companies and organizations make information materials and resources accessible online, the need for secure access solutions has become critical. We see information card technology like Microsoft's Windows CardSpace as a very important step forward in creating a ubiquitous Internet identity layer, which is a key goal of the Shibboleth project as well,” said RL “Bob” Morgan, security architect at the University of Washington and co-manager of the Shibboleth Project. “We appreciate Microsoft's leadership in helping to create an open environment for information card development and deployment, and are grateful for Microsoft support of Windows CardSpace work in Shibboleth.”

Shibboleth is a standards-based, open source middleware architecture providing both intra-domain and inter-domain single-sign on (SSO) capability. Used by over 20 million users worldwide within the research and higher education community, Shibboleth implements the OASIS Security Assertion Markup Language (SAML) standard specification, and is currently interoperable with Microsoft's Active Directory Federation Services (ADFS).

Both Shibboleth and Windows CardSpace provide the underlying mechanisms for institutions and individuals to share resources across organizational boundaries and to make informed authorization decisions for the access of protected online resources. This federated authentication model implemented by both Internet2 and Microsoft has proven to provide online resource providers and institutions with a solid platform for exchanging information in a highly secure and privacy-preserving manner. Once development is complete, sites using Windows CardSpace will have the ability to participate in the growing number of Shibboleth-based federations worldwide.

“The Internet2 Shibboleth project has been one of the leaders in bringing interoperable digital identity to the academic and research communities worldwide,” said Michael B. Jones, senior program manager for Identity Partnerships at Microsoft. “Shibboleth's support for information cards allows people in the Shibboleth federation to use the cards at sites participating in the Identity Metasystem, making the identities more valuable to both the issuers and to the individuals, as well as enhancing the user's control of their online interactions.”

I echo Mike's words.  Shibboleth is distinctly forward thinking in its approach, and has been the main crucible for refining the thinking (and practice) that enables multilateral federations like those needed to facilitate co-operation between universities. 

As Shibboleth federations continue to grow, so will the rewards for attacking them.  CardSpace, and other compatible Information Card selectors, will add resilience and phishing resistance while helping solve Shibboleth's “home site discovery” problem in a way that doesn't put control in the hands of evil sites posing as federation affiliates. 

For more details on what is at stake here, see this posting where I explain a similar vulnerability in OpenID.  SAML and the browser-based version of WS-Federation are also subject to these attacks, which become more probable as the technologies become more widely deployed.