1. What is the SSPI?

The Security Support Provider Interface (SSPI) is a Microsoft Windows Application Programming Interface (API) for security related services. Application developers need not write complex security infrastructures in their applications; they simply make calls to the SSPI which does all of the heavy lifting for them.

The SSPI is a proprietary variant of the GSS-API, with some Windows-specific. However, the tokens generated by the GSS-API and the SSPI are largely compatible so in many circumstances the two can interoperate.

2. Key Concepts and Terminology

The key terminology and concepts used in the SSPI are generally very similar to the GSS-API - see Section 2.1 of the GSS-API page for more information.

An SSP mechanism takes the form of a Dynamic Link Library (DLL) that provides one (or more) SSPs to the system.

2.1. Security Support Providers

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

Some of the more common SSPs include:

• Kerberos (by far the most common!) (see RFC 1964 and RFC 4121)
• NTLM
• Negotiate
• Secure Channel (Schannel)

2.2. SPNEGO

The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) (see RFC 4178) 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 that can be used for the SSPI. The original Negotiate package would allow the negotiation of Kerberos, or NTLM if Kerberos was not present. Negotiate also provides a form of Single Sign On (SSO), which is known as "Integrated Windows Authentication". From Windows 7 onwards, NEGOExts has increased the flexibility of potential negotiation, allowing custom SSPs that are installed to be chosen.

3. Moonshot and the SSPI

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 IETF ABFAB working group use either the GSS-API, the SSPI, or SASL, so we decided to support these three frameworks.

The SSPI in particular is used by many applications on Windows written with Kerberos support.

3.1. How Moonshot uses the SSPI

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

3.2. Where Moonshot uses the SSPI

The SSPI 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 SSPI, and must both be configured to use the EAP-SSP mechanism, or capable of using SPNEGO / Negotiate to negotiate its use.

GSS-EAP defines how EAP traffic is carried over the GSS-API, and the EAP-SSP mechanism does the same over the SSPI. So, when an application client and server have chosen to use the EAP-SSP, an EAP transaction is started. The SSPI 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 EAP-SSP provides the results to the application client and server.