Generic Security Services Application Programming Interface: Difference between revisions

Revision as of 19:30, 12 September 2006

Revision as of 03:15, 1 October 2006

Line 1:

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 that there areof many similar but incompatible security services in use today.

== How it works ==

Line 9:

If the security implementation ever needs replacing, the application need not be rewritten.

The definitive feature of GSSAPI-using softwareapplications is itsthe exchange of opaque messages (''tokens'')

which hide the implementation detail from the higher level applicationsapplication.

The client and server sides of the application are written to first convey the tokens given to them by

their respective GSSAPI implementations.

These tokens can be exchanged on an insecure network because they are guaranteed by the implementation to be inherently secure.

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.

Line 19:

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.

AThe sampleGSSAPI ofdescribes some of theabout 45 standard procedure calls. ofSignificant the GSSAPIones 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'' - processprocesses a token generated byfrom ''GSS_Init_sec_context'' and generategenerates a new token to send back

* ''GSS_Wrap'' - convertconverts application data into a secure message (typically encrypt)

* ''GSS_Unwrap'' - convertconverts a secure message back tointo application data

The GSSAPI has been standardised for the

Line 38:

The dominant GSSAPI mechanism implementation in use is [[Kerberos (protocol)|Kerberos]].

<!-- Ref: MS Active Directory uses SSPI, MIT and Heimdal provide gssapi -->

This can be explained byUnlike the observation thatGSSAPI, the Kerberos API ishas not been unstandardizedstandardized

and thatvarious thereexisting areimplementations varioususe incompatible APIs for its implementations.

== Competing technologies ==

Line 46:

[[Secure Sockets Layer|SSL]].

The SSPI API found in [[Microsoft Windows]] SSPI is a competing (and slightly different)an implementation of the same logical model behind GSSAPI, (RFCbeing 2743). The extension to RFC 2743 that stands out the most is the capability to turn client credentials into a security subject (a tokenwire-compatible, inbut Windowsincompatible parlance) thatat the server can temporarily use to impersonate theAPI clientlevel.

SSPI was delivered as part of [[Windows NT 4.0]], and has since evolved to match updates to the GSSAPI (e.g. ''ExportSecurityContext'').

A significant feature provided by SSPI is that the operating system will allow a service process to 'impersonate' a remote user when their credentials are delegated.

== 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 (object-oriented programming)|identity]]. For example, [[Kerberos (protocol)|Kerberos]] uses names like ''user@REALM'' for users and ''service/hostname@REALM'' for programs.

;[[Credentials]] :Information that proves aan name. May beidentity; used by an entity to act as thatthe named principal. TypicallyCredentials thistypically isinvolve a secret cryptographic key.

;Context :The state of one end of the authenticating/authenticated [[protocol (computing)|protocol]]. Provides a [[secure channel]] when established.

;Tokens :Opaque messages exchanged as part of the initial authentication protocol.

;Mechanism :An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include [[Kerberos (protocol)|Kerberos]], [[NTLM]].

;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.

== History of the GSSAPI ==

* [[July 1991]: IETF Common Authentication Technology (CAT) Working Group meets in Atlanta, led by John Linn

* [[September 1993]]: GSSAPI version 1 (RFC 1508)

* [[June 1996]]: Kerberos mechanism for GSSAPI (RFC 1964)

* [[July 1996]]: Windows NT 4.0 released, includes SSPI

* [[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)

* [[August 2004]]: KITTEN working group meets to continue CAT activities

* [[May 2006]]: Secure Shell use of GSSAPI standardised (RFC 4462)

== External links ==

* RFC 1509, RFC 1964, and RFC 2743.

* [http://www.ietf.org/html.charters/kitten-charter.html Kitten working group - next generation GSS-API]