From: Jim Doyle <jrd@bu.edu>

     In the Kerberos V5 distribution, I believe there is a s
     simple-server/simple-client pair that demonstrates the code
     skeleton needed to implemented per-connection authentication.

     A word of caution to new Kerberizers of applications. :) Dont just
     go off and craft your product's Kerberos implementation around one
     day's worth of hacking on the V5 demo examples... Take the time to
     understand all the subtleties of the protocol and all of the
     features of design in V5 that you have available to you.

     Some common mistakes that newbies do when they Kerberize their
     first client-server application:

       1. They hard-code various things into their code, such as the
          location of the keytab file, or the server's principal name.
          Bad ideas. Consider that people may want to put the keytab
          files in places other than your products' installation
          directory.

          Further, you should also make sure that end-users can choose
          whatever principal name they wish for each server instance...
          This has a side effect that the client side protocol needs to
          be able to discover the principal name of the server process
          before getting and sending an authenticator. Without the
          ability to choose principal names, it may be difficult to
          multiply-instantiate servers in a Kerberos realm.

       2. Put lots of debugging trace statements in your
          implementation. These are invaluable for diagnosing Kerberos
          related problems once your product is in deployment.

       3. Consider using generic GSSAPI services.

Another point worth mentioning is that if you are using a standardized
protocol (such a POP, IMAP, etc etc) it is strongly recommended that you
work within the framework of that protocol. In the case of protocols like
POP and IMAP, there is already a standard authentication framework into
which Kerberos fits. This saves you the work of having to design a protocol
for your application. This doesn't apply to custom protocols developed
internally, of course, but the design decisions made for standardized
protocols might give you some ideas to apply to your own protocol.