[103] in Kerberos
simpler approach to RVD-kerberos in
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:28:41 1987
From Saltzer@ATHENA.MIT.EDU Sat Sep 27 12:11:25 1986
Date: Sat, 27 Sep 86 12:09:38 EDT
To: kerberos, rvd-info, yba
Subject: simpler approach to RVD-kerberos integration
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
John Ostlund, Jim Van Sciver, and I have been going over a strategy
to simplify the integration of RVD with Kerberos, and I think we now
have a complete and consistent simpler proposal.
The idea is to focus on the goal for initial integration: The first
goal isn't to increase RVD security, it is to simplify administration
and use by replacing a password-per-spinup interface with one based
on a password at login time. This proposal effectively does that
simplification but only for what will be the most common and
hard-to-administer case, the student locker.
At the same time, we need to finesse the temporary lack of an Access
Control List Service. With this proposal, when that service is
available, a second round of minor changes to RVD will lead to both
better function and better security.
The idea is to make just one change right now: activate the "owner"
field associated with each pack at the server. A new RVD packet
type, "authenticated-spinup", is defined; it looks just like ordinary
spinup but it contains an authenticated Kerberos ticket instead of a
password. The server uses the standard Kerberos library routines to
examine the ticket and extract the Athena user name. If this user
name matches the name found in the "owner" field, the spinup request
is honored. If not, it isn't.
In addition, no change is made to the server's action on receiving an
old-fashioned spinup packet. It extracts the password field of the
packet and compares it with the appropriate password field of the
pack data, which we continue to maintain.
The client spinup command now behaves as follows: Try to obtain a
Kerberos ticket for RVD service. If it is obtainable, ask the client
driver to send an "authenticated-spinup". If that succeeds, carry
on. If it doesn't (or a Kerberos ticket wasn't obtainable) the
command tries an ordinary spinup sequence, prompting for a password
if necessary, just as is done now. [Tuneup: If, on an
authenticated-spinup request that fails the owner test, the server
goes ahead and checks for a null password in the pack data, and allows
the spinup, it could save the client the extra round of interaction
currently used to discover the need for a password.]
Administration of student lockers would be done by creating packs
with the name of the owner as the owner, and with random strings as
passwords. I would be inclined not to even admit the existence of
the random strings, so as not to encourage the procedure of
exchanging files by exchanging passwords; the ability to allow
someone else spinup access is better postponed till we have an ACLS
and can do it appropriately.
System library packs would continue to operate as now, with some
operations or system engineering id being owner, a null password for
read access, and a password known to both operations and system
engineering for update access. Managing those passwords is two
orders of magnitude less hassle than trying to do it for all
students. The same is less true for class library packs, but I think
hand administration will still work there, at least until we can
field an ACLS.
Two more loose ends: Operations and administration would still be
accomplished with passwords, as at present; but now is the time to
separate those two functions. And finally, the change to encrypt the
passwords found in the RVD data base should now be made. Steve
Miller's high-performance DES one-way-encipherment will be used
rather than the more majestically paced Unix algorithm.
When the ACLS server becomes available, a second round of changes
would be made: the server would accept ACLS membership certification
tickets as well as Kerberos tickets; all password fields would be
replaced by list or user names, and operations and administrative
operations would be done by supplying tickets.
Comments?
Jerry
