Users forget passwords all the time. This leads to
an email sent to an address whose password you ought to
have. If not, you may cascade back into your online
history, ending in your dial-in modem account with an
ISP that does not exist anymore.
Something is wrong here...
The central problem in all this is that your online presence builds on something else, as it needs to start somewhere. In our project we tend to think of this as bootstrapping your online presence, starting with a form of authentication that you want to continue to exist. And to be honest, going back in time is not helpful to get back control. The systems were less secure and your memory about the credentials likely gets foggier.
Related to this is the problem that people fall off the net for a variety of reasons, and their presence may need to be changed by others. This applies to people are deceased, to employees who loose their jobs and to companies that are sold or go bankrupt.
Placing you at the Helm
Every entry point to online resources (like email addresses and domain names) is an important point to regulate your continued access. And doing this properly clearly needs more fantasy than the current password-with-email-fallback.
We developed the idea of ARPA2 Helm, and want to place you at that Helm. Since it makes sense at any point where you take control over a resource, it should be used for domains but also for delegated subdomains, for email addresses of individual members (but not their personal aliases), and within groups each member counts as an access point to guard. There are many places where users hop into online resources and could make good use of an ARPA2 Helm to stay in control.
In essence, an ARPA2 Helm just lists online resources and provides buttons to control them (add new ones, remove current ones and so on). And ways of using the resources as normal users, of course. You only need to login, and the authenticated identity that this yields allows the ARPA2 Helm to locate all the items that you can control.
Flying in from Different Angles
The trick of the ARPA2 Helm is that it allows you to connect more than one login identity to an online resource. And each of these identities is a separate possibility to authenticated. So instead of winding back time, you can have parallel options. The underlying identities are only used for authentication to the ARPA2 Helm; they are not shown to the outside world. They would rather be rewritten to a canonical identity for the online resource, for example an admin@ address for a domain name.
This means that really any identity will do, so the concept of Realm Crossover can be used to allow remote identities to authenticate for accessing the Helm. This gives you many angles of flight to get on board, and they can be completely independent.
Among the actions you can do in the Helm is the management of other identities that can be used to access the online resources. Forgot one? Remove it. And add another to replace it. As long as you have at least one entry point you stay in control.
Finding a Wingman
You should consider printing a few of the identities (and their matching credentials) on paper, and store them in a sealed envelope. Put them in book covers or vaults, whichever suits your requirements.
Another useful idea is handing over identity/credential pairs to friends, collegues or, for the most stringent requirements, an acting lawyer or notary official. In all cases the purpose is the same, namely to serve as a backup in situations of take-over/bankrupty or disease/death. And remember, if you and your friend fall in disgrace you can easily remove their access and substitute another; much simpler than getting back your home key from them.
Unlimited Boarding Passes
You still need a way to authenticate. But you only need to authenticate; there is no communication requirement. Indeed, with Realm Crossover this is possible, as we designed for SASL as well as Kerberos.
Because only authentication is required, and because the identity is not pubished, a long random code suffices as a user identity. Mix that with a long-term key in a server to compute a password. Reconstructing the password is easy, and requires no storage but for the key. Plus, sufficient netropy can be used to achieve a much better security level than for human-made passwords; 128 bit and 256 bit security levels are achievable. The one design constraint that is required for this setup is that nothing allows a username-to-password lookup for outsiders. With a randomly generated user identity and further only login attempts this does not happen.
Creation of such light-weight identities is trivial, because they have no value. It's like opening an empty bank account; authentication to such an account is not an issue. The moment you tell people to pay you into it there is a value, but not before. Likewise, a fresh authenticated identity is of no value, but that changes as soon as the identity is attached to online resources, as it is done in the ARPA2 Helm.
So, a fresh identity can be produced and provided to any requester without any concern. The password will protect a value, but only after the recipient allows it.
This means that we can construct something that we call Helm Arbitrary Access Node, or HAAN for short. It is incredibly light-weight to run a HAAN Service on a dedicated (sub)domain, and the most reliable service providers can be very small organisations that are simply careful about longevity and key management. A few of these suffice to give you a maximum of control over your online service through the Helm.
SASL Extensions
SASL mechanisms habitually lookup passwords for authenticating users; instead of accessing a database, passwords might be derived with a key computation that incorporates that entropy of a username. The result is usable with any SASL mechanism that requests a password for a given username, which gives a good range of choice. Making this available under Realm Crossover for SASL allows anyone to return to the key that can validate the username/password combination.
One SASL mechanism is useful to add. We call it GS2-HAAN-GENERATE and its task is to produce a fresh pair of username and password. As explained above, the username is random and the password is derived from it. Together with the domain name of the originating HAAN Service, the username forms a Helm Key that can be registered for any Online Resource.
The SASL exchange starts with a server-offered list of mechanisms, from which the client selects one. If normal login mechanisms are offered along with a GS2-HAAN-GENERATE fallback, then a well-known pattern emerges, namely the equivalent of a website login with an extra button to register if you have no account yet.
LDAP Extensions
Some systems are administered in LDAP, others in SQL or yet other formats. Since only LDAP has a generic schema language, this is the best way of expressing the extensions in support of the ARPA2 Helm, and have an easy-to-translate example for other contexts.
Adding a class helmOnlineResource to an LDAP object makes it subject to control over the ARPA2 Helm. A search for instances can start by looking for such objects.
Each of these can list any number of helmIdentity attributes. After authenticated login, presumably with Realm Crossover for SASL, a simple filter can be used to match these entries. The helmIdentity is either the exact identity or it may add a space and a label; that can be formulated in an LDAP search filter.
A few more things can be useful. When the object classes provide insufficient detail, a helmType may add value. And when an application independent name to present for the object is useful, then helmCanonical may be used. But that's it, really.
These simple additions to LDAP objects suffice to search for those that match a login; to add and remove Helm Keys, and so on.
True Independency is a Choice
The use of a HAAN Service implies trust in such a provider, and that may not be easy in all situations. Having seen how simple this service is to run, it should be possible to run your own and even multiple of them, either distributed among friends or among locations of your organisation. Spreading control is the trick, so that instances cannot fail together due to the same reason. Variation is key.
There are bound to be ideologically pure providers. The trick is then to find the ones that share your ideology.
Go Top