[483] in Kerberos
Mike's wish list
daemon@TELECOM.MIT.EDU (Jennifer Steiner)
Tue Aug 9 10:04:49 1988
To: kerberos@ATHENA.MIT.EDU
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
- ------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA21570; Thu, 4 Aug 88 10:27:37 EDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11479; Thu, 4 Aug 88 10:25:49 EDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00682> for steiner@athena.mit.edu; Thu, 4 Aug 88 10:25:07 EDT
Received: via switchmail; Thu, 4 Aug 88 10:25:00 -0400 (EDT)
Received: from whitaker.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q000/QF.whitaker.andrew.cmu.edu.22f87369.7ca4c>;
Thu, 4 Aug 88 07:23:40 -0700 (PDT)
Received: from whitaker.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/kazar/.Outgoing/QF.whitaker.andrew.cmu.edu.22f87364.98a7d>;
Thu, 4 Aug 88 07:23:32 -0700 (PDT)
Received: from Version.6.20.N.CUILIB.3.44.SNAP.NOT.LINKED.whitaker.andrew.cmu.edu.rt.r3
via MS.5.5.whitaker.andrew.cmu.edu.rt_r3;
Thu, 4 Aug 88 07:23:31 -0700 (PDT)
Message-Id: <EWy7BXy00Uk-80TEpL@andrew.cmu.edu>
Date: Thu, 4 Aug 88 07:23:31 -0700 (PDT)
From: Mike Kazar <kazar+@andrew.cmu.edu>
X-Andrew-Message-Size: 4066+0
To: steiner@ATHENA.MIT.EDU
Subject: Fwd: Kerberos wish list
References: <MWxm8my00Uk-48PGIX@andrew.cmu.edu>
...
- - ---------- Forwarded message begins here ----------
Well, the heart of our wish list is Ted Anderson's ticket proposal that he sent
to the kerberos mailing list about a week ago. I'm assuming you've seen that
note; if not, send mail to me or to Ted (ota+@andrew.cmu.edu) and we can send
you a copy of the message. The key ideas in that message are (and I'm
over-simplifying here, so you should really read the original note):
More flexibility in specifying when a ticket is valid. We'd like to be
able to specify that a ticket will be valid for a longer period than is
possible now, and we would also like to be able to specify that a ticket
doesn't become valid until a certain time. Ted's proposes using a start
time and an end time, both in Unix date format seconds, to get this
functionality.
I certainly wish that tickets had only one format: network byte order. The
time to convert these things to a different byte order is essentially
trivial, and of course having only one format simplifies things.
It looks like there really is no need for placing the server's name and
instance into a ticket. That would probably reduce the size of tickets
considerably.
Aside from the ticket format, there are several other problems with the
Kerberos distribution as it stands now.
The Kerberos administrative protocols are UDP-based and non-idempotent, yet the
Kerberos code simply retransmits requests without any attempt to prevent a
request from multiple executions. This affects virtually every network request
except for the "get tickets" request. We strongly suggest the use of an RPC
mechanism here, and we're working with IBM to try to make our RPC and
light-weight thread package available essentially in the public domain if you
folks want to use it. Using an RPC mechanism has a significant effect on the
protocols, but we believe, based on our experience, that RPC interfaces are
quite easy to understand and well worth using in those circumstances where they
make sense.
Another "system design" level problem with Kerberos is the lack of a mechanism
for storing tickets for others to read. In the Andrew file system, we
associate tickets with process trees, and any process within a tree can get the
tickets for that tree. Any process can establish itself as the root of a new
process tree, which starts out life with no tickets available (except for those
it had the sense to retrieve before establishing its own tree). Certainly the
current Kerberos scheme of storing tickets in a file on /tmp is unacceptably
insecure on timesharing machines.
Finally, we'd like to see a better replication scheme for the kerberos
database. When I create a new user, change a password, or whatever, I'd like
the operation to take effect as soon as the operation completes, at least
assuming that no network partitions have occurred (the problem gets *seriously*
difficult in the presence of network partitions). We'd like to write utilities
for administrators that do things like create new users, and in our
environment, this requires that Kerberos database operations complete before we
can proceed to create the new users' home dirs, as well as add them to the
appropriate user groups and other file system configuration tables.
Well, that's my first cut at a wish list.
Mike
- ------- End of Forwarded Message
------- End of Forwarded Message
