[3545] in Kerberos
test
daemon@ATHENA.MIT.EDU (De Ruysscher B.)
Thu Jul 14 07:53:16 1994
To: kerberos@MIT.EDU
Date: Thu, 14 Jul 1994 11:28:43 GMT
From: u25843@s854803.kb.be (De Ruysscher B.)
In article <199407140745.AAA07370@cygnus.com>, gnu@cygnus.com (John
Gilmore) writes:
Path:
ub4b!EU.net!uunet!MathWorks.Com!noc.near.net!pad-thai.aktis.com!INTERNET
T!dont-mail-to-path-lines
From: gnu@cygnus.com (John Gilmore)
Newsgroups: comp.protocols.kerberos
Subject: Let's make some decisions re Kerberos 4 credential cache API
Date: 14 Jul 1994 04:58:07 -0400
Organization: comp.protocols.kerberos<->kerberos@mit.edu gateway
Lines: 92
Sender: daemon@cam.ov.com
Message-ID: <199407140745.AAA07370@cygnus.com>
Reply-To: kerberos@MIT.EDU
NNTP-Posting-Host: pad-thai.aktis.com
[This message is going to the Mac, PC, and general Kerberos mailing lists.
Some of these lists mangle the return and reply-to addresses. Please
send replies to kerberos@mit.edu (which is also comp.protocols.kerberos).]
After working more with Kerberos, I feel like I have a solution for a
credential-cache API problem, which is that many implementations of
Kerberos have used different API's for accessing cached credentials.
Unix Kerberos 4 multiple cache, selected in environment, no extra args
Mac KClient multiple cache, selected by TGT princ name, 3 args
Mac Stan Z's multiple cache, selected by app-specific string, 1 arg
Mac AuthMan single cache, no args
Windows MIT K4 single cache, no args
("args" refers to additional arguments to cache-related functions
in the API, such as save_credentials, which determine which cache
is being accessed.)
I've come to the tentative conclusion that the Unix Kerberos interface
(multi cache, selected outside the application) is best. My
experience says that it is a very rare application which knows or
cares "which credential cache" it is using. Essentially all
applications except those *distributed with* kerberos will use the
default cache. For this reason, and for compatability with the
traditional Kerberos API, there appears to be no reason to be passing
cache identifiers in ANY of the function calls.
The few applications (like Unix kadmin) which want to use a separate
cache already have an interface for changing the default cache --
krb_set_tkt_string. I propose that we support this API interface
for multiple ticket caches on all platforms.
As for user interface, it really should be up to the user to manage
their ticket caches. This is how it works on Unix, where users can
set KRBTKFILE in their environment in order to specify another ticket
cache. In a GUI environment, I would provide a visual indication of
how many ticket caches there were, with a way to switch among them
(click on one, probably) and a way to create (`New...') and delete
them. The usual action ("Login...") would replace the tickets in the
current cache with a new TGT.
The point is that user actions in a control panel, not application
program actions, would select which cache is currently in use. The
user knows what they're trying to do, while the application has no
clue what the user is trying to do. For example, the user may be
trying to log into host3, while holding TGT's for realm1 and realm2.
The user can know that realm2 has cross-authenticated to realm3, so
their TGT for realm2 should be used. But the "telnet" or "newsreader"
application won't know this. In many cases where multiple tickets are
held, they'll be in the same realm (Alice and Bob, sharing a machine
in their dorm room). Again, the computer can't tell which ticket is
appropriate for a given application transaction without being told.
It can be easily explained to the user that each TGT identifies the
user as a different "person" or "role". The machine doesn't know
which person is typing, or what role they are playing, at any given
time. The user must tell the machine, "Now I'm Peter, who shares the
machine with Mary". Peter could "Login..." and destroy Mary's
tickets, instead of keeping Mary's tickets around for when she comes
back; many naive users would do so, not knowing there is any option to
have multiple simultaneous identities and switch among them at will.
This is safer than having the default leave naive users' tickets
lying around when a new person identifies themself. It's also less
confusing to explain.
I'd like to start a discussion on this topic, in hope of coming to a
resolution acceptable to most of us, whether or not it ends up similar
to what I proposed here. We can't have a common Kerberos
implementation without a common API and user interface paradigm.
(Cygnus now has a limping Mac Kerberos implementation from the same
source tree as Unix & Windows Kerberos, but putting it on the net at
this point would just make one *more* API to choose from -- and we
need fewer, not more. So let's do some deciding.)
For people who disagree with this API proposal: Please explain how you
expect applications to decide how to select the ticket cache. E.g.
when and why would an application pass anything but the default values
of these arguments to Kerberos?
For people who want to think about K5 or GSSAPI: Please stay out of
this discussion for a bit. We're *close* to having a multi platform
K4 API, and would prefer to stabilize that before opening the next can
of worms.
For people who don't like my particular illustrative GUI choices: Please
hold your fire until we get the API straightened out. Focus, focus, focus...
[Again, let's hold the discussion in kerberos@mit.edu -- ignore the
Reply-To and From: lines generated by overzealous listservs.]
John Gilmore
Cygnus Support
