The implementation has the following components:
Several sets of names have special meanings:
The additional internal interfaces include
are sufficient for first implementation. Any of these commands can return success, not permitted, or other failure. (Permission on lists is managed by some Admin Meta Lists, which can themselves be managed.)
Each command is committed on the master and propagated to all connected slaves. The client gets a response when the master has the transaction committed, and an additional response when the slaves have all responded or been dropped. If a slave is dropped, the client is informed, as is syslog. (The slave will get the record when it reconnects.)
Later extensions would likely include
First, it causes the whole database to be transmitted in a compact form.
Then it causes the connection to "turn around". The slave starts listening, and the master starts sending commands. In this mode, the slave has a command set that includes the commands in the Administration Protocol, but may also support some diagnostic commands.
The slave command set also includes an "accept full dump" command, so that if a slave loses touch with its master and must reconnect and get a new full dump, it can inform all of its children likewise. (A simpler version which would need no specification would simply be for any server which lost it's master to drop all of its slaves; this might lead to unfortunate load redistribution, but remains an option.)
Combining the two makes sure the slave gets complete data, as the server can begin accumulating incremental commands at the time of the dump.
The server commands include an increasing sequence number (possibly a timestamp). A future extension could have the slave record the last seen sequence number, and send it along with the dump command, so that it can receive an incremental update instead of a full dump even after downtime.
Id numbers are from a single pool. Entries have a tag indicating whether they are principals or one of the three types of acls.
For dbm, when a direct acl gets too large it becomes a temporary indirect acl with two half lists. For other systems, temporary indirect won't be necessary.
It will have support for reading bulk data from files, possibly generated by other utilities.
(In the general case, realm/ksu/hostname/username would be used.)
If the checks fail in such a way that the Fall Back Client could be used, the user is specifically informed.
In a large distributed environment, the number of user/host combinations involved might become accessive. If there are common groups of machines, ksu could be modified to treat a set of machines as a "class" of hosts, and use the classname instead of the hostname as key.
If the query succeeds, the client reports such and exits.
If the query fails, the client looks up the current index number and hash (which may be stored in the clear) and prompts the user with the index; if the user produces a value which hashes to the current one, it is stored and the user is let in. (The index number should be updated in a way that doesn't rely on additional disk space being available.) This will be based on the S Key Protocol developed at Bellcore, as described in Internet rfc1760 (S Key RFC.)
When the user is accepted, it should prompt for what program to run, giving a default of /bin/sh (or a value taken from krb5.conf.) This makes it easier to deal with local installation problems.
There are also special wildcard prinicipals. The simplest is "*" for "all authenticated prinicipals." More restrictive (probably more common) is "*@realm" for all authenticated prinicipals in this realm." The backslash convention is extended to permit the use of "*" as an actual character in a principal name.
Further, the trailing match case of "name/*@realm" indicates a principal with that name but any instances (likely to be a convenience for user with multiple principals.)
Note that fully general wildcarding can be expensive; restricting to the forms listed here make it possible to provide the feature while preserving efficiency.
The base form of all names is "realm/service". The realm is included to allow a server to support queries for multiple realms; this also permits an error response of "incorrect realm" if an authserver doesn't actually support a particular realm. The service name should be unique to the service provided, overloading as is used by the "host" service in V5 (or equivalent "rcmd" in V4) is to be avoided.
The service can be subdivided into general and more specific classes. A common one will be "service/hostname" where the hostname is a fully qualified domain name, and describes a particular instance of that service. "rootaccess/ftp.cygnus.com" is an example; "wwwrestart/www.mit.edu" might be another.
These are only conventions, but they are highly recommended. Slashes should be considered component separators. Services with finer breakdown of detail should generally use "service/host/tag" to provide such detail. Since acls can be added to other acls by reference, administration can be simplified by creating specific acls that contain generic ones, and putting the appropriate real principals on the more generic ones.
One possible way to permit encoding of names containing slashes (such as complete kerberos 5 principal names) is to encode the slashes (and other offending characters) using the %xx used in web url's. Thus slash becomes %2F, and percent sign becomes %37. This permits encoding of the zero byte as well, and if newline is encoded as well (%0A), can permit simple line-oriented protocols to pass around aclnames otherwise unencoded.
This encoding can be used for any component; the database can simply store the encoded form of the name, and continue to interpret the slash as a separator.
Make Auth Query provides a packet for delivery to the authserver.
A later version of Send Auth Query could parse the reply directly and attempt to connect to other slaves in the case of certain types of failure.
Additional information may be reported, especially in case of a failure.
A possible future expansion might be to have "unknown list" optional indicate that a list is "partially" unknown. A "partially" unknown list is one where some set of components (starting from the left) matches some existing acl, but the total entry does not exist. This may indicate a configuration error on the client, or an adminstrative error. Although it could be implemented with database probes, that may be two expensive for limited value.
In Kerberos 4 there were admin_acl.add, del, get, cpw; in Kerberos 5, there are similar acls.
The simplest case would be an overall acl, of the form "realm/authserver/servername/feature" where feature is one of
Specific acl's could later be placed on lists themselves, possibly by using "listname/feature" or better "feature/listname" directly.
The "list" feature is where one would set a site policy about being able to read the contents of acl's. It can be left open (*@realm) to allow users to easily find out who is the administrator for some item, or it can be restricted in order to prevent narrowing down the list of entities which have useful access and are thus targets.