Re: Web ID as passwordless authentication for debian web services
Jonas Smedegaard <dr@jones.dk> writes:
> Quoting Russ Allbery (2013-05-16 17:42:20)
>> Jonas Smedegaard <dr@jones.dk> writes:
>>> This seems similar as WebID: In principle ties to HTTPS - and
>>> therefore the CA cartel - is only optional (other URIs than http ones
>>> suffice). In reality alternatives to HTTP(S) is work in progress.
> First of all: Thanks for your quite easy to follow
> explanation/reasoning!
Thanks -- I just hope I'm not projecting false confidence when I don't
actually know what I'm talking about! :) This should all come with the
caveat that while I've worked on authentication systems for some years,
I've only done a cursory evaluation of WebID, and there may be solutions
to the weaknesses that I was glimpsing.
>> Changing the protocol doesn't help you get away from the CA
>> dependency. The reason why there's a CA dependency is not because it
>> happens to use the HTTPS protocol. It's because you have to
>> authenticate the provider of identity data (the other end of the URI,
>> whatever it may be) or you're vulnerable to having the attacker
>> intercept your query and supply whatever data they want. There's no
>> way around that.
> I believe that with WebID I can get rid of the CA *cartel* while still
> reliably using TLS: By using a server cert from same key material as a
> PGP key, I can (contrary to a self-signed cert) verify that the cert is
> not being handed by a man in the middle (e.g. using Monkeysphere).
Sure, but if you have control over the server certificate and are tying
the server certificate to the user certificate via some mechanism like
Monkeysphere, why do the whole indirection dance through a URI at all? At
that point, you have all the tools you need to just validate the user
certificate directly, at which point you can just put all the metadata
directly in the user's public certificate and be done with it. No third
party metadata provider is required.
The reason for the WebID indirection, as I understand it, is that the
server who is trying to authenticate the user has no way of validating the
authenticity of the presented public certificate. Therefore, the web
server reads a URI out of the metadata of the certificate and retrieves
that URI, confirming that the resource at that URI includes certificate
data that matches the presented certificate. This operation verifies the
binding between the URI and the certificate and allows the server to then
trust that certificate as valid authentication for the user identified by
that URI *provided that* the server can verify the URI endpoint
certificate.
The point is to shift the trust point to the URI endpoint validation
instead of the user validation under the assumption that you have some
existing mechanism to validate URI endpoints.
If introduce Monkeysphere to do the URI endpoint verification, it seems to
me like you could just as easily introduce Monkeysphere to do the user
certificate verification directly, thus removing the need to introduce a
third party metadata provider.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: