[OpenID] Association poisoning

[Allen Tom]

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 <mailto: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>
>     [mailto: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
>
>      
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20090309/1cc635c3/attachment-0002.htm>