Where can I find the "WORKING" Kerberos client code?
raeburn at MIT.EDU
Tue Nov 30 19:25:41 EST 2004
On Nov 30, 2004, at 08:20, Surendra Babu Ande wrote:
> Nice to meet you. I am Surendra from INDIA. We are
> planning to implement Kerberos Client for our Printer
> Network Interface card for pSOS+ environment. Our aim
> is to provide Client and Server authentication.
> Could you please give some pointers to implement the
> Some of our concerns:
> - Where should I find the Client code?
> - And also send us the build procedure.
http://www.mit.edu/~kerberos/ is MIT's main Kerberos web page, and has
links to download instructions for our implementation. The build
process is documented in files included in the distribution.
> - Any Porting issues to be considered?
Yes. Our build procedure currently assumes that the machine used for
building is either a UNIX (or similar) system, or running Windows; it
also assumes that it's a native compilation, not a cross compilation.
I'm not familiar with pSOS, but assuming that you do cross compilation
on another OS, how you deal with that depends on the host system.
UNIX host: The configure script attempts to learn a bunch of attributes
about the host system (program names, availability of header files and
functions and libraries) and uses them to decide how to build the krb5
libraries and programs. Many attributes are tested by running the
compiler with various options and test source files, so if you tell the
configure script to run a cross compiler, it may come up with most of
the right answers, if you can arrange for success and failure
indications to be given at compile/link time. (This probably wouldn't
work well for VxWorks, for example, where symbol resolution is done
when the object code is loaded into the OS.)
The configure script generates include/krb5/autoconf.h to influence
whether certain calls are made or certain headers are included, and
Makefile in each directory to indicate compilation options. Each
source directory has a Makefile.in, and config/pre.in and
config/post.in are incorporated into each generate Makefile. Various
@FOO@ sequences are substituted based on the system attributes or
configure options. (Aside from always using the config/ fragments,
this is typical of GNU Autoconf based software configuration.)
Windows host: The "wconfig" program generates the Makefiles in
subdirectories, with config/win-pre.in and config/win-post.in used in
combination with each Makefile.in, and lines starting "##WIN32##" are
uncommented, but @FOO@ substitutions are not done. Instead of
generating autoconf.h, it's copied from include/win-mac.h, where we've
hardcoded some of the parameters we care about, and just left a bunch
of others out. If you work with a Windows host, you may want to
provide your own makefile fragments, and a replacement for win-mac.h or
some additional data to go into it conditionalized on some preprocessor
symbol for pSOS.
There are also places where we assume that certain header files or
functions are available, because both (most) UNIX and Windows platforms
(that we care about currently) provide them. And probably a handful of
places where we check for _WIN32 to decide between "the Windows way"
and "everything else" (i.e., UNIX); you might need to add a third
branch for pSOS. And some places where we've got hooks for Kerberos
for Mac support, which you can probably ignore.
Our build environment assumes that Perl is available, but it's only
needed in the build process, not for run time. If Tcl is available, on
UNIX, a few more programs may be built that are used for testing some
interfaces, but a cross compiler should notice that it can't link
against the native Tcl libraries, and configure should choose not to
build those programs.
In the current 1.4 beta code, our library wants to find routines for
making DNS queries (SRV and TXT RR queries specifically) that are
outside the scope of getaddrinfo and friends. We also look for
/dev/random as a strong random number source, and text files for
configuration information. Our code assumes that allocating and
reallocating lots of little (or not so little) bits of memory isn't too
horribly expensive, and we don't take any special pains to keep our
stack size small. Depending how pSOS works, you may need to add to the
thread support code. (The MIT code doesn't create threads, but will do
locking and such to allow multiple threads to share global data. The
code in include/k5-thread.h is, uh, kind of involved, and some pains
have been taken to use macros whenever possible to allow assert() calls
during debugging to report useful line numbers.) There are probably
other minor issues to deal with, I'm just making some guesses.
> - what type of Data formats exchanged between Client
> and Server?
If you're aiming for a server implementation only, it'll depend on the
exact protocol you wish to use, but typically the Kerberos application
server needs to accept the AP-REQ message and generate the AP-REP
message. Protection for the data to be transferred depends on on the
application protocol. For example, Kerberos provides some message
types for encapsulating application data with or without encryption;
the Kerberos mechanism for GSSAPI uses the Kerberos session key to
protect application data in a different message format.
The server implementation would also need some secure means of getting
the service principal's key stored away.
If you want client code support as well under pSOS, then you may have
to deal with DNS queries to find the KDC, AS-REQ/AS-REP/TGS-REQ/TGS-REP
message exchanges, and generating AP-REQ and accepting AP-REP messages,
I hope this helps.
More information about the krbdev