1. What is the GSS-API?

The Generic Security Service Application Program Interface (GSS-API) is an IETF standard for an Application Programming Interface (API) for security-related services. Application developers need not write complex security infrastructures in their applications.  Instead, they may take advantage of the GSS-API, which does all of the heavy lifting for them.

2. Key Concepts and Terminology

The ultimate goal of the GSS-API is to establish a security context between two GSS entities through the use of a particular GSS-API Mechanism. In doing so it provides peer entity authentication and per-message data authentication and integrity protection.

2.1. Terminology

Some key terminology used in the GSS-API are:

• Acceptor - The entity that receives the first token of the GSS-API exchange from the Initiator. Usually this is the client software.
• Credentials - Information that proves the identity of a Security Principal.
• Initiator - The entity that sends the first token of the GSS-API exchange to the Acceptor. Usually this is the server software.
• Mechanism - A GSS-API implementation that provides names, tokens and credentials.
• Name - A string that names a security principal. Moonshot uses Network Access Identifiers (NAIs - i.e., user@realm) for naming users.
• Security Principal - A user or a service.
• Tokens - Opaque messages exchanged between GSS-API entities. There are two types: those that make up part of the initial authentication protocol (context-level tokens), and those that are subsequently exchanged as part of a protected communication (per-message tokens).

2.2. GSS-API Mechanisms

Technically, the GSS-API itself doesn't actually do anything - it's an API. Instead, mechanisms of the GSS-API do all of the work. The mechanisms need to be installed as libraries on the systems which wish to make use of them.

Some of the more common GSS-API mechanisms include:

• Kerberos (by far the most common!) (see RFC 1964 and RFC 4121)
• NTLM
• Distributed Computing Environment (DCE)
• SESAME
• SPKM (see RFC 2025)
• LIPKEY (see RFC 2847)

2.3. SPNEGO

The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) is a GSS-API "pseudo mechanism" used by an Initiator and an Acceptor to find out what GSS-API mechanisms they may have in common and to choose one to use. This allows new GSS-API mechanisms to be deployed in a phased manner.

Microsoft's HTTP Negotiate mechanism (see RFC 4559) is an example of an implementation of SPNEGO.

2.4. Find out more

• Wikipedia page for the GSS-API
• IETF RFCS:
  • GSS-API: RFC 2743 (GSS-API version 2 update 1)
  • SPNEGO: RFC 4178

3. Moonshot and the GSS-API

One of the main goals of Moonshot from the very start was to enabled federated authentication to a large number of application protocols. A large number of target applications defined by the ABFAB working group use either the GSS-API, the SSPI, or SASL - so we decided to support these three frameworks.

3.1. How Moonshot uses the GSS-API

RFC 7055 (GSS-EAP) defines an ABFAB mechanism for the GSS-API that in turn uses EAP as its authentication framework; Moonshot is an implementation of that mechanism.

3.2. Where Moonshot uses the GSS-API

The GSS-API is used as one of the methods that applications can integrate with Moonshot. A particular application or service's client and server software (e.g., an SSH client and SSH server, or Microsoft Outlook and Microsoft Exchange) need to both be written to support the GSS-API, and must both be configured to use the GSS-EAP GSS-API mechanism, or capable of using SPNEGO to negotiate its use.

GSS-EAP defines how EAP traffic is carried over the GSS-API. So, when an application client and server have chosen to use GSS-EAP, an EAP transaction is started. The GSS-API is then used as the channel for EAP messages to be carried along between the application client and the server. Once the EAP protocol has concluded, the GSS-API provides the results to the application client and server.

3.3. Further Reading

GSS-EAP is defined in RFC 7055.