[113] in Kerberos
Re: a different proposal for authori
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:30:00 1987
From miller%erlang.DEC@decwrl.DEC.COM Tue Oct 14 12:31:20 1986
Date: 14-Oct-1986 1151
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB),
watchmakers@athena.mit.edu, developers@athena.mit.edu,
miller%erlang.DEC@decwrl.DEC.COM
Subject: Re: a different proposal for authorization, etc.
Many moons ago, while discussing these issues, we noted that a key
design decision was whether it was the service's responsibility to
request authorization information, or whether the client had to
provide a "sealed capability" that verified its authorization privileges.
The current proposal by Jerry is of the former type, where the service
has the entire responsibility, given an authenticated user id, to
determine the authorization in whatever fashion it deems best.
I believe that this is a reasonably clean solution with only one
drawback. That is, if a single server (process) handles multiple
clients, the server must either block other clients while performing
a potentially lengthy network transaction to check authorization, or
alternatively, must be prepared to simulate separate threads for
each client. Thus, while waiting for authorization information to
be returned for client A, client B's requests could be serviced.
The problem is that if the server blocks, performance (throughput)
suffers considerably. Or in order to simulate threads, new and
more complex programming of the server is required.
The Kerberos versions of the "rcmd"s currently work in a similar manner;
all authorization policy and mechanism is done by the service, locally.
If server performance is a potential bottleneck, this approach also
adds workload to the server for the extra messages to check authorization.
With these provisos in mind, I find this proposal comparable to the previous,
with different tradeoffs.
Minor comments:
Servers registering in name service--
For servers with well known ports, this works well, with few
transactions. For servers that are not at well known ports, but
whose port changes each time instantiated, update traffic at
the name service should be kept in mind, as well as the authorization
for changing the name service entry. Alternately, a two-stage
binding could be used, where the name service maps to a host,
and something on the host maps to a specific port.
List membership service--
This could be a generic interface via network protocols ( and library),
rather than requiring it to be local. The only difference would
be performance, and security/integrity on the network media. The
library could detect whether the two ends were on the same host or not,
and apply encryption or integrity checks accordingly. As mentioned
in the proposal, this service would be authoritative for
certain lists, and would communicate with other list membership
services where needed.
If the list membership service recursively translates lists, it
must provide cycle detection at input/update.
Caches should time-out relatively quickly, since they provide
real value, rather than just a performance improvement. And
you cannot guarantee any means of invalidation in a network
environment with a variety of types of failures.
{end}
