A quest for login systems

Guido Witmond <[email protected]> Wed, 8 Feb 2017 21:51:27 +0100
Newsgroups	gmane.comp.mozilla.security
Message-ID	<[email protected]>
Dear Mozillians,


(If this is to the wrong list, please point me to a better place.)


I saw the announcement for KaiRo's talk on his Persona replacement at
Fosdem. He's built a Oauth server to fill the gap after Persona shut
down. A I'd like to offer my vision for an authentication system that
offers security, privacy, anonimity as well as community building and
MitM-protection. Above all, all the cryptography this needs is invisible
for the user. It just works without difficult questions.


I'll start with the basics of a user creating an account at a site in a
secure and anonymous way. Later I'll describe how I foresee
community-building on top of the basic authentication layer.


Basic authentication layer

Requirements:

1. user can create an account at a site where he had no account before;

2. user remains anonymous; no email address or other personal
identifying are needed to create the account;

3. each account is a new - independent - identity. Sites cannot track a
user between sites without consent of the user. Even two accounts at the
same site are independent. There is no 'single identity' as with
federated systems;

4. an account is an agreement between site and user only, no 3rd parties
are involved;

5. all communications are encrypted and authenticated before sensitive
data is transmitted.


How it works:

A. Each site runs their own Certificate Authority. It signs the server
certificates for the web site and it will sign the client certificates
for it users when they request for one. The CA never sings any other
site's server certificates. The site and the user authenticate against
the same CA.

B. The site publishes the sites A(ddress) and DANE records in DNS. Then
the site owner enables DNSSEC on the domain. DNSSEC forms a tamper-proof
channel to transfer data from domain owners to the world. It lets the
user agent (browser) know for sure that data it receives are indeed the
data that the site-owner publishes, otherwise the signatures don't match.

C. With both the address and the Root-certificate tied to the domain
name, the browser has everything it needs to validate that is is
connected to the correct site. The agent does not have any client
certificates yet, so the user is still logged off (and anonymous). If
the user browses to a section on the site that requires an account, the
site signals that with a WWW-Authenticate header. That triggers the
agent to search it local database for client certificates that are
signed by the same CA as the current server certificate or it triggers
the agent to ask the user if he wishes to create an account.

D. If the user wants to create an account, he comes up with a username,
the part before the @domain.name. The agent performs a Certificate
Signing Request at the site's CA. If the CSR meets the requirements of
the CA, the CA signs a client certificate and returns it - all in the
same transaction. Or the CA rejects the CSR.

E. The agent has the new certificate. it reconnects to the website and
offers the client certificate to the server. The server validates that
it's indeed signed by it's own CA and if so, it learns the chosen
username. The user has an account and is logged in. QED.

F. The agent offers a logout-button. That would stop the agent from
offering the client certificate to the site at subsequent connections.
The site can't know for sure who the connection comes from and has to
treat this connection as not-logged-in.


The protocol is described in more detail on
http://eccentric-authentication.org. With demo's and all.

If you have any questions, feel free to ask.

With regards, Guido Witmond.

_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
signature.asc (application/pgp-signature, 819 B)