W3C home > Mailing lists > Public > public-webid@w3.org > May 2013

Re: WebID discussion in Debian

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 18 May 2013 17:12:56 +0200
Cc: public-webid <public-webid@w3.org>, Jonas Smedegaard <dr@jones.dk>, Russ Allbery <rra@debian.org>
Message-Id: <FB0523AE-CFEC-480C-91FE-89A0E04ABCE1@bblfish.net>
To: Olivier Berger <olivier.berger@it-sudparis.eu>

On 18 May 2013, at 17:04, Olivier Berger <olivier.berger@it-sudparis.eu> wrote:

> Hi.
> Olivier Berger <olivier.berger@it-sudparis.eu> writes:
>> Hi.
>> Jonas Smedegaard <dr@jones.dk> writes:
>>> Debian already has PGP-based WoT.  So question remains: how is WebID 
>>> relevant for *Debian*?
>> For the records, I've provided some feedback about WebID in the
>> debian-devel@ thread (and have as well forwarded a mail by Andrei), that
>> I hope will have provided more useful details to felow Debian project
>> members.
> In the following posts on the Debian list, Russ Allbery has challenged
> the security of WebID + TLS for authentication. 
> Here's below a forward of his post [0], with permission.
> I'd be interested in hearing your thoughts on the security issue he
> highlights (item 4 below). Maybe this is FAQ ? 
> My answer to him [1] was that some signature of the WebID/FOAF document
> may be necessary to ensure some trust in the process.
> I may have overlooked some recent developments of WebID, so some other
> opinions would be interesting on the matter.
> Thanks in advance.
> [0] http://lists.debian.org/debian-devel/2013/05/msg01067.html
> [1] http://lists.debian.org/debian-devel/2013/05/msg01070.html
> ---- Forwarded ----
> obergix@debian.org writes:
>> Russ Allbery <rra@debian.org> writes:
>>> I'd never heard of WebID before this thread, but looking briefly at the
>>> spec, I share Daniel's concerns.  I don't see how this eliminates
>>> reliance on the normal CAs.  You still have to do certificate
>>> validation to be able to trust the link between URL and keypair, and
>>> the WebID protocol provides no way to do that certificate validation
>>> other than the normal CA process (and doesn't provide any alternative
>>> CA).
>> I'm not sure I understand all aspects of the recent evolutions of the
>> WebID auth protocols nor the big picture, but my understanding is that
>> to auth to a server using a WebID (i.e. a URI pointing to a RDF document
>> which declares a SSL cert public key), all that is required is that the
>> connecting client owns the corresponding private key.
> Here's the security problem in a nutshell (since I'm not sure anyone has
> said it outright in this thread): suppose that I am known to a particular
> server as <https://www.eyrie.org/~eagle/personal/id#me>.  Suppose an
> attacker wishes to authenticate as me.  The attacker would do the
> following:
> 1. Generate a new public/private key pair with that URI in the appropriate
>   field so that it looks like a WebID certificate for that URI.
> 2. Set up a web server that serves the appropriate WebID metadata
>   including their new certificate at that URI.
> 3. Visit the server they wish to attack to trigger the metadata request to
>   my identity URI.
> 4. Hijack that metadata identity request so that it goes to their server
>   instead of mine.  This can be done in any number of ways (DNS cache
>   poisoning, compromise of www.eyrie.org, compromise of my account on
>   www.eyrie.org, TCP active MITM, etc.) depending on the situation.

yes, if you have issues with DNS cache poisoning all bets are off, which
is why DNSSEC is extreemly imporant and why the IETF DANE protocol has
a chance of succeeding.

This is why you still need CAs, which though a weak security mechanism
is going to be enough to get us going, while these transitions take place.

I'd be interested to know how far DNSSEC has advanced in the last 4 years.

> The server then retrieves the attacker's WebID document, verifies that the
> certificates match, and allows the attacker into the system as me.
> The only way to prevent this attack in WebID that I see is to either do
> leap-of-faith permanent caching (in other words, any server that I
> authenticate to caches all my cert information and never lets me change it
> subsequently), which is probably an unacceptable loss in functionality, or
> to secure the connection to my identity URI.  If that endpoint is
> compromised, WebID loses in general (and probably can't be expected to
> defend against that).  However, other major authentication systems are at
> least robust against DNS poisoning and TCP MITM.
> The obvious way to authenticate the connection to www.eyrie.org to
> retrieve my metadata is to validate the www.eyrie.org certificate against
> a CA, which is where the CA cartel is reintroduced into the picture.

see Dane.
The other is to build WebIDs on Tor or other systems, but they have far
less deployment. 

Simply put the perfect is the enemy of the good. 

> Please note that 4 is not as difficult as it looks, particularly if one of
> the goals is to allow more ad hoc servers that are possibly mobile, using
> untrusted wireless networks, or the like, rather than hosted in data
> centers with locked-down networks and physical security.
> Put more succinctly, as I understand the protocol, WebID is only as secure
> as the connection from the authenticating server to the metadata URI.

There could be other ways of re-inforcing this, but this is the simplest
protocol and a lot stronger than many other existing ones people constantly

> -- 
> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
> ---- /Forwarded ----
> -- 
> Olivier BERGER 
> http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)

Social Web Architect
Received on Saturday, 18 May 2013 15:13:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:51 UTC