[13] in pc-kerberos
Re: On the ticket storage issue...
daemon@ATHENA.MIT.EDU (Paul B. Hill )
Tue May 17 15:14:18 1994
To: mamros@ftp.com (Shawn Mamros)
Cc: pc-kerberos@MIT.EDU, kerberos@ftp.com
Date: Tue, 17 May 94 15:05:00
From: pbh@MIT.EDU (Paul B. Hill )
In your message of Tue, 17 May 94 10:39:23 EDT you said:
Hi Paul,
I've been Cc'ed on the traffic between Gordon Lee and yourself on the
issue of ticket storage and ensuring that different implementations
are able to interoperate. I've been doing a lot of thinking on this
subject, and I'd like to offer those thoughts in the hope of reaching
a solution which everyone can agree upon.
I agree 100% with the goal of interoperability, but one question I have
is this: does "interoperability" mean that all implementations have to
share the same ticket storage scheme, or does it suffice to have a
uniform API and calling convention that allows implementations to use
whatever underlying ticket storage they may choose to support? IMHO,
it's highly unlikely that one is going to be using two different Kerberos
DLL implementations at the same time, just as it's unlikely that one will
be using two different winsock.dll implementations at the same time. If
that's the case, then it seems to me that compatibility at the API level
would be sufficient to guarantee interoperability.
The original Kerberos V4 API for UNIX does a relatively decent job of
hiding ticket file location (and the need to know it) from the application
writer. The only function which truly requires a ticket file name is
tf_init(). (krb_get_tf_fullname() and krb_get_tf_realm() also require a
ticket file name, but both of these simply pass on their argument directly
to tf_init() without any additional usage of that argument.) For UNIX
systems, the function tkt_string() returns the default ticket file name
(based on either the environment variable KRBTKFILE or, failing that, the
user's UID).
If tkt_string() is defined to return a valid, printable string that somehow
identifies the "location" of the ticket "file" (for implementations that
support on-disk ticket files, the string would be a filename;
implementations using an in-memory ticket storage scheme would return some
non-filename string that would be an implementation-dependent identifier),
and tf_init() is made capable of accepting and verifying whatever return
value(s) tkt_string() may provide by default, then the underlying ticket
storage scheme is, for all intents and purposes, completely transparent to
the application programmer. Since tkt_string() and tf_init() would be
functions located within the same DLL, there should be no issues regarding
getting the return from tkt_string() in one DLL and having an app call
tf_init() in another DLL that won't know how to use it. The only real
difference between this scheme and the existing UNIX Kerberos API is that
applications must not assume tkt_string() returns a filename.
Not only can tkt_string() hide whether a DLL implementation is using
in-memory or on-disk ticket files (or both), it can also hide whether or
not the DLL can support multiple simultaneous ticket files (i.e., having
tickets for both "pbh" and "pbh.root"). For implementations that can
support multiple files, tkt_string() should consult whatever
implementation-dependent configuration/environment parameters govern the
location and usage of various ticket "files" before returning a suitable
string. Implementations that support only a single ticket file will return
some "fixed" string that will be the same across all concurrent calling
applications.
What do you think? Does this sound like an acceptable solution, or are
there other issues which this proposal doesn't address? Let me know
if this looks OK; if so, we'd be willing to have it forwarded to the
rest of the mailing list.
-Shawn Mamros
E-mail to: mamros@ftp.com
------- End of Forwarded Message
Although I love the idea of a well implemented abstraction layer I think
that there are some issues that are not addressed.
Having followed what the Mac community has done I think it is possible that
some users may end up using more than one DLL to access the Kerberos
tickets. I am aware that the current chaos surrounding Kerberos on the Mac
is largely due to the lack of well implemented device driver being
available a few years ago however there are additional reasons why the
situtation exists and why it is not being solved as rapidly as users would
like.
Many developers abhor the existing Kerberos API. Some sites have created
C++ wrappers that have an entirely different API. In the future some sites
may port these to Windows. Other sites are very interested in GSS and may
create a GSS DLL that uses v4 as the underlying authentication mechanism.
Although at first glance you would expect both of these approaches to be
layered on top of an existing Kerberos DLL this may not happen.
The other issue that is not addressed is the whole problem of where DOS and
Windows are heading and what needs to be supported. At our site we have an
uncounted but large population that uses DOS and TCP/IP but not Windows. We
have an even larger population that uses a mixture of both. We also have a
growing number of users that are fans of OS/2 and Windows/NT. Under OS/2 we
also need to support the DOS and Windows subsystems. Under Windows/NT we
need to support the DOS, Windows, OS/2 1.3, and POSIX subsystems.
I realize the the POSIX subsystem under NT does not currently support
Networking but I wouldn't be surprised if it eventually does. Either due to
the efforts of clever hackers or with MS's blessing.
What happens when someone writes a Kerberos server for some other
networking environment like Netware or LAN Manager? Will each vendor have
to decide if they want to support it with their DLL implementation? Or will
the ticket storage be well defined so that someone can make a version that
will interoperate?
WABI, Soft Windows, ....
Do we want the use of Kerberos to be transparent across these emulators and
the host system implementations?
This implies that in many cases just having a well defined API at the DLL
level may not be enough for our users. By "our" I mean the customers of
everyone on this list. Although I do not ever expect an application
developer to have to be aware of where or how tickets are stored I do think
it is important that different implementation authors give this issue
serious consideration. I believe that having a well defined method of
storing the tickets will prove invaulable during the next 24 months.
I have concluded that our Kerbmen implementation falls short of my goals. I
think a file based ticket storage is needed. However I think that the use
of a SMALL RAM disk should be encouraged on DOS/Windows machines. Just as
the use of a memory mapped file should be encouraged for NT users.
Now do we provide some fallback or discovery mechanism for vendors that do
not agree with this strategy? I realize that some vendors have decided that
their only customers are Windows users. Do we provide backwards
compatibility for users of the existing MIT distribution?
Comments?
Paul
