Security Support Provider Interface

SSPI is an API used by Microsoft Windows systems to perform a variety of security related operations such as authentication.

SSPI functions as a common interface to several Security Support Providers (SSP) such as:
* NTLM
* Kerberos
* Secure channel (aka SChannel)
* Distributed Password Authentication (DPA)
* Digest access authentication
* Negotiate
* Credential

It is a proprietary variant of GSSAPI with extensions and very Windows-specific data types. It shipped with Windows NT 3.51 and Windows 95 with the NT LAN Manager Security Support Provider (NTLMSSP). For Windows 2000, an implementation of Kerberos 5 was added, using token formats conforming to the official protocol standard RFC 1964 (The Kerberos 5 GSSAPI mechanism) and providing wire-level interoperability with Kerberos 5 implementations from other vendors.

The tokens generated and accepted by the SSPI are mostly compatible with the GSS-API so an SSPI client on Windows may be able to authenticate with a GSS-API server on UNIX depending on the specific circumstances.One significant shortcoming of SSPI is its lack of explain|channel bindings|Channel binding is a way to cryptographically bind end-to-end authentication at the application layer to a secure channel at a lower layer. This cryptographic binding is a way to eliminate man-in-the-middle attacks in that secure channel. It is particularly useful to applications that intend to rely on TLS or IPsec for session/transport security. Channel bindings also stimulate the development of APIs for IPsec and an unauthenticated mode of IPsec., which makes some GSSAPI interoperability impossible.

Another fundamental difference between the IETF-defined GSSAPI and Microsoft's SSPI is the concept of "impersonation". In this model, a server can switch to and operate with the FULL privileges of the authenticated client, so that the operating system performs all access control checks, e.g. when opening new files. Whether these are less privileges or more privileges than that of the original service account depends entirely on which client connects/authenticates. In the traditional (GSSAPI) model, a server runs under a service account, cannot elevate its privileges, and has to perform access control in a client-specific and application-specific fashion. The obvious negative security implications of the impersonation concept are mitigated in the most recent version of Windows by restricting impersonation to selected service accounts.

See also

* Security Support Provider
* Integrated Windows Authentication

External links

* [http://msdn2.microsoft.com/en-us/library/aa380493.aspx SSPI Reference on MSDN]
* [http://win32.mvps.org/security/sspi.html SSPI Information and Win32 samples]