OSIS I4 Wiki is coming up

I am pleasantly surprised that the I4 wiki is up. Well, I guess, Pam is still polishing it. That must be the reason we haven't seen an anouncement. Anyway; thanks Pamela, great work already.

Here is a table I compiled from the last interops feature tables. The new wiki will probably produce something similar automatically. Perhaps not with this eye-hurting colors.And there will be much more feature tests...

Stealing the Security Token

The Ruhr Uni Bochum claims that they can steal the security token in a CardSpace scenario.... The experts from the German computer magazine c't could not verify the attack...
After reading the paper that describes the attack I must say that I find it very unrealistic.

The attack is described for managed cards. The browser is tricked to load malicious code and then the real RP's code is loaded and presented to the user. The malicious code then loads the root certificate for the malicious RP's SSL certificate and asks the user to install it into the trusted store. This is the biggest assumption in the scenario. Next the user clicks the purple CardSpace icon.

Case 1) Auditing Mode
Assume that CardSpace is tricked to request a token for the malicious RP. When this is the first time CardSpace sees this RP (which is likely) then there might be little CardSpace can do to help the user to recognize the malicious site (because of the installed root certificate). When this is not the first time then CardSpace will warn the user who will probably terminate the transaction.
But who installs a root cert into a trusted store might continue the transaction even when CardSpace raise all flags and blinks all warning lights.

First: The IdP might reject to issue a token to an RP with which it does not have a contract or is outside the (enterprise) circle of trust. Then this attack does not work.
Second: When the IdP issues a token to the malicious RP then that RP can decrypt the token and read the (private) claims. Then it encrypts the assertion for the real RP. The malicious code in the browser (loaded from the malicious server) receives the newly encrypted token and presents it to the form for it to be submitted. The assumption that the malicious code can now reuse the security token to whatever purpose it likes at the RP is not true because the auditing mode restrict its use to the malicious RP.

Case 2) Non-Auditing Mode
Assume the same prerequisites as in case 1. The user is super stupid and the token is stolen and not restricted to the malicious RP. So whenever the real RP expects a security token the malicious code in the browser can provide it.

Do I have to say that an attackers code running inside my browser is probably deadly anyway? Even when the token is not stolen the likelihood that the claims will be a visible part of the "next" page is high, so they can be stolen this way too.

Can't wait to hear what Microsoft writes about this. I had a long busy day and will rethink the whole thing tomorrow.

Free SSL certificate from GoDaddy

Sometimes wishes become true.
I just whined about the cost for certificates but only a few hours later I found this offer from GoDaddy for opensource projects.
Have to wait how complex this gets... Sending the application was easy. Now I am waiting for approval...

openid comments at this blog

I just enabled comments with openid on this blog.

Now you can have your nice "own" id instead of a google account.
Please make sure that you have sxipper installed to warn you about phishing attacks. Does sxipper examine the cert whether I have been at a site already? Have to look into this later...

Have fun with this very useful use of openid. If you are a product manager: While this is useful, please listen to your security guys, before jumping onto the openid train by enabling openid on your valuable site. Better enable information cards.

extended validation certificates

Extended validation certificates are not the cure for all problems.
The Register reports an XSS attack to Paypal.

I think that more than EV certs the identity metasystem needs affordable certificates for all.

openid is toast

Mike (one of those who need no sleep) blogged about Fun Communication's openid idtheft site and I encourage you to read Mike's post and try your personal idtheft immediately.

Back here?! Well, you knew all this already, didn't you?
But seeing it in action is another thing, I guess.

So where does this lead us? Remember the "openid dogfight" from September 2007? I too think that we need a spectrum of solutions. I agree that openid is for when an RP has "trivial" security requirements, but I think that trivial is not easy to define. At first your openid might be good enough for trivial things but its value grows with time. The more you use your openid the more valuable it becomes and then the risk you take by using the openid protocol becomes too great to accept. So let us all improve openid through e.g. PAPE. But why? To end up with another secure and inconvenient system? Thanks, no.

• back channels are bad (privacy, user consent). (SAML artefact)
• browser redirect protocols are bad (phishing). (openid protocol, SAML HTTP redirect binding)

Are CardSpace, Higgins' id selector, DigitalMe and openinfocard the solution? Not yet.
I think that the most important things that the Microsoft's vision of the Identity Metasystem until now has brought us are:

• thinking in claims instead of thinking of "login"
• identified the need for a unified user experience when PII is involved
• a client component to achieve the former two

Paul writes that his sxipper prevented the phish. This is a client component like CardSpace and the other id selectors.
We could integrate openid into the id selector and call it "identity agent" or whatever makes this idea stick. But then... Why use openid at all? This is so close to the origin of the security axis that we would need logarithmic scaling to make it visible.

Let us build this identity agent. Let us integrate openid and passwords into the client, but only as a migration path to a convenient and secure alternative.
Down with browser forms for claims/attributes. The browser is your friend.

Minimal Disclosure Tokens

Kim's presentation is full of nuggets. Minimal disclosure tokens will be part of the future of CardSpace I believe.

Magic Kim

While looking for input why "Claims will change everything" I found this presentation from Kim Cameron on the net.
Yes, we have the "proto-wand" and I want to turn it into our magic wand. I think that this is the true "iCard" and I hope that CardSpace will allow to have the cardstore on a secure mobile device not too far in the future.

Please notice the logo on the phone. It shows the building in which Deutsche Telekom Laboratories reside. My colleague Martin Kurze and I created the Magic Kim and reused our prototype magic wand image there.

CardSpace @ Microsoft 360° Security Days

Microsoft Germany offers the Microsoft 360° Security Days to German speaking architects, project managers and developers. One session for architects and project managers is about Microsoft CardSpace. I really hope this will be an inspiring talk given by a true believer of the claims paradigm.
It's a pity that a participant can not provide her claims by using information cards during registration for the event.
Anyway, I am happy that CardSpace is a topic. We need more events that advocate information cards. Worldwide and in other languages than English too. I hope that Microsoft Germany offers the slides of the session to the public after the event and not only to participants.

Bandit Architecture Goes Mobile

Anders Lundgren from RSA Labs just forwarded me a link to a Nokia research paper that describes an implementation of the Bandit's project architecture on mobile devices.

Too bad my attempts to contact Nokia regarding the Identity Metasystem failed. I tried to contact them right after Catalyst Barcelona but replies remained vague and dried out soon. I think that mobiles are THE target for information cards.
Maybe somebody from Nokia reading identity blogs reads this and we work together?
I think we are operating on common ground to a common goal and will benefit from a cooperation!

People are email addresses. not.

During the Internet Identity Workshop I thought that it might be time to "pretend" to relying parties that I don't have an email address. Some years ago I tried to live without a "C:" partition on a windows systems. I had several versions of Windows installed on different partitions and at some point in time removed the oldest version on C by removing the whole partition. After some time I gave up on this scheme because to many dump scripts and too many dump programmers insisted that either the system is on C or that the program or parts of it are installed on C. If you don't have a C than things start to fail in interesting ways.
Today, I think, that many relying parties (social sites) demand that I have a valid email address. I think that this might be an assumption that is more and more false as "social" people are using the social sites. Or more and more people will have email addresses but will not know that they have one.
So relying on email for "verification" (registration) or credential reset might not be a good idea. More probably the notion of an "account" is wrong to begin with.

IIW2008a Infocard Features

During the OSIS session at IIW2008a we went through all the informationcard related features.

• I3:Information Card Relying Party Features
• I3:Information Card Browser Add-On Features
• I3:Information Card Identity Selector Features
• I3:Information Card Identity Provider Features

We categorized them by priority and maturity.
We identified features that need clarification and features that need (better) tests.
Results will be on the wiki soon.

IIW2008a Tuesday: Openliberty People Service

Asa demoing bootstrapping ID-WSF PP from an OpenID

IIW2008a Monday: Relationship Cards

Drummond Reed demos Relationship Cards with the help of Asa Hardcastle



Asa using his eSissors to cut the relationship.

Demostyle inspired by Made to stick

IIW2008a Monday: Intro

Monday Program

Paul Madsen

Notice the German football trikot

Kaliya, paul, david, pamela

Instant Managed Cards

One of the problems around managed cards is that if they are protected through username and password then the benefit to the user seems not as big as one might expect. The promise to get rid of passwords is not completely fulfilled because now instead of giving a username and passport to a RP I have to give one to the IdP. The user now is disappointed and the product management responsible for the introduction of information cards at the RP is unhappy because the user is disappointed.
Well, the promise was not to get rid of ALL passwords. The promise was to get rid of most passwords. The user has to authenticate to the IdP to get the security token.

CardSpace has alternatives to the username/password authentication at the IdP.

• self issued cards
• X509 certificates
• kerberos

Kerberos is said to be not adaquate for Internet use and should be restricted to Intranet use. Hm.
So that leaves us with self-issued cards and X509 certificates.
Self-issued cards that back a managed cards have their own difficulties. Try to explain to a user that he has to generate a self-issued card, then introduce that card to the IdP before the IdP can issue a managed card backed by this self-issued card. This is just to complicated and if you delete your self-issued card then your managed card is toast. Or if you backup your cards and import the managed card somewhere else but fail to import the self-issued card then that managed card is useless too.
X509 certificates are similar complicated. Where do I get one that is accepted at the IdP? (I am talking about the Internet use-case here, not the corporate use-case)
Well, the mobile operator might deploy one over-the-air and the IdP might accept that. This is a scenario that I like very much, but we have to wait whether mobile operators will do this or not.

Anyway, how do we solve the problem? I suggest that we simply put the username/password into the managed card's private data section. This might be optionally PIN protected or the whole cardstore might be protected by "something I know/have/are".
The user experience should be that the card is imported and that the authentication to the IdP is preformed by the identity selector (preferably without user interaction) when the card is used.

First I thought that we should put the self-issued card or the X509 certificate into the managed card's private data and that that should be used to authenticate to the IdP. The needed keypair should be generated on the fly by the identity selector when the managed card is retrieved from the IdP (We could use a RST to push the public part of the keypair to the IdP and retrieve the managed as a security token in the RSTR).
But now I think that putting the username/password into the managed card's private data and use it without user interaction is a valid option if the user consents to it. This is like the "remember this password?" option in Firefox.
Yes, these credentials need to be protected but not necessarily by something the user has to enter when the managed card is used.

To repeat: I think we need a managed card that is easy to deploy and easy to use.
The solution is to put the credentials needed for IdP authentication into the managed card's private data and to deploy these credentials to the IdP in one step.
The username/password does not have to be the same as the initial username/password needed to authenticate to the IdP. I suggest that they should be different. Like the keypair from the self-issued card that is generated on the fly.

The goal is: IdP offers managed card. The user retrieves it and can immediately use it without further dialogs and complicated procedures.
The solution: IdP offers managed card (signifying what authentication method is/are supported). The id selector generated the authentication credentials (random password, keypair in certificate/self-issued card are not really different from each other) and sends them in a RST to the IdP. The managed card is retrieved as the security token from the RSTR.

Alles wird gut.

IIW2008a Monday: <link rel="metadata" ...>

Reading through the proposed topics for IIW2008a I noticed that George Fletcher blogged about something that I want too.
Though calling it Identity Metasystem Markup Language seems a little too big, I think.
Anyway I posted something similar to the osis-general mailing list on May 2nd.

Using <link rel="metadata" ...> to indicate what the RP wants is a good idea, I think. This is very simple and very much simpler than embedded objects.

What I like most about this idea is that we might get rid of any RP login form etc all together. If the browser/UA/client notices this new "link" then it can display a dialog or whatever to the user and there is no need for RP generated login forms. This way we have a unified user experience at the user's choice.

What we need next: Do the same with privacy statements. There should be a "link" to the privacy statement of the RP (maybe this is part of the metadata already?). The privacy statement should be kind of machine readable too. I want the browser to be able to help the user to make the right decision here. Well, we need much more but this might be a start.

----

This topic is related to "identity selector advertising"... The selector should/could advertise to the RP that it understands to handle "link metadata" and then the RP could avoid sending <object type="application/x-informationcard" ..> because it now knows that the id selector will offer the user the option to send his claims.

easy to impress

Perhaps I am easy to impress or maybe I have a misconception about IP addresses, but I am still impressed by Jurassic ones.

Apple has 17.149.160.10
HP has 15.192.45.21

Everything smaller than 32 is from the Stone Age.
In the era of classless routing this is not that impressive anymore, but still...

openinfocard.org (today) is 68.178.232.100 which is smaller than 128 but nothing to be proud of. And anyway the rule "smaller is bigger" does not count anymore.

And I have to make up my mind what I do with my freshly bought domains. I should have bought a SSL certificate first too. Then I could host the Firefox extensions (openinfocard and CardSpace4Firefox) and have a secure update server... My Minister of Finance will not like this... ;-)

Craig Mundie: Claims, Privacy and Everything

Today I re-viewed the Craig Mundie keynote from the RSA 2008 conference.

Many things were said that I liked:

• Recently, a few weeks ago, we announced that we had acquired Credentica, and their U-Prove technology, which we think is going to be an example of a way to realize this requirement where we can tease apart some of the individual claims around identity or elements of identity and present them individually, and therefore be able to prove certain pieces of information without disclosing too much.
• ...I think on the consumer side there are two things that I hope will come together in a positive way. We put the CardSpace mechanism into Vista as a baby step in a way of introducing a GUI that people would be more familiar with, like they use credit cards and driver's licenses....
• ...more...

It is really good to hear that top management of Microsoft supports all this. Interesting to call CardSpace a "baby step". I am sure that was not intended to downplay the great work the CardSpace team did but to acknowledge how much work is still to do to create the need-to-know Internet.

There is one thing though where Mr. Mundie fell back into pre-"beyond fear" thinking. He gave the following example:
"CRAIG MUNDIE: I think that's true, and certainly this comes down in a sense again to the choice question, not just the choice to participate but you have to be able to identify the regions or the zones, if you will, of the Internet where the ground rules are complete anonymity, and likewise society I think will increasingly demand that they know that there are certain places where identities are really well known.

So, for example, if you're putting together an online playground for young school kids, you really want to know about all the identities of the people who have access to that. You don't want people lurking in your playground if you don't really know who they are in a reliable fashion.

So, I think that much as happens in the physical world, we will cone to understand that there are certain places where you're not expected to have to be identified, that you enjoy the ability to move around."

This example is not a good one. In the physical world I don't know what the identities of the fellow parents on the playground are and I think that the identity of the people in an online playground does not need to be known to the people visiting this online playground either. I think that a "is in custody of a child"-claim would be good enough to be acceptable on the online playground (or an "is a child"-claim). Sure there are differences between a physical playground and an online playground but throwing liberty out of the window when fear is involved happens just too often.

I would do Mr. Mundie wrong if I claimed that he meant to say "Society needs Microsoft CardSpace to protect our children". I apologize for even writing that conceived allegation. "Child abuse", "terrorism" trigger peoples fears and, hop, out goes our liberty.

That said...
Maybe later we can say: "CardSpace was a small step for Microsoft, but one giant leap for mankind"...

have fun! See you next week at IIW2008a.

Identity Bus round-table

Ripped out of context phrases from this video:

"LDAP is the COBOL of Identity Systems"

"Web-Services can be Hokus-Pokus or they can be usefull."

"Information should decay. Identity Entropy ; Identropy; Claims TTL"