GSSAPI

from Wikipedia, the free encyclopedia

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.

functionality

The GSSAPI itself does not offer any security. Instead, various manufacturers offer their security software , often in the form of libraries . These libraries present a GSS-compatible interface for application programmers, who in turn only need to use the manufacturer-independent and standardized GSSAPI. If the implementations of the safety functions have to be replaced at some point, there is no need to change the application.

The most important feature of GSSAPI applications is the exchange of opaque messages (so-called tokens ), which hide the implementation details from the higher layers of the application. The client and server side of the implementation are designed in such a way that they transfer the tokens that the respective GSSAPI implementation provides. GSSAPI tokens can be exchanged over insecure networks (such as the Internet ) because their mechanism guarantees message security . After a certain number of tokens have been exchanged, the GSSAPI informs the respective application on both sides that a secure connection has been installed.

As soon as this secure connection has been established, sensitive messages from the respective application can be encoded in GSSAPI tokens and packed securely between client and server. The typical protection provided by the GSSAPI includes confidentiality (secrecy) and integrity (authenticity). The GSSAPI can also provide local guarantees about the identity of the remote user or computer.

The GSSAPI describes around 45 function calls. The following are particularly important:

  • GSS_Acquire_cred - receives the evidence for the user, often a cryptographic key
  • GSS_Import_name - converts an entered user or host name into an identifiable form
  • GSS_Init_sec_context - generates a new token that is sent to the server
  • GSS_Accept_sec_context - processes a token from GSS_Init_sec_context and generates a new token that can be sent back
  • GSS_Wrap - converts application data into a secure message (typically encrypted)
  • GSS_Unwrap - converts a secure message back into application data

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

A limitation of GSSAPI is that only authentication (authentication), but not authorization (authorization) is standardized; a client-server architecture is still assumed.

Different GSSAPI mechanisms usually do not work together. If various other GSSAPI mechanisms are expected in large, heterogeneous networks in the future, an implementation of SPNEGO on each side of the communication should make sense. This enables common GSSAPI mechanisms to be negotiated securely between two partners (initiator and recipient). Microsoft built SPNEGO into Windows 2000 when Kerberos 5 was added to the existing NTLM SSP mechanism.

Connection to Kerberos

The dominant implementation of the GSSAPI mechanisms currently in use is Kerberos . However, the Kerberos API is not standardized; there are different implementations that use mutually incompatible APIs.

Competing Technologies


Key concepts of the GSSAPI

Surname
a binary string that identifies the principal (user or program) - see Access Control and Identity . As an example, Kerberos uses names like user @ REALM for users and service / hostname @ REALM for programs.
Credentials (legitimation)
Information about identity; are used by an entity as a named principal. Credentials usually contain a cryptographic key.
context
The status of a side of the certified / verified connection. May contain services to protect messages that are used to establish a secure connection.
Token
opaque messages that are exchanged either as part of the initial authentication (context-level token) or as part of the protected communication (per-message token).
mechanism
An underlying GSSAPI implementation that provides names, tokens and credentials. Well known mechanisms include Kerberos, NTLM, DCE , SESAME, SPKM, LIPKEY.
Initiator / recipient
The end that sends the first token is the initiator, the other end is the recipient. Generally, the client is the initiator while the server is the recipient.

History of the 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 is released, 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 of GSSAPI standardized ( RFC 4462 )

Web links