[OpenID] How to handle byzantine failure with openid.

Lukas Rosenstock lukas.rosenstock at identity20.eu
Thu Aug 30 16:41:41 UTC 2007


Hello!
I haven't thoroughly read all details on what Askemos is about, although  
this project seems quite interesting to me.

The idea how OpenID confirms that a user controls a certain URL is that  
only the user in control can place a link to his chosen OpenID server,  
which, of course, a server administrator could do, too. The user needs to  
trust his provider, because the provider has no problem to use his user's  
identity - as email server administrators have access to their user's  
inbox folders! This is the tradeoff in security and privacy that makes  
OpenID so lightweight and easy to use.

Through the use of XRDS files ("Yadis"), it is possible to associate  
multiple servers with one URL. The intended use was to give these servers  
priority values so that if the primary server is down, the relying party  
can check with another server. For applications that need high security it  
would be no problem to check *every* server in that document and require  
that, for example, there are at least three or four of them whose IP  
addresses are in different class A networks. Still, the identity URL  
itself that hosts the XRDS document is a SPOF because an attacker could  
replace all servers with his own - if he controls a bot network with hosts  
on different networks ...
The list of providers could also be sent as an InfoCard of the XRDS  
document could be signed - which is, even put apart from Askemos, quite a  
good idea ...

The other use case could be solved by DNS - resolving the same provider  
domain to different servers, but this might cause problems with SSL  
certificates, as you said. I'm not an expert on that, maybe someone else  
can help you with this.

Regards (und freundliche Grüße),
  Lukas Rosenstock

Am 29.08.2007, 23:25 Uhr, schrieb Jörg F. Wittenberger  
<Joerg.Wittenberger at softeyes.net>:

> Hello all,
>
> these days I considered to implement OpenID support for Askemos
> <http://www.askemos.org>.
>
> To my current understanding the spec appears to be underspecified.  Now
> I contemplate about solutions and/or seek advice of someone OpenID
> wizard on reading the hairy details of the spec which I missed.
>
> So far I understand OpenID is about users proofing to each other, that
> the individual controls a URL. OpenID does not specify how the users
> ensure that they control the URL.
>
> In fact most users don't do that at all: The URL is usually hosted at
> some web server and at least the administrators of that server farm have
> factually more control of the end users URL than the users themself. Let
> alone that the administrators often enough don't know how little of
> their own control is left over, when intruders evaded the servers.
>
> Askemos empowers users to factually own and control their URL's in the
> presence of byzantine failure of their web host providers as long as the
> majority of servers doesn't fail at once.
>
> So it looks as if we, the Askemos developers, need to support at least
> Identity Provider service and maybe Relying Party support. Let's see:
>
> == As Relying Party
> === The Problem
> As a relying party, our Askemos servers would need - as the name
> suggests - to rely on a remote identity provider's idea of the identity
> of the user.
>
> However the OpenID specs eventually rely on a single remote server,
> don't they?  Doing so would introduce a remote single point of failure
> into the Askemos network, which is not acceptable according to the
> Askemos design principles.
>
> Hm, I might drill this hole into private installations if someone needs
> it. But not into the published source.
>
> === Possible Solution
> The specification should require that: when a Claimed Identifier
> resolves to several OP-Local Identifiers (optional if a single OP-Local
> Identifier one resolves via DNS to a set of distinct hosts) then the
> Relying Party MUST NOT rely on the authentication until it has verified
> with the majority of those OpenID Providers the Identifier resolved to.
>
> Would this be reasonable?
>
> == As Identity Provider
>
> The situation is better as a OpenID Identity Provider (OP).
>
> Using OP-Local Identifiers, users can point Relying Parties via several
> network paths particular mirror copies of the users identity. However
> that's inconvenient and right now I'm not sure that browsers will accept
> multiple CN attributes in SSL certificates. (This appears to me as the
> only solution if all those OP-Local Identifiers resolve to the same
> place just on different providers. Alls those hosts come under one SSL
> CN but different locations (X509 L-attributes).  I'm in the dark how we
> will have to keep the reference correct, but this seems doable from a
> birds point of view.
>
> But: At least when the OP Endpoint URL resolves via DNS to several A
> records, the OpenID specification could suggest on the handling
> association requests. Once the User-Agent has associated with a OP via a
> certain DNS address it should stick to it with all further
> authentication requests for that realm. (Otherwise most authentication
> requests will fail, since the other copies of the OP don't share the
> secret the one OP copy shared with the RP -- or should we share those
> secrets? ;-) No kidding, I assume there is no sharing of RP/OP shared
> secrets among several OP's intented.)
>
> Thanks for your replies.
>
> /Joerg
>
> Note: I'll archive the essence of your replies here:
> http://www.askemos.org/A231f1a67e1aa44d0ef613c02e1db0baa
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general



-- 
Lukas Rosenstock
Identity 2.0 Europe :: http://identity20.eu/



More information about the general mailing list