Appendix A Criticism of GSS

The author has doubts whether GSS is the best solution for free software projects looking for a implementation agnostic security framework. We express these doubts in this section, so that the reader can judge for herself if any of the potential problems discussed here are relevant for their project, or if the benefit outweigh the problems. We are aware that some of the opinions are highly subjective, but we offer them in the hope they can serve as anecdotal evidence.

GSS can be criticized on several levels. We start with the actual implementation.

GSS does not appear to be designed by experienced C programmers. While generally this may be a good thing (C is not the best language), but since they defined the API in C, it is unfortunate. The primary evidence of this is the major_status and minor_status error code solution. It is a complicated way to describe error conditions, but what makes matters worse, the error condition is separated; half of the error condition is in the function return value and the other half is in the first argument to the function, which is always a pointer to an integer. (The pointer is not even allowed to be NULL, if the application doesn't care about the minor error code.) This makes the API unreadable, and difficult to use. A better solutions would be to return a struct containing the entire error condition, which can be accessed using macros, although we acknowledge that the C language used at the time GSS was designed may not have allowed this (this may in fact be the reason the awkward solution was chosen). Instead, the return value could have been passed back to callers using a pointer to a struct, accessible using various macros, and the function could have a void prototype. The fact that minor_status is placed first in the parameter list increases the pain it is to use the API. Important parameters should be placed first. A better place for minor_status (if it must be present at all) would have been last in the prototypes.

Another evidence of the C inexperience are the memory management issues; GSS provides functions to deallocate data stored within, e.g., gss_buffer_t but the caller is responsible of deallocating the structure pointed at by the gss_buffer_t (i.e., the gss_buffer_desc) itself. Memory management issues are error prone, and this division easily leads to memory leaks (or worse). Instead, the API should be the sole owner of all gss_ctx_id_t, gss_cred_id_t, and gss_buffer_t structures: they should be allocated by the library, and deallocated (using the utility functions defined for this purpose) by the library.

TBA: specification is unclear how memory for OIDs are managed. For example, who is responsible for deallocate potentially newly allocated OIDs returned as actual_mechs in gss_acquire_cred? Further, are OIDs deeply copied into OID sets? In other words, if I add an OID into an OID set, and modify the original OID, will the OID in the OID set be modified too?

Another illustrating example is the sample GSS header file given in the RFC, which contains:

     /*
      * We have included the xom.h header file.  Verify that OM_uint32
      * is defined correctly.
      */
     #if sizeof(gss_uint32) != sizeof(OM_uint32)
     #error Incompatible definition of OM_uint32 from xom.h
     #endif

The C pre-processor does not know about the sizeof function, so it is treated as an identifier, which maps to 0. Thus, the expression does not check that the size of OM_uint32 is correct. It checks whether the expression 0 != 0 holds.

TBA: thread issues

TBA: multiple mechanisms in a GSS library

TBA: high-level design criticism.

TBA: no credential forwarding.

TBA: internationalization

TBA: dynamically generated OIDs and memory deallocation issue. I.e., should gss_import_name or gss_duplicate_name allocate memory and copy the OID provided, or simply copy the pointer? If the former, who would deallocate that memory? If the latter, the application may deallocate or modify the OID, which seem unwanted.

TBA: krb5: no way to access authorization-data

TBA: krb5: firewall/pre-IP: iakerb status?

TBA: krb5: single-DES only

TBA: the API may block, unusable in select() based servers. Especially if the servers contacted is decided by the, yet unauthenticated, remote client.

TBA: krb5: no support for GSS_C_PROT_READY_FLAG. We support it anyway, though.

TBA: krb5: gssapi-cfx differ from rfc 1964 in the reply token in that the latter require presence of sequence numbers whereas the former doesn't.

Finally we note that few free security applications uses GSS, perhaps the only major exception to this are Kerberos 5 implementations. While not substantial evidence, this do suggest that the GSS may not be the simplest solution available to solve actual problems, since otherwise more projects would have chosen to take advantage of the work that went into GSS instead of using another framework (or designing their own solution).

Our conclusion is that free software projects that are looking for a security framework should evaluate carefully whether GSS actually is the best solution before using it. In particular it is recommended to compare GSS with the Simple Authentication and Security Layer (SASL) framework, which in several situations provide the same feature as GSS does. The most compelling argument for SASL over GSS is, as its acronym suggest, Simple, whereas GSS is far from it.

However, that said, for free software projects that wants to support Kerberos 5, we do acknowledge that no other framework provides a more portable and interoperable interface into the Kerberos 5 system. If your project needs to use Kerberos 5 specifically, we do recommend you to use GSS instead of the Kerberos 5 implementation specific APIs.