Re: WebID as passwordless authentication for debian web services
Olivier Berger <olivier.berger@it-sudparis.eu> writes:
> 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).
I'm happy for anything I wrote on this thread to be forwarded to anyone
who is interested, but I'm afraid I don't have time at the moment to
follow another mailing list or get too much deeper into the discussion
than I have already, sadly.
>> 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...
OpenID and OAuth are similarly dependent on CA authorities to verify the
connections between endpoints. (Well, I should be somewhat less general:
OAuth can mean a lot of different things, and I think there are some token
types that can do mutual auth. But the normal bearer token implementation
that I'm familiar with assumes a typical TLS security model with CA
validation of certificates.)
Of course, anything that uses CAs can be made to use a private CA
infrastructure that can be trusted, or use some other certificate
distribution protocol. For example, SAML also uses X.509 for security,
but the large SAML federations, such as most Shibboleth installations,
have mechanisms for distributing federation metadata that contains the
certificates, so they don't have to trust any external CA authority and
only have to secure the metadata distribution process. The same could be
done with WebID in theory, although I think the coordination required is
contrary to some of the goals around loose coupling.
> 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.
Oh, absolutely. If you are in a position to verify PPG signatures from
the user, you can of course use PGP as the authentication method, at which
point you don't need to trust anything other than PGP. The problem, of
course, is that this too just moves the authentication problem, this time
to the PGP world. You still need to establish the trust chain, since
anyone can make a GnuPG key claiming to be for a particular person.
(Someone created a bogus key for me, for example.)
This is, as I understand it, what Monkeysphere does: bridge the PGP web of
trust into other authentication systems and allow them to rely on the PGP
web of trust for authentication data.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: