Re: WebID as passwordless authentication for debian web services
Hi.
Russ Allbery <rra@debian.org> writes:
> obergix@debian.org writes:
>> 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):
May I suggest you forward this to the WebID list so that more informed
experts can react ? This seems a very interesting problem, and certainly
not Debian-related (I could forward your message, but it may be better
if you're posting directly, just let me know).
> 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, the issue is with the trust you can put in the FOAF retrieval, in
the 4th step. Confidence in the "security" of the hosting site for your
FOAF is a key issue.
Note that some WebID implementations scenari make use of relying
parties, and this may get worse here, IIUC :-/
> 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.
>
I wonder how OpenID, for instance, is supposed to resist to such
attacks, in comparison...
> 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.
>
> 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.
>
I've not though alot about this before, so maybe I'm overlooking other
details, but I think the use of the GPG signature of the FOAF document
may help overcome some of the weaknesses that you explained wrt ensuring
the FOAF retrieved is indeed the one that is supposed to be bound to the
SSL cert.
If you've checked the example I posted earlier today, I have an
accompanying signature file for my FOAF, that can be used by a Debian
server which knows me via the GPG WoT to verify that my FOAF is legit
(provided that my GPG passphrase/private key isn't compromised either
;), and indeed mentions the right cert's public key modulus to be
provided by connecting clients.
Maybe that can guarantee some more robustness for WebID in Debian, or in
the frame of any similar Web of Trust (peered freedomboxes, etc.),
including CA-based infrastuctures...
I think it sounds quite logical to enforce some digital signature of the
FOAF document (not necessarily the server which hosts it), by (at least)
the cert that it points to may be a first step, and maybe by some
authorities, or a GPG signature of a key in WoTs, if one has to build
trust over WebID. Usually, a TLS cert is self signed and may be signed
by CAs, and if we're just extending its meta-data in a Web document
(FOAF), so this Web document needs signature by a traceable chain of
certification.
Again, this deserves examination by WebID experts (which I'm not), IMHO.
Hope this helps.
Best regards,
--
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)
Reply to: