1.2 Features and Status

Shishi might have a couple of advantages over other packages doing a similar job.

It's Free Software

Anybody can use, modify, and redistribute it under the terms of the GNU General Public License (see GNU GPL).

It's thread-safe

The library uses no global variables.

It's internationalized

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's portable

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 (see Cryptographic Overview).
• 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 Gnulib and Libgcrypt are supported. If you wish to add support for another low-level cryptographic library, you only have to implement a few APIs for DES, AES, MD5, SHA1, HMAC, etc. Look at gl/gc-gnulib.c or gl/gc-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, including some reasonable startup-time to get familiar with Shishi in general. If you like to start working on anything, please let me know so work duplication can be avoided.

• Parse /etc/krb5.keytab to extract keys to use for telnetd etc (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)
• LDAP backend for Shisa.
• Set/Change password protocol (weeks?)
• Port applications to use Shishi (indefinite)
• Finish server-realm stuff
• 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. This is supported via the ticket-applet, of which a Shishi port is published on the Shishi home page.
• 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.
• Proof read manual.
• X.500 support, including DOMAIN-X500-COMPRESS. I will accept patches that implement this, if it causes minimal changes to the current code.