3.4 The Alphabet Soup of Kerberos-Related Protocols

Finally, there are several protocols that, while strictly speaking are not directly related to Kerberos, will be encountered when implementing a Kerberos authentication system.

3.4.1 The Generic Security Services API (GSSAPI)

The Generic Security Services API, as the name implies, is not specific to any authentication technique. Therefore, its mention in a book on Kerberos may seem a bit out of place. However, GSSAPI is widely used by protocol implementers as a means to implement Kerberos 5 support in their applications. By using GSSAPI, a protocol gains the ability to use other strong authentication methods "for free," and the GSSAPI layer also shields implementers from the complexities of the raw Kerberos 5 API.

GSSAPI is geared toward developers of client/server applications who wish to add strong authentication support to their protocols. It provides a generic interface and message format that can encapsulate authentication exchanges from any authentication method that has a GSSAPI-compliant library. GSSAPI insulates application programmers from the specific programming interface for particular authentication methods. GSSAPI also provides a standard message format so that protocols can support many different authentication methods without changing the protocol itself. GSSAPI does not define a protocol, authentication, or security mechanism itself; it instead makes it easier for application programmers to support multiple authentication mechanisms by providing a uniform, generic API for security services.

Most Kerberos 5 implementations also include a GSSAPI library. This means that all applications that support GSSAPI also support Kerberos 5. The notable exception is the Windows Kerberos implementation, which does not include GSSAPI support but instead includes a Microsoft-specific API, the Security Support Provider Interface (SSPI). SSPI is not API-compatible with GSSAPI; that is, programs written for GSSAPI will not compile with SSPI. Instead, applications written for SSPI can be made to be wire-compatible with GSSAPI applications. Therefore, an SSPI client can communicate with a GSSAPI server. Microsoft provides some example code that demonstrates how to achieve this network message-level interoperability.

While GSSAPI is mostly standardized, there are still some differences between the C language bindings of the available implementations, particularly the MIT and Heimdal implementations of GSSAPI. During the configuration stage, most open source software will detect which GSSAPI implementation you have and compile the appropriate code to work with it, but some software may only work with one or the other. Work to unify these APIs is ongoing.

The relevant standards documents defining GSSAPI include RFC 2743, which documents the basic GSSAPI message types, RFC 1509, which defines the C language bindings and API, and RFC 1964, which defines the Kerberos 5 GSSAPI mechanism.

3.4.2 The Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)

GSSAPI solves the problem of providing a single API to different authentication mechanisms. However, it does not solve the problem of negotiating which mechanism to use. Indeed, for GSSAPI to work, the two applications communicating with each other must know and agree ahead of time what authentication mechanism they plan to use. Since most GSSAPI implementations only support one mechanism anyway (namely, Kerberos 5), this is usually not a problem. However, if there are multiple mechanisms to choose from, a method is needed to securely negotiate an authentication mechanism that is mutually supported between both client and server. SPNEGO, documented in RFC 2478, performs this function.

Microsoft includes an implementation of SPNEGO in its Kerberos and SSPI implementation in Windows 2000 and above. Currently there is no widely accepted open source SPNEGO implementation for Unix, but work is ongoing to produce one. In addition, Microsoft has some sample code on its web site that provides a simple way to parse SPNEGO messages as part of its three-part article on HTTP authentication through the Negotiate protocol, available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/http-sso-1.asp. Many Microsoft-based products, including Exchange SMTP, file services through SMB, and web authentication with IE and IIS, use SPNEGO to negotiate an authentication mechanism.