A standard scalable privacy-aware online account system for GNOME

We propose to create an online account identity service for GNOME end users. At the core, this service will act an OpenID provider, as well as a consumer. The account service will be a standard component of the desktop, and applications can assume it exists and use the services its provides.

There is an obvious question:

Why does GNOME need an account service, can't we just require an external OpenID?

The primary reason is simply that while we expect OpenID adoption to increase, at the present time there are simply not enough well-known providers. And more crucially, there are none that we would feel comfortable pointing to as a dependency for all of the people who presently do not have an OpenID. Additionally, the user experience is simply not as good as a default integrated account system.

Design

The account service will run on a cluster of servers, which would be hosted either in GNOME's current infrastructure or in an external host like AWS, depending on which is determined to be better.

Account model

The core of the account model is that ownership of an email address gives access the CreateAccount and ResetAccount privileges in the account system, as well as access to all operations on any GNOME-affiliated services. We might support setting a password for access to the account, but the initial design will not have one. Now, there can be a password involved for private data - it is encrypted on the client before being sent to the server, and typically one will want a password on the private key.

As the above implies, accounts will be named by an email address. When acting as an OpenID provider, a GUID mapping will be used (e.g. http://online.gnome.org/id/hKcbRMYl4vNDqw).

Unlike a traditional web-based system, new accounts will be created through client code.

New Account

1. Client generates a new RSA public/private keypair

2. Client sends a RequestNewAccount request () to the server, server responds with the pair (request id, PNG image). Request id is an integer ID for this session, and PNG image is a reCAPTCHA (http://recaptcha.net/)

3. Client displays a dialog asking for an email address OR OpenID of the account, along with the captcha.
4. User enters email and captcha solution

5. Client sends a NewAccount request to the server, composed of the 4-tuple (request id, email/OID, public key, captcha solution)

6. Server recieves request; First, if the (request id, captcha solution) pair is invalid, the request is rejected.
7. If the account is based on an email address, client checks email, and clicks on verification link (over SSL)
8. If the account is based on an OpenID, server goes through OpenID verification process
9. Server finishes account creation process; on the server, we store the 3-tuple (email address, public key, client secret)
10. Server sets cookie on the client side which says this account is valid and logged in. This cookie is described below.
11. Client detects cookie change, and now asks for a password
12. Client sets password on private key and saves locally

Now, the problem with private keys (and passwords) is - what happens when one loses them? We would like for the desktop to have an integrated backup system; for example, when one plugs in a USB key, we offer to use it for backup, and the private key is by default backed up onto it. However, we still need to accomodate the possibility of losing the key.

Reset Account

1. Client sends a ResetAccount request to the server, composed of the 1-tuple (email)

2. Server sends a verification link to that email address
3. Client clicks on link, sees confirmation web page where account data can be downloaded locally (and deleted from the server if desired)
4. Client proceeds with New Account process as if the old account had never existed

Note that because the old data has been encrypted, the server cannot give it to the client. It is lost.

Services

Now, the proposed account system is just that - an account system. It does not itself provide other services that might be desired, such as data storage, XMPP, NAT punching, etc. The account system is designed to accomodate two kinds of service; First, services which are part of GNOME. Second, "third party" services that might wish to make use of GNOME data, such as GGZ.

GNOME-hosted services

An example hosted service would be online data (key/value) storage. The basic idea is that all of the GNOME services have a full trust relationship, even though they may be in different data centers or administered by separate groups. This trust relationship is expressed as a shared secret between the servers, and a cookie on the client.

Client cookie

The client cookie is a time-limited (probably on the order of 3 months) ticket granting access to any GNOME online services. It is a 4-tuple (id, creation time, client secret, signature). The signature is SHA256(id, creation time, client secret, server secret). The client secret is a random token known only to the client and server. This cookie has a subset called the "public auth cookie", which is the 3-tuple (id, creation time, signature).

Let's assume that the protocol for interacting with the online storage service is HTTP requests. Then, to store a new value, the process might look like this:

1. Client checks for the existence of the "login cookie", determines we're logged in

2. Client decides to send a new Tomboy note to the online storage server, and constructs a StoreValue request, composed of the 4-tuple (key, encrypted value, public auth cookie, signature). This signature is SHA256(key, encrypted value, public auth cookie).

3. Storage server checks the public auth cookie components against its secret, and decides whether or not to allow the request

This proposed protocol as described is vulnerable to replay attacks, but it illustrates the core idea of how the client and server authentication can work. The replay attack problem could be solved by using SSL or nonce values.