Generic Security Services Application Programming Interface

This is an old revision of this page, as edited by 85.18.35.21 (talk) at 11:36, 8 February 2006 (Competing technologies: Ooops). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

The Generic Security Services Application Program Interface (GSSAPI, also GSS-API) is an application programming interface for programs to access security services.

The GSSAPI is an IETF standard that addresses the problem that there are many similar but incompatible security services in use today.

How it works

The GSSAPI, by itself, does not provide any security. Instead, security service vendors provide GSSAPI implementations usually in the form of libraries installed with their security software. These libraries present a GSSAPI-compatible interface to application writers who can write their application to use only the vendor-independent GSSAPI. If the security implementation ever needs replacing, the application need not be rewritten.

The definitive feature of GSSAPI-using software is its exchange of opaque messages (tokens) which hide the implementation detail from the higher level applications. The client and server sides of the application are written to first convey the tokens given to them by their respective GSSAPI implementations. These tokens can be exchanged on an insecure network because they are guaranteed to be inherently secure. After some number of tokens have been exchanged, the GSSAPI implementations at both ends inform their local application that a security context has been established.

Once a security context is established, sensitive application messages can be wrapped (encrypted) by the GSSAPI implementation for secure communication between client and server. Typical protections guaranteed by GSSAPI wrapping include confidentiality (secrecy) and integrity (authenticity). The GSSAPI can also provide local guarantees about the identity of the remote user or remote host.

A sample of some of the 45 standard procedure calls of the GSSAPI include:

  • GSS_Acquire_cred - obtains the user's login proof, often a secret cryptographic key
  • GSS_Import_name - converts a typed username or hostname into a form that identifies a securable entity
  • GSS_Init_sec_context - generates a new token to send to the server
  • GSS_Accept_sec_context - process a token generated by GSS_Init_sec_context and generate a new token to send back
  • GSS_Wrap - convert application data into a secure message (typically encrypt)
  • GSS_Unwrap - convert a secure message back to application data

The GSSAPI has been standardised for the C and Java languages. A standard for C♯ is forthcoming.

Limitations of the GSSAPI include that it standardizes only authentication, and not authorization, and that it assumes a client-server architecture.

When the remote GSSAPI implementation's capabilities are unknown, the local GSSAPI implementation can negotiate a common mechanism by using SPNEGO.

Relationship to Kerberos

The dominant GSSAPI mechanism implementation in use is Kerberos. This can be explained by the observation that the Kerberos API is unstandardized and that there are various incompatible APIs for its implementations.

Competing technologies

RADIUS, SASL, SSL.

The SSPI API found in Microsoft Windows is a competing (and slightly different) implementation of the same logical model behind GSSAPI (RFC 1508). The extension to RFC 1508 that stands out the most is the capability to turn client credentials into a security subject (a token, in Windows parlance) that the server can temporarily use to impersonate the client.

Key concepts of the GSSAPI

Name
A binary string that labels a security principal (i.e. user or service program) - see access control and identity. For example, Kerberos uses names like user@REALM for users and service/hostname@REALM for programs.
Credentials
Information that proves a name. May be used by an entity to act as that principal. Typically this is a secret cryptographic key.
Context
The state of one end of the authenticating/authenticated protocol. Provides a secure channel when established.
Tokens
Opaque messages exchanged as part of the initial authentication protocol.
Mechanism
An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include Kerberos, NTLM,
Initiator/acceptor
The peer that sends the first token is the initiator; the other the acceptor. Generally, the client program is the initiator while the server is the acceptor.