Generic Security Services Application Program Interface

From Wikipedia, the free encyclopedia

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.

Contents

[edit] 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.

Different GSS-API mechanisms are usually non-interoperable. When the future addition of other GSS-API mechanisms into a large heterogenous landscape is anticipated, it might be wise to deploy SPNEGO on every communication peer from the beginning so that a common GSS-API mechanism can be securely negotiated between communication peers (initiator and acceptor). Microsoft included SPNEGO with Microsoft Windows 2000 when they added Kerberos5 to the existing NTLM SSP/mechanism.

[edit] 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.

[edit] Competing technologies

RADIUS, SASL, SSL.

The Microsoft Windows Security Service Provider Interface (SSPI) is a proprietary variant of GSS-API with extensions and very Windows-specific data types. It was shipped with Windows NT 3.51 and Windows 95 with the NT LAN Manager Security Support Provider (NTLM SSP). For Windows 2000 an Implementation of Kerberos 5 was added, using token formats conforming to the official protocol standard RFC 1964 (The Kerberos 5 GSS-API mechanism) and providing wire-level interoperability with Kerberos 5 implementations from other vendors. One significant shortcoming of SSPI is its lack of channel bindings, which may preclude interoperability for some GSS-API enabled application protocols.

One fundamental difference between the IETF-defined GSS-API and Microsoft's SSPI is the concept of "impersonation". In this model, a server can switch to and operate with the FULL privileges of the authenticated client, so that the Operating system performs all access control checks, e.g. when opening new files. Whether these are less privileges or more privileges than that of the original service account depends entirely on which client connects/authenticates. In the traditional (GSS-API) model, a server runs under a service account, can not elevate its privileges, and has to perform access control in a client- and application-specific fashion. The obvious negative security implications of the impersonation concept are mitigated in the most recent version of Windows by restricting impersonation to selected service accounts.

[edit] 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. 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 (context-level tokens), or as part of a protected communication (per-message tokens)
Mechanism 
An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include Kerberos, NTLM, Distributed Computing Environment(DCE), SESAME, SPKM, LIPKEY.
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.

[edit] History of the GSSAPI

[edit] External links