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 which 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 usually travel over an insecure network as the mechanisms provide inherent message security. After the exchange of some number of tokens, the GSSAPI implementations at both ends inform their local application that a security context is established. Once a security context is established, sensitive application messages can be wrapped by the GSSAPI for secure communication between client and server. Typical protections guaranteed by GSSAPI wrapping include confidentiality and integrity. 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 identity proof, often a secret cryptographic key ; GSS_Import_name: Converts a username or hostname into a form that identifies a security entity ; GSS_Init_sec_context: Generates a client token to send to the server, usually a challenge ; GSS_Accept_sec_context: Processes a token from GSS_Init_sec_context and can generate a response token to return ; GSS_Wrap: Converts application data into a secure message token ; GSS_Unwrap: Converts a secure message token back into application data The GSSAPI is standardized for the C language. Java implements the GSSAPI as JGSS, the Java Generic Security ServicesApplication Program Interface. Some Limitation of GSSAPI are:
Anticipating new security mechanisms, the GSSAPI includes a negotiating pseudo mechanism, SPNEGO, that can discover and use new mechanisms not present when the original application was built.
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. The GSSAPI allows Kerberos implementations to be API compatible.
;Name :A binary string that labels a security principal - 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. May provide message protection services, which can be used to compose a secure channel. ;Tokens :Opaque messages exchanged either as part of the initial authentication protocol, or as part of a protected communication ;Mechanism :An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include Kerberos, NTLM, Distributed Computing Environment, SESAME, SPKM, LIPKEY. ;Initiator/acceptor :The peer that sends the first token is the initiator; the other is the acceptor. Generally, the client program is the initiator while the server is the acceptor.
History
July 1991: IETF Common Authentication Technology Working Group meets in Atlanta, led by John Linn