[OpenID] Association poisoning

[Andrew Arnott]

A living security document?  Awesome!
--
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 Mon, Mar 9, 2009 at 11:55 AM, Allen Tom <atom at yahoo-inc.com> wrote:

>  Andrew - thanks for documenting this potential security issue that RP
> library developers must keep in mind when storing associations. As far as I
> can tell, the OpenID 2.0 spec does not mention that RPs must key the
> association with the OP-endpoint, although fortunately it appears that libs
> already do this.
>
> The future OpenID 2.1 spec will contain a pointer to a living security
> document which will definitely mention this issue.
>
> Thanks
> Allen
>
>
>
> Andrew Arnott wrote:
>
> 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
>>
>>
>>
>
>  ------------------------------
> _______________________________________________
> general mailing listgeneral at openid.nethttp://openid.net/mailman/listinfo/general
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090309/6bc7466e/attachment-0002.htm>