[112] in Kerberos
a different proposal for authorizati
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:29:53 1987
From Saltzer@ATHENA.MIT.EDU Sat Oct 11 23:18:28 1986
Date: Sat, 11 Oct 86 23:15:36 EDT
To: kerberos, watchmakers, developers
Subject: a different proposal for authorization, etc.
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Jeff and I have been chewing over several alternate possibilities for
design of an authorization service. Each has a
Japanese-tea-party-like scenario of interaction among a client,
Kerberos, authorization service, name service, and the service the
client was interested in (if it hasn't lost interest after all that).
The result of those discussions is a new proposal, radically
different from the previous one I made (recently well summarized by
Steve Miller) on how to organize this architecture.
There are three issues that are beginning to dominate my thinking on
this topic:
1. Availability: It is appropriate to minimize the number of
distinct, other network services that must be available at the
instant that one decides to invoke some service, especially if the
other network service isn't really needed for the specific case at
hand. (E.g., you are importing a public file system that allows
anyone read access. Access lists are irrelevant, so no request
should be made of an access list server, which may be on the other
side of a gateway that is reloading right now.)
2. Intricacy: some of the scenarios are very baroque; others seem
more intuitively organized and modular. Simplicity should win.
Also, simpler cases should have simpler scenarios.
3. Who's in charge: access authorization is a poorly organized area,
with lots of different ways to do it. In the absence of widespread
agreement that there is one best way, the server designer should get
to decide how to do it, rather than having to fit into someone else's
imposed model. Another aspect of this consideration is that private
services should get to (have to) store their own authorization
information, rather than burdening a public storehouse with such
stuff.
The new proposal, and a more-or-less complete scenario for
integrating name service, Kerberos, and authorization, is as follows
(there are a lot of services flying around in this discussion--the
one the client really wants to invoke is called the "desired
service"):
1. Assume for starters that each client (and service) knows the
internet address of a name service and the name of Kerberos. As part
of its initialization, the client invokes the name service to
determine the internet address of Kerberos. It also performs an
initial transaction with Kerberos to obtain a ticket-granting ticket.
Each service that cares about authorization has done the same
thing as part of its initialization.
2. The client learns the name of a desired service. It may learn in
one of any number of ways. Here are a few examples:
- A prospective user reads the name on a bulletin board.
- User copies a program from a public place; the program has the
name buried in it.
- The name is embedded in a system-provided library program.
- The name is embedded in a class-provided library program.
- The user knows a watchmaker.
3. The person exporting the desired service has previously done one
thing: registering the name of that service with the name service.
If this step hasn't happened, it doesn't prevent use of the desired
service, but it does mean that the client has to invoke it by
discovering and using a host name and port number, rather than by
name.
4. The client invokes the name service to learn the host name and
port of the desired service. The client can cache this information
at its own risk, to allow future invocations of the desired service
without using the name service again. The name service provides a
time-to-live value for the information that gives the client a hint
about how long it is safe to cache it. [There is an open question of
whether for this record type the name service should also resolve the
host name into a host internet address, to avoid another inquiry of
the name service. Since a different authoritative name server is
likely to be the real source of the name-to-IP address information,
there may be no advantage to doing it under the covers.]
5. The client invokes the Kerberos ticket-granting service,
requesting a ticket for the desired service name. If Kerberos has
never heard of the desired service, that doesn't cause the scenario
to abort; it may simply be that the desired service doesn't require
authentication.
6. [Assuming that the initial response from the name service was the
name of the server's host] The client invokes the name service
again, to transform the host name of the desired service into an
internet address.
7. The client invokes the desired service, presenting its Kerberos
ticket (if by now it has one) certifying the client's identity. It
is the responsibilty of the desired service to decide whether or not
it wishes to deal with this client.
8. The desired service may invoke a list membership service, which
operates via a network connection in a process running on the same
host. This list membership service looks up the client's identity in
a list that was mentioned in the request, and reports whether or not
it finds that name. A list may contain names of other lists; the
list membership service will perform a recursive descent through
these lists trying to verify membership of the client in one of them.
9. A named list can either be stored in a file containing lists on
this host, or it can be managed by a list membership service running
on a different host. The access list service is organized like the
BIND name service: a local process manages some authoritative data;
it may refer to remote list membership servers which manage other
authoritative data. The ability to use remote servers allows the
possibility of shared, centrally managed lists. The ability to use
local lists allows the possibility of lists whose contents are
unknown to any central authority. The architecture allows that these
two possibilities can be mixed and matched in any way desired by the
implementer or manager of the host that offers the service.
Because the desired service is probably depending on the
authenticity of the certifications of the list membership service,
each connection with a remote list membership service must be
initiated via Kerberos and the responses from the service need to be
integrity-assured. One way could be for the remote list membership
service to return a copy of the original request, with a yes or no
bit added, enciphered in the session key that the invoker obtained
at initial connection with the list membership service.
This description leaves a fair amount to be designed as to how the
list membership service might work internally. Because of the family
resemblance, an initial model might be that it is organized much like
the BSD BIND package, perhaps to the extent of implementing it by
starting with the code of that package. It seems fairly likely that
the same list membership service can serve both for access control
lists and also for mailing lists--especially since it would provide
neatly both for completely private as well as publicly shared mailing
lists.
It should be apparent that this proposal needs some comment and
discussion . . .
Jerry
