Clarification

In response to my post earlier today on some OpenID providers who did not follow proper procedures to recover from a bug in Debian Linux, a reader wrote:

 

“You state that users who authenticated to the OpenID provider using an Information Card would not have their credentials stolen.   I assume that cracking the provider cert would allow the bad guys to tease a password out of a user, and that InformationCards require a more secure handshake than just establishing a secure channel with a cert. But it still seems that if the bad guys went to the effort of implementing the handshake, they could fool CardSpace as well. Why does that not expose the users credentials?

 

I'll try to be be more precise.  I should have stayed away from the word “credential”.  It confused the issue.

 

Why?  There are two different things involved here that people call “credentials”.  One is the “credential” used when a user authenticates to an OpenID provider.  To avoid the “credential” word, I'll call this a “primordial” claim: a password or a key that isn't based on anything else, the “first mover” in the authentication chain.

 

The other thing some call a “credential” is the payload produced by the OpenID provider and sent to the relying party.  At the minimum this payload asserts that a user has a given OpenID URL.  Using various extensions, it might say more – passing along the user's email address for instance.  So I'll call these “substantive” claims – claims that are issued by an identity provider and have content.  This differentiates them from primordial ones.

 

With this vocabulary I can express my thoughts more clearly.  By using a self-issued Information card like I employ with my OpenID provider –  which is based on strong public key cryptography – we make it impossible to steal the primordial claim using the attack described.  That is because the secret is never released, even to the legitimate provider.  A proof is calculated and sent – nothing more.

 

But let's be clear:  protecting the primordial claim this way doesn't prevent a rogue identity provider who has guessed the key of a legitimate provider – and poisoned DNS  – from tricking a relying party that depends on its substantitve claim.   Once it has the legitimate provider's key, it can “be” the legitimate provider.  The Debian Linux bug made it really easy to guess the legitimate provider's key.

 

Such a “lucky” rogue provider has “obtained” the legitimate provider's keys.  It can then “manufacture” substantive claims that the legitimate provider would normally only issue for the appropriate individual.  It's like the difference between stealing someone's credit card, and stealing a machine that can manufacture a duplicate of their credit card – and many others as well. 

 

So my point is that using Information Cards would have protected the primordial claim from the vulnerability described.  It would have prevented the user's keys from being stolen and reused.  But It would not have prevented the attack on the substantive claim even in the case of PKI, SAML or WS-Federation.  A weak key is a weak key.

 

The recently publicised wide-scale DNS-poisoning exploits do underline the fact that OpenID isn't currently appropriate for high value resources.  As I explained in more detail here back in February:

 

My view is simple.  OpenID is not a panacea.  Its unique power stems from the way it leverages DNS – but this same framework sets limits on its potential uses.  Above all, it is an important addition to the spectrum of technologies we call the Identity Metasystem, since it facilitates integration of the “long tail” of web sites into an emerging identity framework. 

 

Published by

Kim Cameron

Work on identity.