Project Notebook for SystemDesign

SystemDesign

The Authorization Server has three interfaces:

The implementation has the following components:

Several sets of names have special meanings:

KSUclient

The KSUclient 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 FallBackClient could be used, the user is specifically informed.

AuthorizationProtocol

The AuthorizationProtocol is implemented by a client side library. There are a small number of external features:

The additional internal interfaces include

ACLdatabase

The ACLdatabase 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.

AdministrationClient

The AdministrationClient supports the basic operations of the protocol directly.

It will have support for reading bulk data from files, possibly generated by other utilities.

ACLNameSemantics

Authorization lists should be named so as to make their use clear and unambiguous. A method for constructing clear names follows:

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.

AdministrationProtocol

The AdministrationProtocol is in the initial version very simple. Based on the standard text-command protocols like POP and FTP, once authentication is complete, the commands

are sufficient for first implementation. Any of these commands can return success, not permitted, or other failure. (Permission on lists is managed by some AdminMetaLists, 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

PrincipalNameSemantics

Principal names are simply the string representations of Kerberos V principal names.

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.

SlaveDistributionProtocol

The SlaveDistributionProtocol is an authenticated "ftp" or "pop" style text based protocol. It has one command:

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 AdministrationProtocol, 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.

FallBackClient

The FallBackClient 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 and possibly whatever else is likely to fail in such a way as to interfere with normal authserver 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.)

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.

SendAuthQuery

SendAuthQuery takes a packet from MakeAuthQuery and sends it to the first available authserver. The reply packet is returned to ParseAuthReply. (This keeps the separation between the queries themselves and the slave replication feature clear.)

A later version of SendAuthQuery could parse the reply directly and attempt to connect to other slaves in the case of certain types of failure.

MakeAuthQuery

MakeAuthQuery 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.

MakeAuthQuery provides a packet for delivery to the authserver.

ListAuthServers

ListAuthServers 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.

ParseAuthReply

ParseAuthReply is used to take the AuthServerResponse and report a useful answer, in the form

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.

AdminMetaLists

AdminMetaLists are used to manage access to lists themselves.

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.