[OpenID] Association poisoning

[Peter Williams]

If it is critical that some security enforcing function is done it must be stated [in open standards communities (*)].

Furthermore the means by which one would detect violation of the control must be normalized (so different libraries don't use different tests  to induce the error state). If there is an error state, the standard should normalize what is done, with the usual conformance rules (SHOULD, MUST, etc).

What we don't want is the that RP website designer has to do any of this ; it has to be addressing by the library/protocol engine delivering a complete set of security enforcing functions. The only thing an app designers has to do is then profile the identifier syntax and the trust model (just like in https). We don't want "special security engineering skills" to be required, merely to addon websso to a website.

--

(*) In some ISO-security/telematic standards produced in the late 1980s, many of the contributing global telco companies would withhold 10% of the scheme from standardization in favor of "implementation knowhow", so standards acted as a barrier to entry. Typically, submarine patents would be being placed - addressing the 10% "effectiveness" areas - to control the competitive phased of the market. It will be interesting to see what the culture is in OpenID too, where one sees such dominance of the movement these days by mega-large companies, who are assuredly patenting away as we speak - given the way the Foundation is setup about patent issues.



From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Andrew Arnott
Sent: Sunday, March 08, 2009 10:39 AM
To: OpenID List
Subject: Re: [OpenID] Association poisoning

Martin,

Yes, that about sums it up.  Since thinking of this potential problem I couldn't find anywhere in the OpenID 2.0 spec that calls out the caution.  If it isn't there, perhaps 2.1 can add it.

As stated in my blog post, I only checked Janrain's ruby library and dotnetopenid.  I haven't checked any other RPs.  I hope that anyone that owns an RP implementation will check for this.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Sun, Mar 8, 2009 at 9:20 AM, Martin Atkins <mart at degeneration.co.uk<mailto:mart at degeneration.co.uk>> wrote:
Andrew Arnott wrote:
If you write an OpenID relying party library or custom implementation, you
might want to review a post I just wrote on a potential security hole I've
never heard anyone else talk about:

http://blog.nerdbank.net/2009/03/openid-association-poisoning.html

So, just to be clear, the flaw here is employing a simple assoc_handle to assoc secret mapping without considering which OP belongs to the assoc_handle?

That is a pretty serious problem. Have you found any RP implementations that *are* vulnerable?

_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090308/6c992cd3/attachment-0002.htm>