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 of 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 applications is the exchange of opaque messages (tokens) that hide the implementation detail from the higher level application. The client and server sides of the application are written to convey the tokens given to them by their respective GSSAPI implementations. GSSAPI tokens can be sent over an insecure network because the mechanisms guarantee inherent message security. After some number of tokens have been exchanged, the GSSAPI 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 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.
The GSSAPI describes about 45 procedure calls. Significant ones 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 - processes a token from GSS_Init_sec_context and generates a new token to send back
- GSS_Wrap - converts application data into a secure message (typically encrypted)
- GSS_Unwrap - converts a secure message back into 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. Unlike the GSSAPI, the Kerberos API has not been standardized and various existing implementations use incompatible APIs.
Competing technologies
The Microsoft Windows SSPI is an implementation of the same logical model behind GSSAPI, being wire-compatible, but incompatible at the API level. SSPI was delivered as part of Windows NT 4.0, and has since evolved to match updates to the GSSAPI (e.g. ExportSecurityContext). A significant feature provided by SSPI is that the operating system will allow a service process to 'impersonate' a remote user when their credentials are delegated.
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 an identity; used by an entity to act as the named principal. Credentials typically involve 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.
History of the GSSAPI
- July 1991: IETF Common Authentication Technology (CAT) Working Group meets in Atlanta, led by John Linn
- September 1993: GSSAPI version 1 (RFC 1508)
- June 1996: Kerberos mechanism for GSSAPI (RFC 1964)
- July 1996: Windows NT 4.0 released, includes SSPI
- January 1997: GSSAPI version 2 (RFC 2078)
- October 1997: SASL published, includes GSSAPI mechanism (RFC 2222)
- January 2000: GSSAPI version 2 update 1 (RFC 2743)
- August 2004: KITTEN working group meets to continue CAT activities
- May 2006: Secure Shell use of GSSAPI standardised (RFC 4462)