Grab them eyeballs! Any cred at all!

Want to deeply understand how OpenID would make our lives better on social networks? Check out this piece by Dare Obasanjo, a program manager within Windows Live.  But be prepared to be jolted.  According to Dare, there is indeed a promised land, but we won't be allowed into it.

Dare is responding to Wired's Slap in the Facebook:  It's Time for Social Networks to Open Up.  He talks about the common-sense economics of identity, then asks why “there seem to be more OpenID providers than there are consumers”, concluding:

Why would Facebook implement a feature that reduced their user growth via network effects? Why would MySpace make it easy for sites to extract user profile information from their service? Because openness is great? Yeah…right.

Openness isn’t why Facebook is currently being valued at $6 Billion…

Dare's explanation of how the big web properties see things is spot on.  But are they right? 
Continue reading Grab them eyeballs! Any cred at all!

Ensuring Privacy and Consent

I think many will benefit from Marco Casassa Mont's Research on Identity Management blog.  He discusses business-driven identity management – and its foibles.

A recent post invites us to an upcoming Kable conference that I would attend if I possibly could:

An interesting conference is going to take place on July, 9th in London, UK on “Ensuring Privacy and Consent in Identity Management Infrastructures”. It is supported by DTI and free to attend to the private sector and academics. The conference program and online registration form are available here.

“The Department of Trade and Industry (DTI), through the Technology Strategy Board's Network Security Innovation Platform, is working with the Identity and Passport Service (IPS), the Home Office, the Economic and Social Research Council (ESRC) and the Engineering and Physical Sciences Research Council (EPSRC) to develop a work package that will sponsor a £10m, 3-year, research and development programme into how to balance the potentially intrusive nature of identity services and network security with users’ expectations of privacy and consent. This research will be cross-disciplinary, combining social science with technological innovation. …

The aim of this initial workshop on 9 July is to discuss and refine the areas of importance for research, as well as identifying where the research is needed and where the UK has potential to develop world-leading commercial services. The findings of the workshop will lead to the development of projects and proposals using the EPSRC's sand-pit concept at a further workshop to be held in early October.”

You might want to consider attending if you work in the areas of identity and privacy management …

PHP managed card provider

Here's a new managed card provider from Patrick Patterson at  Carillon Information Security Inc.  With commendable understatement, Patrick writes:


I just thought that you'd like to know about a demonstration STS for issuing managed infocards that we've just finished.It's written in PHP, backends into either a database or LDAP, and is easily customizable to accommodate custom claims.

And, since it is written in PHP, it is easily deployable for those that want to experiment with a CardSpace STS, but who may not have either a JSP server to deploy one of the other Java based implementations, or an IIS .NET server to experiment with the one Microsoft has provided.

It is available here.

I'm a sucker for PHP and Ruby on Rails, so I love seeing this support.  Beyond that, I'm interested in Carillon's support for certificates. 

What is it?

The Carillon STS is a PHP-based Federated Identity Provider (IdP) which is capable of acting as a Secure Token Service (STS) compatible with Windows CardSpace and other “infocard” implementations. It has been successfully tested with CardSpace, as well as with Chuck Mortimore's Firefox identity selector plugin.

Once installed and configured, the Carillon STS allows a user to authenticate himself, either by password or by X.509 certificate, whereupon he is issued a digitally signed infocard containing some standard identity claims and optionally some customizable identity claims. When he presents this infocard to a Relying Party's (RP's) site, his browser's identity selector requests a SAML token from the Carillon STS. If the authentication information is still valid, a digitally signed token will be issued with the various claims asserted. The browser takes this token, checks the digital signature, encrypts it for the RP, and passes it along. It is the RP's responsibility to decrypt the SAML token, check the digital signature, check the asserted claims, and make an access decision based on this information.

Current Status:

This project has been tested with available releases of Windows CardSpace and the Firefox identity selector plugin. There are several Relying Party (RP) sites on the web to test against; in particular, the xmldap.org RP is able to consume Carillon STS infocards and display their contents.

Version 0.01 is the initial release of the Carillon STS. It is presently under active development.

License:

The Carillon Demo STS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Carillon Demo STS is Copyright © 2007 Carillon Information Security Inc.

Download:

Note: Please hold down the SHIFT key while clicking on package you want to download to avoid file corruption.

Source: carillon-sts-0.01.tar.gz

I hope to meet Carillon at the next Interopathon.  It's really awe-inspiring to see this level of Information Card expertise developing spontaneously in the security and identity communities.  Congratulations, folks!

