(no subject)

This message is in response to the brief discussion earlier
about user IDs and what to do about remote users. I mentioned
that I was opposed to the local system doing any sort of
mapping of user IDs whatsoever. Andy's current thinking
is that he would temporarily map them all to a default 'net'
user ID. Here is some of my reasoning for being against
this approach.

There are at least three (3) different schemes for "networking"
many computers together.

I. Introduce a new set of commands: rlogin, telnet, rcp, ftp, rsh,
   rexec, etc. to allow users to log onto other systems, transfer data
   to/from other systems, and execute commands on other systems.
II. Introduce a central administrator (usually a master system) or a
    globally agreed to administration procedure so that: all the
    files/resources on every system appear as though they are in a
    single (local) file system. This generally also means either
    global user IDs and/or replicated root directories.
III. Introduce an enhancement to the pathname format to include
     "system" in the path.

   I prefer option III. (I also implemented it many years ago at
a large computer company.) Option I does not give the user enough
power, replicates commands the user is already familiar with (cp,sh) and
introduces new commands which before were transparent and associated with
physical devices (rlogin, telnet).

  Option II requires too much to be defined globally, does not give
each system autonomy, and all too often it is incredibly difficult, if not
impossible to move a computer from one network to another (pathname
conflicts!!).

  Option III may be implemented by a simple modification to the
"open" system call and thereafter passing system calls to a server task.
This, in and of itself, can be a lot of overhead and a little slow.
However:
1) Good support of intertask communication can solve this at the
application level. Applications can send messages to other tasks
which contain much higher level operations than "read,write,rewind".
2) ALL of the standard security and accounting automatically work.
3) In efficient implementations the interposition of an extra server
task at each end is very small compared to the network and actual I/O
overhead.

  If done right, Option III can also maintain the integrity of the
local system's password file. The only user IDs that the local OS knows
about are local user IDs. Anyone on a remote machine accessing my local
files will have to present a valid local ID. This allows me to continue
using my normal security and accounting procedures. Notice that when we
turn this around it means that in order to access someone else's system we
need to map our local user ID to a valid ID on the remote system.
I envision this mapping being done by a special kernel task which
maintains a special user ID mapping database. Users may add/modify/delete
(my_local_userID,remote_system,remote_user_ID) entries at any time.

  I am strongly opposed to any compromises to local autonomy. For
instance I feel it is a horrible security hole to recognize certain users on
certain remote systems as privileged on my system. In fact, I think it is a
big mistake to recognize the system from which a request originates at
all. This is too easily falsified in a broadcast environment. The best
security would entail having the initiator of a communications session 'prove'
his identity by responding to an encrypted question. Public key
encryption is a good tool for this. I also think it is a mistake to allow
certain files to be 'exported to' or 'mounted by' only certain remote
systems. Security must be based on user ID (and maybe other filters as well,
such as restricting the access rights of an executable program when it is
installed on the system. These restrictions would be in addition to
any restrictions placed on the user executing the task.)

  When a remote request for access comes in, it must not matter from
which remote system or network that request originates; instead, it
only matters what local user ID is presented. This user ID must not be
verified by passing the password across the net (too easily
intercepted) but by an encrypted session initiation. After the user ID is
verified a session key is exchanged that will be used for the encryption of
all data sent during this communication session. (That key may be null
if the user wishes. This could be the case if the communcation line is
known to be secure or if the data being accessed is public.)

  Also, I don't want to forget accounting. It is important that
remote users pay for their access to my system. This is handled by charging
all their activity to the local user ID the remote user presents.
My system is not a public asset. I must be able to control and
charge for access, or else I do not really 'own' my own computer.
Received on Tue Jan 11 14:52:15 1994