Identity

A proposal for release 12.2.0.

We want to build a peer-to-peer network with controlled access. Worse, we want to allow users multiple points of access, like a home computer, office computer or web access from any computer. Further, the software is open source and expected to be customized, possibly corrupted. How are we going to manage this?

User Name

To begin we need some universal identifier for users--two users with the same name on different systems leads to problems eventually. The obvious answer is to use email ids. The big plus here is that emails are easily validated while still offering anonymity. OK, so not everyone wants to make their email id public. Tell them to create another email account--a small price to pay for anonymity!

Password IDs

These days, everyone has too many passwords to keep track of. And while we'd all like to have just one password, that leads to a lot of potential trouble--and who are you going to trust with that password? On the flip side, I think most folk have a small set of passwords. One for home, one for office, one for the bank, one for email, and a few more which are used to access multiple systems of lessor concern.

Now in a peer-to-peer network of both relatively untrusted and trustworthy systems, the problem gets worse. For my local system and a remote system to interoperate, they need to share a password. Let us assume we trust the local system, or the web service we are using to access the p2p network.

To help manage the password mess, lets attach IDs to different categories of passwords. Now we can take advantage of having the same password on multiple computers--they can discover on their own that they have the same password ID for the same user and then cross validate. So, once I log on to the local system, that system can handle the logon for many of the other systems I want to access, transparently. Hey, they can also coordinate password changes for a given password ID which they have cross-validated.

What we have done here is turned a worry, that a system might misuse a password shared by other systems, into a benifit that makes our lives easier. Still we can manage the situation by using multiple password IDs.

Changing Passwords

When you don't have a trusted server that you can count on to always be on-line, changing passwords can be problematic. So for each password Id, we should keep all the old passwords which have not yet expired. Now we can login to systems with the older password and transparently exchange this history of password changes as a means of distributing these changes.

AutoLogin

We can also keep a list of systems we want to log onto automatically on the local system. This will help in distributing passwords, as well as in receiving notifications from our remote systems. Note that we might even allow information transfer even when the user is not logged in. Think of this as an alternative to email. It can be especially helpful for interaction between users in different time zones or with different schedules.

Secure Hash

Secure hashes work like checksums only better, for if the secure hash of two strings is the same you are pretty much assured that those two strings are the same. So I can send the secure hash of a password to another system and it can confirm that the password matches without having to send the password. (Well, it is almost that simple. You better add a timestamp to that password before calculating the secure hash or someone else can just use the secure hash of your password and gain access without needing your password. Just pass the timestamp along with the secure hash and then the receiver can confirm that the timestamp is recent enough to assure that it didn't receive an old message sent by some third party.)

The Data Structures

Each user account is keyed by email id, but also by the secure hash of the email id. The latter is helpful if we want to uniquely identify a user [in a message] without providing an email address to 3rd parties.

A user account can have a registration password. Users can generate a registration password without logging into a given system. The registration password is then sent to the user via email. This password expires after autologin succeeds with another password, and can not be used to log into other systems.

Each user account has multiple password categories, keyed by Password Id.

Each password category has multiple password entries, keyed by the earliest known date of that entry. Each entry contains a password. Note that this isn't the password entered by the user but a hash of what the user entered. This then is treated internally as "the password" and when we talk of a hash of the password we really mean a hash of the hash of the password as entered by the user.

Note that passwords must be preserved by dump for migration purposes. But they should not be generally accessible, as otherwise they can be employed by users with corrupted systems for impersonation.

A user account also has a record of every system that has been logged into, together with the matching password ids and passwords. Auto login then is only used when for some reason the remote system rejects the given password.

General Message Structure

Once a user is logged into a remote system, this general message structure can be used:

1. email id hash - used to identify a virtual channel
2. password id - used to identify which group of passwords is used in this message
3. password hash - used to identify which password is used in this message
4. timestamp
5. message hash - built by combining the password, timestamp and message body
6. message body

Auto Login Protocol

Here is the protocol used between a local system (where the login is initiated) and a remote system:

1. The local system initiates autologin by sending:
- "AL1"
- email id hash

2. The remote system responds to an AL1 message with:
- "AL2"
- email id hash
- a list of password ids

3. The local system responds to an AL2 message with:
- "AL3"
- email id hash
- timestamp
- random number
- for each matching password id:
- - the password id
- - for each password:
- - - secure hash of (the password + timestamp + random number + password date)
- - - password date

4. On receipt of an AL3 message the password date of all matching passwords is updated by the remote system if the password date received is earlier than the date already known. The remote system then responds with:
- "AL4"
- email id hash
- timestamp
- random number which differs from the AL3 random number
- for each password id with a matching password:
- - the password id
- - for each matching password:
- - - secure hash of (the password + timestamp + random number + password date)
- - - password date

Note that a registration password can be used when entered by the user. It has a password of registration and is removed from both the local and remote system once autologin succeeds with another password id. (Registration passwords are assumed to be only for the remote system, so they are not stored on the local system. And they are only used to add password ids and/or passwords to a remote system.

Registration Requests

When auto login fails, the user can add password ids and passwords to the local system. If auto login still fails, the user can request that the remote system send an email containing a registration password and then add password ids and passwords using the registration password.

Adding Password Ids and Passwords

Adding password ids and password is done using a general message structure. Note that this is the only activity which uses a registration password. Passwords in the body of the message are encrypted using the password in the header of the message.

This occurs automatically after autologin (and bi-directionally) for all matching password ids to supply the missing passwords.

This process occurs as well after a new password has been added, distributing the password to all systems with matching password ids.

A user request is required however to add a new password id to a remote system.