[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Web ID as passwordless authentication for debian web services



Wouter Verhelst <wouter@debian.org> writes:
> On 16-05-13 17:42, Russ Allbery wrote:

>> You could, in theory, switch to DNSSEC, but now you're just replacing
>> one CA cartel with another.

> Except that with DNSSEC (and DANE), the number of people you have to
> trust is much smaller.

Right, it depends on what your risk model is.  If you're defending against
incompetence and/or commercial greed overriding security practices, DNSSEC
looks a lot more appealing than the CA cartel, since there isn't the same
level of commercial incentive to cut corners and do a crappy job (there's
some, but it's not as bad).  But if you're defending against governments,
DNSSEC isn't going to help.  I think it's best to assume that both the US
and Chinese governments, at least, can make DNSSEC say what they want it
to if they ever needed to.

The government risk case may not be of interest, and it is, in general,
quite difficult to defend against governments (usually the best that you
can hope for is knowledge you've been compromised, and even that is fairly
difficult even in the US with National Security Letters).  The problem
with authentication systems, though, is like the problem with
cryptosystems: vulnerabilities never get better.  They only get worse.  So
there's some reluctance within the field to adopt a new authentication
system with known attack vulnerabilities even if one thinks one can live
with the current vulnerability.  It usually means that vulnerability is
going to get worse over time.

The basic problem is that you have to trust someone, and all the parties
involved in the authentication transaction (which includes the metadata
host in the WebID model) have to agree on who they're going to trust.
Obviously, the simplest scenario (and the one used essentially exclusively
within large institutions) is for all parties to agree on a trusted
central authentication authority such as, for example, an internal CA run
according to known practices.  The whole point of distributed
authentication is to eliminate that single point of central authority, but
as a result the trust problem becomes almost intractably difficult.

The most secure distributed authentication trust system is for every party
to maintain explicit whitelists of who they trust based on personal
information and their own policies (think GnuPG signature trust, for
example).  It's also by far the most difficult to maintain and has
significant interoperability issues.

So, again, it comes down to what problem we're trying to solve.  If the
problem is just how do we authenticate Debian contributors to Debian
systems, then we're actually in the institutional case and we don't have
to trust anyone outside the project: we can deploy our own central
authentication system -- a CA, a Kerberos KDC, or any other authentication
system of choice -- and have all parties trust it, and that will be much
simpler and much easier to analyze than any of the distributed models.
Once we have our own CA, we could of course do secure WebID if we wanted
to using that CA (modulo the inherent dubiousness of substituting endpoint
authentication for user authentication), but it's not clear to me why we'd
bother as opposed to just issuing client X.509 certificates with the
metadata already included.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: