[3549] in Kerberos
Re: Let's make some decisions re Kerberos 4 credential cache API
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Thu Jul 14 12:06:44 1994
Date: Thu, 14 Jul 94 11:54:10 EDT
To: kerberos@MIT.EDU
From: mamros@ftp.com (Shawn Mamros)
Cc: mamros@ftp.com
Reply-To: kerberos@MIT.EDU
[Note: I am sending this reply to kerberos@mit.edu only, as per John's
request. I hope this doesn't leave others out of the conversation...]
It may just be me, but John's proposal has me somewhat confused.
I'm not sure whether he's proposing using an existing API, or of coming
up with additions to the existing one to support the desired functionality.
If he's proposing using the existing UNIX Kerberos API as-is, then I don't
see how it can support the functionality, unless he intends to change the
semantics of the existing functions.
Quoting from John's message:
>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.
It should be noted that, in the UNIX API at least, krb_set_tkt_string()
only changes the default cache of the program calling the function.
Other processes (including child processes which exec some other program)
are not affected, because the string which gets changed is part of the
data area of the specific process in question.
If the semantics of the UNIX krb_set_tkt_string() are preserved across
all platforms (as it should be, IMO), meaning that the call only affects
the process/task making the call, then that would not be capable of
implementing the sort of environment which John envisions as follows:
>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.
This sort of environment would imply that there would be a function
call which would change the default ticket cache used by any application
started after the call was made (by the "control panel" or whatever).
Right now, such a call does not exist in the UNIX Kerberos API (unless
you count putenv() as part of the Kerberos API ;-). krb_set_tkt_string()
certainly doesn't do it.
And the environment variable soltuion which the UNIX implementation adopts
really doesn't entirely work in the desired manner, either. If I'm on a
UNIX workstation running an X11 server, and I change KRBTKFILE inside an
xterm, that won't change the default ticket file seen from an X11 application
which I start from, say, my window manager. True, *I* know that I would
have to start the app from within the xterm where I made the KRBTKFILE
change for it to take affect, but do you seriously expect that *every* user
is going to understand UNIX environment variable inheritance and its
implications in an X Windows environment?
Certainly you're not proposing that krb_set_tkt_string() should make a
"global" default ticket file change on non-UNIX single-user platforms such
as DOS/Windows/Mac, are you? That would be a serious mistake, as there's
no reason why kadmin/kpasswd and the like couldn't be implemented on those
systems, and I would think you'd want to keep as much code in common with
the UNIX implementations (which would include use of krb_set_tkt_string()
to change the ticket cache for that program and that program only).
So, if you really want the functionality which you suggest across all
platforms, you're really going to have to have some additional function
call to do that. Or is that what you were proposing in the first place? :-)
-Shawn Mamros
E-mail to: mamros@ftp.com
