Generic Security Services Application Program Interface

The Generic Security Service Application Program Interface ( GSSAPI, also GSS- API) is a programming interface for applications that access security devices.

The GSSAPI is an IETF standard that addresses the problem of many different, sometimes incompatible security devices.

Operation

The GSSAPI itself provide any security. Instead, offer a variety of manufacturers to their security software, often in the form of libraries. These libraries present a GSS- compatible interface for application programmers who in turn have to use only manufacturer- independent, standardized GSSAPI. If the implementations of the safety functions must be eventually replaced, it requires no modification to the application.

The most important feature of GSSAPI applications is the exchange of opaque messages ( so called tokens) that hide the implementation details from the higher layers of the application. The client and server side of the implementation are designed to transmit the token that provides the respective GSSAPI implementation. GSSAPI tokens can be exchanged over insecure networks ( like the Internet ), because their mechanism ensures message security. After a certain number of tokens has been replaced, the GSSAPI information on both sides of the application that a secure connection has been installed.

Once this secure connection is established, sensitive messages the application tokens in the GSSAPI can be encrypted and packed securely transmitted between client and server. The typical protection that is provided by the GSSAPI, trust includes ( confidentiality ) and integrity ( authenticity ). The GSSAPI can also provide local guarantees about the remote user or host identity.

The GSSAPI describes about 45 function calls. Of particular importance are:

  • GSS_Acquire_cred - receives the proof for the user, often a cryptographic key
  • GSS_Import_name - converts an input user or host name in an identifiable form
  • GSS_Init_sec_context - generates a new token that is sent to the server
  • GSS_Accept_sec_context - edited a token of GSS_Init_sec_context and generates a new token that can be returned
  • GSS_Wrap - convert application data in a secure message (typically encrypted)
  • GSS_Unwrap - converts a secure message back to application data

The GSSAPI is standardized for C and Java. A standard for C # is in development.

A limitation of the GSSAPI is that only the authentication ( legalization ), but not the authorization ( permission ) is standardized to continue a client-server architecture is adopted.

Various GSSAPI mechanisms do not usually work together. When various other GSSAPI mechanisms are expected in large, heterogeneous networks for the future, is likely to be useful to an implementation of SPNEGO on each side of the communication. This allows common GSSAPI mechanisms are negotiated safely between two parties (initiator and receiver). Microsoft has SPNEGO installed in Windows 2000, has been added as Kerberos 5 to the existing NTLM SSP mechanism.

Connect to Kerberos

The dominant implementation of the GSSAPI mechanism, which is currently used, is Kerberos. The Kerberos API is not standardized, there are different implementations employing mutually incompatible APIs.

Competing technologies

  • Remote Authentication Dial- In User Service ( RADIUS)
  • Simple Authentication and Security Layer ( SASL )
  • Secure Sockets Layer ( SSL)
  • Security Support Provider Interface ( SSPI ) is a published Microsoft's proprietary variant of the GSSAPI

Key Concepts of the GSSAPI

History of GSSAPI

  • July 1991: The 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 appears, contains SSPI
  • June 1996: Kerberos mechanism for GSSAPI (RFC 1964)
  • January 1997: GSSAPI Version 2 (RFC 2078 )
  • October 1997: SASL published contains GSSAPI mechanisms (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 the GSSAPI standardized ( RFC 4462 )
Tokenization Client (computing) C Sharp (programming language) Kerberos (protocol) NT LAN Manager Transport Layer Security Access control Distributed Computing Environment
284008
de