Shishi might have a couple of advantages over other packages doing a similar job.
Anybody can use, modify, and redistribute it under the terms of the GNU General Public License (Appendix D).
The library uses no global variables.
It handles non-ASCII username and passwords and user visible strings used in the library (error messages) can be translated into the users' language.
It should work on all Unix like operating systems, including Windows.
Shishi is far from feature complete, it is not even a full RFC 1510 implementation yet. However, some basic functionality is implemented. A few implemented feature are mentioned below.
Initial authentication (AS) from raw key or password. This step is typically used to acquire a ticket granting ticket and, less commonly, a server ticket.
Subsequent authentication (TGS). This step is typically used to acquire a server ticket, by authenticating yourself using the ticket granting ticket.
Client-Server authentication (AP). This step is used by clients and servers to prove to each other who they are, using negotiated tickets.
Integrity protected communication (SAFE). This step is used by clients and servers to exchange integrity protected data with each other. The key is typically agreed on using the Client-Server authentication step.
Ticket cache, supporting multiple principals and realms. As tickets have a life time of typically several hours, they are managed in disk files. There can be multiple ticket caches, and each ticket cache can store tickets for multiple clients (users), servers, encryption types, etc. Functionality is provided for locating the proper ticket for every use.
Most standard cryptographic primitives. The believed most secure algorithms are supported (Section 2.4).
Telnet client and server. This is used to remotely login to other machines, after authenticating yourself with a ticket.
PAM module. This is used to login locally on a machine.
KDC addresses located using DNS SRV RRs.
Modularized low-level crypto interface. Currently Nettle and Libgcrypt are supported. If you wish to add support for another low-level cryptographic library, you only have to implement a few APIs to DES, AES, MD5, SHA1, HMAC, etc, look at lib/nettle.c or lib/libgcrypt.c as a starting pointer.
The following table summarize what the current objectives are (i.e., the todo list) and an estimate on how long it will take to implement the feature. If you like to start working on anything, please let me know so work duplication can be avoided.
Pre-authentication support (week).
Cross-realm support (week).
PKINIT (use libksba, weeks)
Finish GSSAPI support via GSSLib (weeks) Shishi will not support GSSLib natively, but a separate project "GSSLib" is under way to produce a generic GSS implementation, and it will use Shishi to implement the Kerberos 5 mechanism.
Port to cyclone (cyclone need to mature first)
Modularize ASN.1 library so it can be replaced (days). Almost done, all ASN.1 functionality is found in lib/asn1.c, although the interface is rather libtasn1 centric.
KDC (initiated, weeks)
Set/Change password protocol (weeks?)
Port applications to use Shishi (indefinite)
Improve documentation
Improve internationalization
Add AP-REQ replay cache (week).
Study benefits by introducing a PA-TGS-REP. This would provide mutual authentication of the KDC in a way that is easier to analyze. Currently the mutual authentication property is only implicit from successful decryption of the KDC-REP and the 4 byte nonce.
GUI applet for managing tickets.
Authorization library (months?) The shishi_authorized_p() is not a good solution, better would be to have a generic and flexible authorization library. Possibly based on S-EXP's in tickets? Should support non-Kerberos uses as well, of course.