[OpenID] Association poisoning

Mon Mar 9 20:33:44 UTC 2009

I have found that it is necessary, when giving guidance on the
implementation of RPs by developers new to OpenID, to be very explicit about
security considerations. For instance, reminding that they should verify the
signature is important. Some have assumed that the association handle
validates the response because it was negotiated secretly.

--Breno.

On Mon, Mar 9, 2009 at 12:24 PM, Andrew Arnott <andrewarnott at gmail.com>wrote:

> 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
>>
>>
>>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090309/d0c5c288/attachment-0002.htm>