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 version 3.0 or later.
- 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 4120
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.