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.
ACL Database
The ACL Database uses the same basic technology as the Kerberos
Database (Berkeley db or native dbm) except that several techniques
are used to make sure that arbitrary length lists of principals can
fit in a database entry:
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.
Administration Client
The Administration Client supports the basic operations of the protocol
directly.
It will have support for reading bulk data from files, possibly
generated by other utilities.
KSU Client
The KSU Client is both a demonstration of the service and the original
purpose for implementing the service. The extensions are
staightforward; the existing .klogin file check is simply replaced
with a call to the authserver for "realm/ksu/hostname/root" with the
principal name that we've identified.
(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.
Fall Back Client
The Fall Back Client attempts to make an authserver query. This needs to
have the effect of testing whether a normal authserver query would
work, so it needs to use
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.
Principal Name Semantics
Principal names are simply the string representations of Kerberos V
principal names.
ACL Name Semantics
Authorization lists should be named so as to make their use clear and
unambiguous. A method for constructing clear names follows:
Make Auth Query
Make Auth Query is intended for use by servers checking
authorization. They are expected to have already checked
authentication to themselves in whatever way makes sense to the
application.
Send Auth Query
Send Auth Query takes a packet from Make Auth Query and sends it to the
first available authserver. The reply packet is returned to
Parse Auth Reply. (This keeps the separation between the queries
themselves and the slave replication feature clear.)
Parse Auth Reply
Parse Auth Reply is used to take the Auth Server Response and report a
useful answer, in the form
List Auth Servers
List Auth Servers is used to get a list of servers to try. This will
closely parallel the code used to get a list of kdc's, and if there
isn't a specific indication otherwise in krb.conf, will be the same list.
Admin Meta Lists
Admin Meta Lists are used to manage access to lists themselves.