Where can I find the "WORKING" Kerberos client code?

[Ken Raeburn]

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
> same?
> 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, 
etc.


I hope this helps.

Ken