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
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_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
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: 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.