Catalyst Interopathon reveals sea change

Here are the logos of the projects participating in the Information Card Interopathon at the Burton Group's Catalyst Conference. Beyond that, people told me about at least half a dozen new open source projects (each with a unique mission) that are sitting in the wings getting ready to go public.  I'll try to keep you posted on these. 

We had a rehearsal for this a couple of months ago at Internet Identity Workshop, but something has changed since then:  many of the players seem to have made strides in getting concrete about how the technology would be used in their products.  That's the key.

According to the press release:

Participants include projects groups Eclipse Higgins Project, Internet2 Shibboleth Project, The Pamela Project, Ian Brown (OpenInfoCard), XMLDAP, and SocialPhysics and vendors BMC Software, CA, FuGen Solutions, IBM, Microsoft, NetMesh, Novell, Nulli Secundus, Oracle, Ping Identity, Sxip Identity, VeriSign, and WSO2.

The demonstration will be centered on a photo sharing application and will show the breadth and maturity of user-centric technologies by executing a variety of information card-based component capabilities including:

  • Protocol and wire format interoperability
  • Card format interoperability
  • Policy interoperability
  • Platform interoperability 

The interop event was organized by OSIS and identity commons and hosted by The Burton Group.  Thanks to all involved.

Control, not nagging

In a piece called Pleading down the Charges, Jeff Bohren of talkBMC  refers to the discussion I've had with Conor about invisible redirection as ‘inflammatory’, and adds: 

“In subsequent exchanges Kim and Conor plead the charges down from a felony to a misdemeanor. Kim allows that the redirection is OK so long as the IdP is completely trusted, but he is concerned about the case where the IdP is not trustworthy…

It's probably true that my “hand in wallet” metaphor was a bit stark.  But how can I put this?  I'm doing a threat analysis.  Saying everything is OK because people are trustworthy really doesn't get us very far.  Even a trustworthy IdP can be attacked;  threats remain real even in the light of mitigations. 

When we put on our security hats, and look at the security of a system, we try as hard as we can to explore every possible thing that can go wrong, and develop a complete profile of the attack vectors.  No one says, “Hey, don't talk about that attack, because we've done this or that to prevent it.”  Instead, we list the attack, we list what we do to mitigate it, and we understand the vulnerability.  We need to do the same thing around the privacy attack vectors.  It is revealing that this doesn't seem to be our instinct at this point in time, and reminds me of the days, before the widespread vulnerability of computer systems became apparent, when people who brought up potential security vulnerabilities were sent to stand in the corner.

Jeff continues:

What is missing from this discussion is the point that “automatic redirection” is not mandated by SAML. Redirection, yes, but automatic redirection is not required. The SP could very well have presented at page to the user that says:

“Your browser is about to be redirected www.youridp.com for the purposes of establishing your identity. If you consent to this redirection, press Continue. If you do not consent, press Cancel….

Correct.  This could be done.  But information can also be made to fly around with zero visibility to the user.  And that represents a risk.

Jeff concludes:

Nobody does this kind of warning because the average user doesn’t want to be bothered and isn’t concerned with it. Not as concerned as, for instance, having a stranger reach into their pocket.

Actually, thanks to “invisible system design”, the “average user” has no idea about how her personal information is being sent around, or that with redirection protocols, her own browser is the covert channel for sharing her identity information between sites.  This might be all right inside an enterprise, when there is an implicit understanding that the enterprise shares all kinds of personal information.  It might even be OK in a portal, where I go to a financial institution and expect it to share my information with its various departments and subsidiaries.  But in the age of identity theft, I'm not so sure she would not be concerned with the invisible exchange of identity information between contextually unrelated sites.  I think she would probably feel like a stranger were reaching into her wallet. 

To be clear, my initial thinking about the “hand in wallet” came not from SAML, but from X.509, where the certificates described in Beyond maximal disclosure tokens are routinely and automatically released to any site that asks for them without any user approval.  SAML can be better in this regard, since the IP is able to judge the identity of the RP before releasing anything to it.  In this sense, not just any hand can reach into your wallet – just a hand approved by the “card issuer”…  This is better for sure.

Do we need to nag users as Jeff suggests might be the alternative? No.  Give the user a smart client, as is the case with CardSpace or Higgins, and whole new user experiences are possible that are “post nagging”.  The invisibility threat is substantially reduced.

In my next post in this series I'm going to start looking at CardSpace and linkability.

Beyond maximal disclosure tokens

