[OpenID] How to handle byzantine failure with openid.

Thu Aug 30 18:02:13 UTC 2007

ok. Lets look at the rationale. Its addressing issues that are core to OpenID.

1. The class of assurance that OpenID aims for is limited by the security enforcing features it depends upon. 

2. And, as you say, it depends upon secure name resolution (what OpenID calls discovery, pre or post authentication) 

This depedency contrasts with other schemes which have the assurance founded on secure key distribution (NSA doctrine), or secure relaying (NATO doctrine, GSM doctrine, Cardspace doctrine?).

In the case that XRDs are managed by the user, the choice of XRDS over HTML changes nothing. Your superadmin at the hosting site can alter a static XRDS file like he can the HTML file. 

Whether its HTML or XRDS, the doctrine of secure name resolution requires that the name server is secure. This will occur in OpenID only when either (a) the user controls the "name/web" server by running his own web server, or (b) a trusted proxy is used for name resolution (the XDI.org approach).

Scatter gun confidence building is not considered an appropriate means to fix the underlying assurance problem (tho this is a quasi-religious cliam, on my part). It is appropriate to help deal with subtler issues addressing the need for social engineering countermeasures. 

If a high-clearance general asks you a similarly high-clearance FBI case officer for the sex life details of a congressman the executive branch doesnt like, DO ASK  YOUSELF IF A GENERAL OF A TANK DIVISION IS LIKELY TO REALLY NEED IT ? IS SOMEONE HOLDING A GUN TO THE GENERAL'S HEAD, WHILE CALLING FROM HIS OVERRUN TANK? Do asess a confidence factor in the authentication and authorization data, by taking into consideration the wider context.

Counter arguments welcome.

________________________________

From: general-bounces at openid.net on behalf of Lukas Rosenstock
Sent: Thu 8/30/2007 9:41 AM
To: Jörg F. Wittenberger; general at openid.net
Subject: Re: [OpenID] How to handle byzantine failure with openid.

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