[OpenID] Association poisoning

Andrew Arnott andrewarnott at gmail.com
Sun Mar 8 18:08:45 UTC 2009


Ok, how about this:

A relying party MUST key an association using its OP Endpoint and
association handle  together for both storage and lookup.

--
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:55 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  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>
> 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
> http://openid.net/mailman/listinfo/general
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090308/27e5b2bb/attachment-0002.htm>


More information about the general mailing list