I concluded my last piece on linkability and identity technology by explaining that the probability of collusions between Relying Parties (RPs)  CAN be greatly reduced by using SAML tokens rather than X.509 certificates.  To provide an example of why this is so, I printed out the content of one of the X.509 certificates I use at work, and here's what it contained:

Version V3
Serial Number 13 9b 3c fc 00 03 00 19 c6 e2
Signature Algorithm sha1RSA
Issuer CN = IDA Enterprise CA 1
Valid From Friday, February 23, 2007 8:15:27 PM
Valid To Saturday, February 23, 2008 8:15:27 PM
Subject CN = Kim Cameron
OU = Users
DC = IDA
DC = Microsoft
DC = com
Public Key 25 15 e3 c4 4e d6 ca 38 fe fb d1 41 9f
ee 50 05 dd e0 15 dc d6 2a c3 cc 98 53
7e 9e b4 c7 a5 4c a7 64 56 66 1e 3d 36
4a 11 72 0a eb cf c9 d2 6c 1f 2e b2 2a
67 4f 07 52 70 36 f2 89 ec 98 09 bd 61
39 b1 52 07 48 9d 36 90 9c 7d de 61 61
76 12 5e 19 a5 36 e2 11 ea 14 45 b1 ba
12 e3 e2 d5 67 81 d1 1f bb 04 b1 cc 52
c2 e5 3e df 09 3d 2b a5
Subject Key Identifier 35 4d 46 4a 13 c1 ae 81 3b b8 b5 f4 86 bb 2a c0 58 d7 ad 92
Enhanced Key Usage Client Authentication (1.3.6.1.5.5.7.3.2)
Subject Alternative Name Other Name – Principal Name=kc@microsoft.com
Thumbprint b9 c6 4a 1a d9 87 f1 cb 34 6c 92 50 20 1b 51 51 87 d5 a8 ee

