World Library  
Flag as Inappropriate
Email this Article


Article Id: WHEBN0001521174
Reproduction Date:

Title: Gssapi  
Author: World Heritage Encyclopedia
Language: English
Subject: SOCKS, Secure copy, Simple Authentication and Security Layer, Integrated Windows Authentication, AbsoluteTelnet, SecureCRT
Publisher: World Heritage Encyclopedia


The Generic Security Service 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 usually be sent over an insecure network as the mechanisms provide inherent message security. 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 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 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 (typically encrypted)
  • GSS_Unwrap - converts a secure message token back into application data

The GSSAPI has been standardized for the JSR-072) languages.

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

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.

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. The GSSAPI allows Kerberos implementations to be API compatible.

Related technologies

Key concepts

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.
Information that proves an identity; used by an entity to act as the named principal. Credentials typically involve a secret cryptographic key.
The state of one end of the authenticating/authenticated protocol. May provide message protection services, which can be used to compose a secure channel.
Opaque messages exchanged either as part of the initial authentication protocol (context-level tokens), or as part of a protected communication (per-message tokens)
An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include Kerberos, NTLM, Distributed Computing Environment (DCE), SESAME, SPKM, LIPKEY.
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.


  • July 1991: IETF Common Authentication Technology (CAT) Working Group meets in Atlanta, led by John Linn
  • September 1993: GSSAPI version 1 (RFC 1508, RFC 1509)
  • May 1995: Windows NT 3.51 released, includes SSPI
  • June 1996: Kerberos mechanism for GSSAPI (RFC 1964)
  • 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, RFC 2744)
  • August 2004: KITTEN working group meets to continue CAT activities
  • May 2006: Secure Shell use of GSSAPI standardised (RFC 4462)

See also

  • PKCS #11

External links

  • RFC 2743 The Generic Security Service API Version 2 update 1
  • RFC 2744 The Generic Security Service API Version 2: C-Bindings
  • RFC 1964 The Kerberos 5 GSS-API mechanism
  • RFC 4121 The Kerberos 5 GSS-API mechanism: Version 2
  • RFC 4178 The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
  • RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM)
  • RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
  • Kitten working group - next generation GSS-API
  • GSS-API Programming Guide from Oracle

Template:Authentication APIs

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.