[2] in pc-kerberos
pc-kerberos information
daemon@ATHENA.MIT.EDU (pbh@MIT.EDU)
Tue Apr 12 11:41:43 1994
To: pc-kerberos@MIT.EDU
Date: Tue, 12 Apr 94 11:40:18
From: pbh@MIT.EDU
This message announces the creation of yet another mailing list,
pc-kerberos@mit.edu. It has been initially populated with a number
of users that have contacted MIT about Kerberos for DOS/Windows over
the past two years. If you wish to be removed from the kist, please send
mail to pc-kerberos-request@mit.edu.
This list exists to facilitate discussion on Kerberos implementations for
DOS, Windows, OS/2 and Windows/NT.
In Summer '91, developers at Brown University began to port MIT's UNIX
implementation of Kerberos v4 to the DOS/Windows environment. They chose
to target Novell's LAN WorkPlace for DOS API. As requirements, they
decided that tickets should be shareable between all DOS and Windows
applications, and that the DOS file system was sufficiently insecure that
tickets should not be stored in a file.
In early '93, MIT's dosdev team had reached a point in their projects which
required Kerberos support. MIT took the Brown code and both MIT and Brown
developers worked together to make the implementation bug free, with mostly
successful results. During this time frame, Eliel Mamousette of Brown also
began to port the Windows code to winsock, but was unable to complete the
work before leaving the project.
Code Availaibility
------------------
Summer '93 marked the MIT release of Leash for Windows, krbdll.dll and some
DOS applications for Kerberos. That release only supported the LAN
WorkPlace API. Source for the above applications are available via
anonymous ftp to the server/path
athena-dist.mit.edu:/pub/kerberos/README.pc
Binaries are also available from
net-dist.mit.edu:/pub/dos/kerberos-binaries
In order to build the sources you will also need com_err for Windows. This
may be found at
net-dist.mit.edu:/pub/dos/developers/com_err
MIT developers recently revisited the winsock support, and hope to make the
code available in the immediate future. This release also corrects some
bugs in the Kerberos for LWP version which are need support LWP 4.12a and
later versions of their TCP/IP Kernel and wlibsock.dll. This version will
also work under the forthcoming Mobile WorkPlace product.
Known Bugs
----------
1) kerbmem can cause a system crash if there is insufficient room in the
enviroment for it to create the variable "KERBEROS_TICKETS=xxxx" when it is
first loaded.
Share your changes
---------------------------------------
There are still many issues which need to be addressed before this package
will be widely accepted in the community. As work progresses, MIT's dosdev
team strongly urges both academic and commercial developers to submit the
required changes back to MIT so that we may incorporate them into our
release. All of us, developers and vendors alike, want to make sure that
different implementations will interoperate.
For example, we do not want to force users to re-enter their password each
time they invoke a Kerberized application. That defeats much of the purpose
of our work. This situation currently exists on the Mac.
Commercial developers have an additional incentive for submitting these
changes. Many firms do not want to enter into the legal hassles of
distributing a Kerberos development SDK for their overseas customers. By
making sure that commercial implementations continue to interoperate with
the MIT/Brown distribution, firms can point developers to the
athena-dist.mit.edu distribution point. This places the legal obligations
upon the developers rather than the commercial vendors.
Future Enhancements
-------------------
1) LWP for OS/2 support and support for IBM's TCP/IP for OS/2.
Support for Windows/NT.
Under the current implementation, tickets are stored in memory reserved by
a program called kerbmem. This is not portable to the OS/2 and Windows/NT
environments. Some firms do not intend to support DOS so they would prefer
to store the tickets in the DLL.
Storing the tickets in the DLL is not desirable, because the DOS subsystem
under OS/2 and the DOS, OS/2 and POSIX subsystems under NT will
have problems accessing the tickets. What happens to subsystem users when
the DLL is paged out? Is some one out there willing to write a vxd for
OS/2, NT, and Windows to enable the subsytems access to the tickets? What
happens to a DOS only user? Do we have two write two versions of each DOS
program, one with vxd support and one without?
It seems like the easiest method to support NT would be the use of memory
mapped files. Is there a similar mechanism available on OS/2?
Note: this topic only affects one module of the current distribution,
tf_util.c.
2) Vendor independent, user configurable location of Kerberos configuration
files.
The current distribution requires the Kerberos configuration files to be
in \net\kerb. The drive default to C: but can be overridden with the use of
the NDIR environment variable. The use of NDIR should be expanded so that a
full path can be specified.
Note: this topic only affects one module of the current distribution,
tf_util.c.
3) Support for multiple similtaneous principles.
The current distribution does not provide support for multiple
simultaneous principles. Many people at MIT have multiple principles, i.e.
"pbh" and "pbh.root". If I am connecting to a "secure" server, I will
normally need to use my pbh.root principle rather than my default pbh
principle.
Again, most of the changes required for this enhancement would be limited
to the tf_util.c module.
4) International distribution restrictions.
The international community has a need for two different versions of the
DLL - one which does not export the DES functionality and limits the use
of the DLL to authentication purposes only; the other to export the DES
functionality and enable the DLL to provide data encryption support as
well.
We need to define exactly which functions are exported in these two
versions and we also need to provide a function call to determine which
version is present or required.
5) Well defined calling interfaces for each exported function.
Currently some of the exported functions use the FAR PASCAL calling
convention and others use the C calling convention. This occasionally leads
to calling convention conflicts in applications using the DLL.
6) SRVTAB support.
The current distribution lacks SRVTAB support. As more and more users
wish to run servers which should require authentication on Windows, OS/2
and NT machines, this will become more important.
That's it for now. I'm sure many of you will raise additional topics of
concern to this group.
As a parting footnote here is list of the Kerberized DOS and Windows
applications that are currently known:
kinit, klist, kdestroy (DOS)
Leash (Windows)
TechMail (Windows, DOS version under development)
TechInfo (Windows)
lpr, lprm (DOS) (MIT uses a Kerberized lpd for quota management)
wlprspl (Windows under development)
from (DOS)
CSO client (developed at Brown)
Paul B. Hill
MIT Information Systems
pbh@mit.edu