Everything shown is released every time I use the certificate – which is basically every time I go to a site that asks either for “any old certificate” or for a certificate from my certificate authority.  (As far as I know, the information is offered up before verifying that the site isn't evil).  You can see that there is a lot of information leakage.  X.509 certificates were designed before the privacy implications (to both individuals and their institutions) were well understood.

Beyond leaking potentially unnecessary information (like my email address), each of the fields shown in yellow is a correlation key that links my identity in one transaction to that in another – either within a single site or across multiple sites.  Put another way, each yellow field is a handle that can be used to correlate my profiles.  It's nice to have so MANY potential handles available, isn't it?  Choosing between serial number, subject DN, public key, key identifier, alternative name and thumbprint is pretty exhausting, but any of them will work when trying to build a super-dossier.

I call this a “maximal disclosure token” because the same information is released everywhere you go, whether it is required or not.  Further, it includes not one, but a whole set of omnidirectional identifiers (see law 4).

SAML tokens represent a step forward in this regard because, being constructed at the time of usage, they only need to contain information relevant to a given transaction.  With protocols like the redirect protocol described here, the identity provider knows which relying party a user is visiting. 

The Liberty Alliance has been forward-thinking enough to use this knowledge to avoid leaking omnidirectional handles to relying parties, through what it calls pseudonynms.  For example, “persistent” and “transient” pseudonyms can be put in the tokens by the identity provider, rather than omnidirectional identifiers, and the subject key can be different for every invocation (or skipped altogether). 

As a result, while the identity provider knows more about the sites visited by its users, and about the information of relevance to those sites, the ability of the sites to create cross-site profiles without the participation of the identity provider is greatly reduced.  SAML does not employ maximal disclosure tokens.  So in the threat diagram shown at the right I've removed the RP/RP collusion threat, which now pales in comparison to the other two.

As we will see, this does NOT mean the SAML protocol uses minimal disclosure tokens, and the many intricate issues involved are treated in a balanced way by Stefan Brands here.  One very interesting argument he makes is that the relying party (he calls it “service provider or SP), actually suffers a decrease in control relative to the identity provider (IP) in these redirection protocols, while the IP gains power at the expense of the RP.  For example, if Liberty pseudonyms are used, the IP will know all the customers employing a given RP, while the RP will have no direct relationship with them.  I look forward to finding out, perhaps over a drink with someone who was present, how these technology proposals aligned with various business models as they were being elaborated.

To see how a SAML token compares with an X.509 certificate, consider this example:

You'll see there is an assertionID, which is different for every token that is minted.  Typically it would not link a user across transactions, either within a given site or across multiple sites.  There is also a “name identifier”.  In this case it is a public identifier.  In others it might be a pseudonym or “unidirectional identifier” recognized only by one site.  It might even be a transient identifier that will only be used once.

Then there are the attributes – hopefully not all the possible attributes, but just the ones that are necessary for a given transaction to occur.

 Putting all of this together, the result is an identity provider which has a great deal of visibility into and control over what is revealed where, but more protection against cross-site linking if it handles the release of attributes on a need-to-know basis.

No SAML bashing intended here

Conor Cahill (Conor's Web log of Esoterica) responds to my discussion about SAML protocol and linkability in a piece called SAML bashing – which is, by the way, absolutely NOT my intent.  I'm simply trying to understand how SAML relates to linkability, as I am doing for all the other major identity technologies.  I can't take up all the points he raises at this point in the flow, but encourage the reader to look at his piece… 

Conor mentions the emerging ideas for a SAML 2.0 Enabled Client/Proxy.  I want to make it clear I wasn't analysing these proposals.  I was analysing SAML as everyone knows it today - using the “http redirect” and “post” modes that have been widely deployed in portals all over the world, and don't require changes to the browser.

Kim writes about SAML's use of redirection protocols.. To start with, he forgets to mention a few important facts as part of his discussion: 

  • SAML defines a profile for an Enabled Client/Proxy (ECP) which is an evolution of the Liberty Alliance's LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).
  • The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.

That said, there are still several statements in Kim's analysis that I feel obligated to respond to. These include:

Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on – trust us.”)

First off, the user only see's nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don't want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace's implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.

Secondly, the analogy is way off base, trying to make this seem like I'm bing pick-pocketed by someone I don't know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of “I give one of my providers permission to reach into my bank account and withdraw money to pay my bill”. I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.

[Much more here…]

I think Conor is misunderstanding my intentions.  I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor's points b) and c) above would likely apply.  But we are looking at linkability precisely to judge the threats in the case where parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.)  So arguing that the identity provider will behave properly has nothing to do with what I am exploring:  risk.  I'll try to build Conor's concerns into my ongoing discussion.

In terms of Conor's point about letting his telephone company deduct directly from his bank account, that's a use case that “rings true”, but there are few companies to which I would want to give this ability.  That's my point.  We need a spectrum of technologies to handle different use cases and risk profiles.

[Update:  Conor later relents a bit in Perhaps not so much Bashing, bringing up a number of points I hope to make part of this exposition.] 

Linkage in “redirect” protocols like SAML

Moving on from certificates in our examination of identity technology and linkability, we'll look next at the redirection protocols – SAML, WS-Federation and OpenID.  These work as shown in the following diagram.  Let's take SAML as our example. 

In step 1, the user goes to a relying party and requests a resource using an http “GET”.  Assuming the relying party wants proof of identity, it returns 2), an http “redirect” that contains a “Location” header.  This header will necessarily include the URL of the identity provider (IP), and a bunch of goop in the URL query string that encodes the SAML request.    

For example, the redirect might look something like this:

HTTP/1.1 302 Object Moved
Date: 21 Jan 2004 07:00:49 GMT
Location:

https://ServiceProvider.com/SAML/SLO/Browser?SAMLRequest=fVFdS8MwFH0f7D%

2BUvGdNsq62oSsIQyhMESc%2B%2BJYlmRbWpObeyvz3puv2IMjyFM7HPedyK1DdsZdb%........2F%
50sl9lU6RV2Dp0vsLIy7NM7YU82r9B90PrvCf85W%2FwL8zSVQzAEAAA%3D%
3D&RelayState=0043bfc1bc45110dae17004005b13a2b&SigAlg=http%3A%2F%
2Fwww.w3.org%2F200%2F09%2Fxmldsig%23rsasha1&
Signature=NOTAREALSIGNATUREBUTTHEREALONEWOULDGOHERE
Content-Type: text/html; charset=iso-8859-1

The user's browser receives the redirect and then behaves as a good browser should, doing the GET at the URL represented by the Location header, as shown in 3). 

The question of how the relying party knows which identity provider URL to use is open ended.  In a portal scenario, the address might be hard wired, pointing to the portal's identity provider.  Or in OpenID, the user manually enters information that can be used to figure out the URL of the identity provider (see the associated dangers).

The next question is, “How does the identity provider return the response to the relying party?”  As you might guess, the same redirection mechanism is used again in 4), but this time the identity provider fills out the Location header with the URL of the relying party, and the goop is the identity information required by the RP.  As shown in 5), the browser responds to this redirection information by obediently posting back to the relying party.

