[3551] in Kerberos
Re: Let's make some decisions re Kerberos 4 credential cache API
daemon@ATHENA.MIT.EDU (Eric Blossom)
Thu Jul 14 14:44:01 1994
Date: Thu, 14 Jul 1994 11:22:28 -0700
To: kerberos@MIT.EDU, krbdev-l@brownvm.brown.edu, pc-kerberos@MIT.EDU
From: EricBlossom@epri.com (Eric Blossom)
Cc: kerberos@cygnus.com, jcm@cygnus.com, gnu@cygnus.com
At 12:45 AM 7/14/94 -0700, John Gilmore wrote:
>[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.
I think I understand this so far and agree with it.
>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.
Here I get confused. I'm not clear on the purpose of multiple ticket cashes.
How is the set of all tickets on a machine partitioned by the cashes? Or is
this what is being debated? Does a cashe correspond to a realm? Or, does it
correspond to a TGT and service tickets obtained through use of that 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.
This sounds like you want the tickets cashed by TGT. i.e. one TGT (plus
service tickets) per cashe. Is that right?
>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 think I'm with you here. My current interface keeps a state for each
realm. It is logged in or not. So Peter must logout of the current realm
and log in again. Or he could switch realms (there can be more than one
copy of a realm for different users). Are you suggesting that I allow
another login to replace the current one? I should have a working version
of my new design today or tomorrow and I'll send it to you.
>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.)
The common API is very important. The common user interface paradigm may
be less important. With a strong API perhaps someone will come up with
a better user interface that we do not foresee.
>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
Eric Blossom 415 855-2270 EricBlossom@.epri.com
Electric Power Research Institute, Palo Alto, CA
