The Liberty Alliance. The past week was monopolized by the reactions I received to my essay, On Liberty and the Case for Anonymous Federation of Identity. I've received more feedback regarding this essay than on any other topic I've addressed in my weblog or here in the newsletter. Most of the comments were in agreement, but since virtually all were via private email, I can't quote them.

I heard from some heavy hitters in the worlds of security and digital identity including Andre Durand (pingid.org and pingid.com), Eric Norlin (Digital ID World), Jiri Ludvik (who publishes a security weblog), Gerry Gebel (Burton Group), Brent Sleeper (The Stencil Group), and Carol, Allen, Russ and Scott (Glenbrook Partners).
Posted Tuesday, September 17, 2002 5:55:58 PM 

The Comparmentalization Attack. As part of my criticism of the Liberty Alliance, I've been explaining a class of security threat I've named (for lack of a better term, although I'm sure there must be one) the Compartmentalization Attack. We've all seen the generic submarine movie in which the engine room takes a direct torpedo hit. In order to save the rest of the ship, all the compartment bulkhead doors are closed, committing the isolated sailors to their watery deaths.

Compartmentalization--limiting the scope of damage--plays an important role in security planning. I believe the Liberty Alliance 1.0 spec weakens consumer protection by leaving open bulkhead doors between federated providers, therefore creating opportunities for attackers.

Under Liberty 1.0, when a user opts-in to the sharing of his identity between two parties, he must initially log in to both web sites. The parties don't learn the usernames and passwords used on the other sites (i.e., no identifying data are exchanged), but an anonymous relationship is created. The next time that same user visits one of the sites, he can click through using a link to the other site without authentication.

If a Bad Guy manages to obtain the consumer's username and password to the first site, he can impersonate the consumer on that site. That risk has always existed. But due to the association created by Liberty 1.0, the Bad Guy now can also click through to the other federated sites--continuing to impersonate the consumer--without being authenticated via usernames and passwords.

Once the Circle of Trust between providers has been created under Liberty 1.0, compartmentalization of the identity has been compromised. The bulkhead doors have been opened. A password-theft attack that would have been contained to a single site without 1.0, now has a broadened scope. If my bank and brokerage account identities are federated, anyone able to log into one can automatically access the other. [This could even be an employee of one of the merchants. For instance a wayward broker who somehow learned my password on his company's site could not only impersonate me there, but at my federated bank as well.]
Posted Sunday, September 15, 2002 6:18:54 AM

Eric Norlin (a highly respected security/identity expert) disagreed.
Posted Monday, September 16, 2002 2:43:32 PM  

Scott Loftesness asked, "Is it any worse than having users writing down multiple userids and passwords on stickie notes next to their screens or keyboards? Or, perhaps even worse, users who use the same userid/password combinations across multiple sites and thereby have the same risk of loss?"

The difference is that these are behavioral issues: entirely personal and client-side problems. Liberty, Passport and other single sign-on systems institutionalize the password re-use problem and manifest it beyond the control of the consumer. It places merchants in the position of encouraging risky practices that, at the same time, many of them publicly discourage. We're all told that it's bad to keep passwords in our wallets and to never reuse them at mutliple sites. So why, then, is it okay for Microsoft or the Liberty Alliance members to do the equivalent on our behalf?

Sure, if you're a password re-user, then Liberty-style federation doesn't make things any worse. But if you've followed the experts' advice and used different passwords for each site, then identity federation creates an exploitable path that you've worked hard to prevent.

There's also a difference between enterprise/intranet single sign-on systems and those deployed for the public. In the former case, it's generally (not entirely) the enterprise that assumes the risks associated with the abuse of such a system. Any CIO installing a corporate single sign-on system knows the risks he's taking. And the data that's being protected by the authentication/authorization system is, for the most part, corporate not personal data.
Posted Sunday, September 15, 2002 12:55:08 PM 

Glenbrook Partners published a well-considered critique of my analysis of the Liberty Alliance 1.0 documents. A few points I'd like to make in rebuttal:

• Regarding the benefits of single sign-on for mobile devices or cross-platform identities: If that's the objective, there are ways to accomplish this without the drawbacks of Liberty. I'll have more to say on this later, but for now, just imagine RoboForm, based on ECML, and linked to an encrypted identity database that's accessible from any client or platform but that only the consumer can read or modify. [Thanks to Scott Loftesness for the link to the RFC2706 ECML spec.]
• "No actual individual identity information is shared between identity provider and service provider." True, but I'm not worried about the cooperating parties. I'm worried about the Bad Guy who has gained access to my account at the identity provider. As explained above, he can then access all of my other accounts within the Circle of Trust without the need for any more usernames or passwords.
• The Glenbrook paper claims that issues surrounding target marketing are "tangential to the mission and objectives of the alliance." I disagree. As I wrote in my original essay, I believe (and I think substantiated) targeted marketing and the creation of new ways to sell goods and services to consumer are precisely the objectives of the Liberty Alliance. Why else would the members bother to do this? If you think it's for the altruistic good of the consumer, do you believe the same about Passport or the new MSN Wallet? (Not me.)

Patricia Seybold and Geoffrey Bock published their analysis of the Liberty Alliance proposal the day after I published mine. It's almost as though we were reading from the same script. (Great minds think alike?) Sound bytes from Seybold:

• Not customer-centric enough! [Exclamation theirs]
• Liberty just saves you the step of logging on separately to each of these supplier's sites.
• ...displeased with the marketing-centric approach...
• ...the group's vision is one in which businesses make marketing partnerships with one another and customers opt into these business relationships...
• ...no provision yet (in Version 1.0) for customers to control which of their profile information they want to share in which contexts with which providers.
• Federated single sign-on is a good start. [This is where I differ with Seybold. I think the concept is fundamentally flawed.]

But the week wasn't only about the Liberty Alliance. I came across a few interesting papers and articles:

Securing & Managing XML & Web Services in the Enterprise. An excellent report by ZapThink, available for free download at Westbridge's site. (Registration required.) Jason and Ron compare and elaborate upon management platforms, security platforms and XML proxies.
Posted Monday, September 16, 2002 12:55:39 PM   

WS-Security: 6-24 Months to Go. "Phillip Hallam-Baker, principal scientist at VeriSign, has been helping to develop the WS-Security Web services security standard. His advice to anyone considering building Web services across the Net is to wait: He says it is likely to take between six months and two years to nail down the WS-Security specification that he helped to write."
Posted Tuesday, September 03, 2002 6:32:16 AM   

IBM and Microsoft Diverging? Darryl Taft points out that WS-Routing is a Microsoft-only spec that the company has not submitted to W3C and has not been endorsed by IBM.

"Cooperating on the base standards is easy because people don't make money on just connecting things," said Eric Newcomer, chief technology officer of Iona Technologies plc., of Waltham, Mass. "But when you get into security or business processing or transaction processing, it gets harder to agree on things at that level, and companies start competing with each other. Whereas nobody ever competes on a better TCP/IP--everybody has that." [Source: eWeek]
Posted Tuesday, September 03, 2002 6:52:14 AM  

Playing Hardball With Your Hoster. "The most expensive real estate you'll ever lease is collocation space...Before you sign on with a Web hoster, here's what you need to do." A checklist and strategy for colocation buyers by Matthew Leeds at Network World.
Posted Monday, September 16, 2002 8:58:24 AM

Changing Web Hosts. "Moving to a new host is always a traumatic, time consuming event. You should take pains to be prepared so that the trauma is reduced in duration and loss...If you are lucky, you get to make the choice about moving." Richard Lowe Jr. has published helpful checklists for both how to move, and how to be prepared in case you need to.
Posted Friday, September 13, 2002 1:40:31 PM 

SLAs Make a Difference. Lest you think SLAs can't be effective, read this article in Outsourcing Journal of how DoubleClick improved its service in response to paying out over $1 million in SLA penalties.
Posted Wednesday, September 04, 2002 10:31:34 PM

Subscribe
View or search newsletter archives
Email Doug or visit his site at www.rds.com
Permanent link to this issue