Note that all of this can occur without the user being aware that anything has happened or having to take any action.  For example, the user might have a cookie that identifies her to her identity provider.  Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by.  (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on — trust us…)

Since the identity provider is tasked with telling the browser where to send the response, it MUST know what relying party you are visiting.  Because it fabricates the returned identity token, it MUST know all the contents of that token.

So, returning to the axes for linkability that we set up in Evolving Technology for Better Privacy, we see that from an identity point of view, the identity provider “sees all” – without the requirement for any collusion.  Knowing each other's identity, the relying party and the identity provider can, in the absence of appropriate policy and suitable auditing, exchange any information they want, either through the redirection channel, or through a “back channel” that dispenses with the user and her browser altogether. 

In fact all versions of SAML include an “artifact” binding intended to facilitate this.  The intention of this mechanism is that only a “handle” need be exchanged through the browser redirection channel, with the assumption that the IP and RP can then hook up and use the handle to “collaborate” about the user without her participation.

In considering the use cases for which SAML was designed, it is important to remember that redirection was not originally designed to put the “user at the center”, but rather was “intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent… for example, if the communicating parties do not share a direct path of communication.”  In other words, an IP/RP collaboration use case.

As Paul Masden reminded us in a recent comment, SAML 2.0 introduced a new element called RelayState that provides another means for synchronizing or exchanging information between the identity provider and the relying party; again, this demonstrates the great amount of trust a user must place in a SAML identity provider.

There are other SAML bindings that vary slightly from the redirect binding described above (for example, there is an HTTP POST binding that gets around the payload size limitations involved with the redirected GET, as Pat Paterson has pointed out).  But nothing changes in terms of the big picture.  In general, we can say that the redirection protocols promote much greater visibility of the IP on the RPs than was the case with X.509. 

I certainly do not see this as all bad.  It can be useful in many cases – for example when you would like your financial institution to verify the identity of a commercial site before you release funds to it.  But the important point is this:  the protocol pattern is only appropriate for a certain set of use cases, reminding us why we need to move towards a multi-technology metasystem. 

It is possible to use the same SAML payloads in more privacy-protecting ways by using a different wire protocol and putting more intelligence and control on the client.  This is the case for CardSpace in non-auditing mode, and Conor Cahor points out that SAML's Enhanced Client or Proxy (ECP) Profile has similar goals.  Privacy is one of the important reasons why evolving towards an “active client” has advantages.

You might ask why, given the greater visibility of IP on RP, I didn't put the redirection protocols at the extreme left of my identity technology privacy spectrum.  The reason is that the probability of RP/RP collusion CAN be greatly reduced when compared to X.509 certificates, as I will show next.

What does the identity provider know?

I appreciate the correction by Irving Reid in a posting called What did the identity provider know?

…And when did it know it?

Kim Cameron sums up the reasons why we need to understand the technical possibilities for how digital identity information can affect privacy; in short, we can’t make good policy if we don’t know how this stuff actually works.

But I want to call out one assertion he (and he’s not the only one) makes:

 First, part of what becomes evident is that with browser-based technologies like Liberty, WS-Federation and OpenID,  NO collusion is actually necessary for the identity provider to “see everything”.

The identity provider most certainly does not “see everything”. The IP sees which RPs you initiate sessions with and, depending on configuration, has some indication of how long those sessions last. Granted, that is *a lot* of information, but it’s far from “everything”. The IP must collude with the RPs to get any information about what you did at the RP during the session.

Completely right. I'll try to make this clearer as I go on. Without collusion, the IP doesn't know how the user actually behaved while at the RP.  I was too focussed on the “identity channel”, thinking about the fact that the IP knows times, what RPs were visited, and what claims were released for each particular user to each RP.

The European e-Identity Conference

I don't often mention my speaking agenda, but next week I'll be giving the opening keynote at a conference in Paris that looks like a great opportunity to exchange information.  It is hosted by EEMA (which has morphed into the European Association for eIdentity and Security) and ENISA (the European Network and Information Security Agency).  If you've been sitting on the fence, it looks like the conference has really come together. Here's the program.

One track is called “managing identity” (in the largest sense) with presentations about architecture and application development approaches by Siemens, SEALED and SAP.  It includes roundtables on interoperability, security-identity interfacing and SOA. 

The other track is on “social networking” with presentations on Netlog and Facebook, and a fascinating series of roundtables on a nice taxonomy of reputation issues.

And that's just day one!  Day two is huge.