The plan for this note is to describe a centralized authentication services and to explore what infrastructure is necessary to make it sound. Naturally the prejudice is that it will be sound if it can be made to conform to the style of distributed capabilities.

A natural (predominant?) growth mode for a system is incremental automation of manual operations. Suppose that we have a centralized authentication server (AS) that has the function of authenticating things (usually persons) outside some perimeter to application code within the perimeter. How does this plan meet to demands of the above incremental development?

We will suppose that AS is securely connected to the portals of the perimeter and controls those portals to identify the agent at the portal. We further assume that the AS can convey its assurance to points within the perimeter so that, for instance, an application could gain access to a circuit knowing that it is an authenticated, possible private connection the agent as identified by a securely delivered datum.

Incremental automation, as described above, occurs at the portals, where the manual operations of the persons occur. After such a module has been added the semantics of the AS has changed. The circuit is no longer to the agent but to the new module. This does not mean that the new configuration is insecure, but merely that the original security argument is no longer valid.

Suppose that application X has a secure circuit to person Z and that the system is to be improved by adding code, Y, that intermediates between X and Z. More precisely, instances of X will, after the installation of the new code, acquire a circuit to Y which, in turn, gains a circuit to Z.

The above picture is still fuzzy for we have ignored the question of the authority that this software upgrade required. In typical Unix systems the most commonly expected answer would be that someone with root privileges makes the changes and that is all that is necessary. Capability systems aspire to imposing security principles to the installation, as well as the operation of evolving software configurations.

To sharpen the last point, there seems to be two interesting answers to the question of installation authority:

  1. The person or his agent installs the code Y, transparently to the application Z,
  2. The application installs the code Y, and presents the result as a functional upgrade to Z.
With the person’s authority (scheme 1)
I am currently hung up with the realization that “Capability systems aspire to imposing security principles to the installation, as well as the operation of evolving software configurations.”. Current Unix practice is to use root authority to install most applications. I don’t know whether this is a property of the culture or a necessary attribute of the applications and operating system. I know that it is often necessary to use root authority for at least part of the installation.
Naïvely it would seem that the concept of principal is being reincarnated with its attendant pitfalls!