The intention with this section is to discuss various problems with Kerberos 5, so you can form a conscious decision how to deploy and use Shishi correctly in your organization. Currently the issues below are condensed, and mostly serve as a reminder for the author to elaborate on them.
No encryption scheme with security proof.
No standardized API, and GSS mechanism lack important functionality.
Lack of authorization system. (krb5_kuserok())
Host to realm mapping relies on insecure DNS or static configuration files.
Informational model and user database administration.
Non-formal specification. Unclear on the etype to use for session keys (etype in request or database?). Unclear on how to populate some “evident” fields (e.g., cname in tickets for AS-REQ, or crealm, cname, realm, sname, ctime and cusec in KRB-ERROR). Unclear error code semantics (e.g., logic for when to use S_PRINCIPAL_UNKNOWN absent). Some KRB-ERROR fields are required, but can't be usefully populated in some situations, and no guidance is given on what they should contain.
RFC 1510/1510bis incompatibilities. NULL enctype removed without discussion, and it is still used by some 1964 GSSAPI implementations. KRB_SAFE text (3.4.1) says the checksum is generated using the session or sub-session key, which contradicts itself (compare section 3.2.6) and also RFC 1510, which both allow the application to define the key. Verification of KRB_SAFE now require the key to be compatible with the (sub-)session key, in 1510 the only requirement was that it was collision proof.
Problems with RFC 1510bis. Uses bignum INTEGER for TYPED-DATA and AD-AND-OR.
Problems with crypto specification. It uses the word “random” many times, but there is no discussion on the randomness requirements. Practical experience indicate it is impossible to use true randomness for all “random” fields, and no implementation does this. A post by Don Davis on the ietf-krb-wg list tried to provide insight, but the information was never added to the specification.