Generic Security Services Application Programming Interface: Difference between revisions

Revision as of 19:55, 24 October 2006

Latest revision as of 00:59, 11 April 2025

(76 intermediate revisions by 61 users not shown)

Line 1:

{{Short description|Application programming interface}}
{{more footnotes|date=October 2013}}
The '''Generic Security ServicesService Application ProgramProgramming 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{{Asof|2005|lc=y}}.

== How it worksOperation ==

The GSSAPI, by itself, does not provide any security. Instead, security-service vendors provide GSSAPI ''implementations'' - usually in the form of [[Library (computer science)|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 [[Standardization|vendor-independent]] GSSAPI.

The GSSAPI, by itself, does not provide any security.

Instead, security service vendors provide GSSAPI ''implementations'' usually in the form of [[Library (computer science)|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 [[Standardization|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'') which hide the implementation detail from the higher-level application.

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 beusually senttravel over an insecure network becauseas the mechanisms guaranteeprovide inherent message security.

After somethe numberexchange of tokenssome havenumber beenof exchangedtokens, the GSSAPI implementations at both ends inform their local application that a ''security context'' has beenis 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 [[Data integrity|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'' -: obtainsObtains the user's loginidentity proof, often a secret cryptographic key

*; ''GSS_Import_name'': - convertsConverts a typed username or hostname into a form that identifies a securablesecurity entity

*; ''GSS_Init_sec_context'': - generatesGenerates a newclient token to send to the server, usually a challenge

*; ''GSS_Accept_sec_context'' -: processesProcesses a token from '''GSS_Init_sec_context''' and generatescan generate a newresponse token to send backreturn

*; ''GSS_Wrap'': - convertsConverts application data into a secure message token (typically encrypted)

*; ''GSS_Unwrap'': - convertsConverts a secure message token back into application data

The GSSAPI is standardized for the [[C (programming language)|C]] (RFC 2744) language. [[Java (programming language)|Java]] implements the GSSAPI<ref>{{cite web

The GSSAPI has been standardised for the

| url=https://jcp.org/aboutJava/communityprocess/review/jsr072/index.html

[[C (programming language)|C]] and [[Java (programming language)|Java]] languages.

| title=JSR-000072 Generic Security Services API Specification 0.1

A standard for [[C Sharp|C#]] is forthcoming.

| date=2001-06-15

| access-date=2015-10-07}}</ref>

as JGSS,<ref>{{cite book

| last1 = Schönefeld

| first1 = Marc

| title = Refactoring of Security Antipatterns in Distributed Java Components

| url = https://books.google.com/books?id=cUWFz3oZLyAC

| series = Schriften aus der Fakultät Wirtschaftsinformatik und Angewandte Informatik der Otto-Friedrich-Universität Bamberg

| volume = 5

| publisher = University of Bamberg Press

| date = 2010

| page = 179

| access-date = 2015-10-07

| quote = JGSS is the JAVA implementation of the GSSAPI.

| isbn = 9783923507689}}</ref>

the Java Generic Security Services Application Program Interface.<ref>{{cite book

| last1 = Fisher

| first1 = Marina

| last2 = Sharma

| first2 = Sonu

| last3 = Lai

| first3 = Ray

| last4 = Moroney

| first4 = Laurence

| title = Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices

| url = https://books.google.com/books?id=CXnCJhrB3g4C

| publisher = Prentice Hall Professional

| date = 2006

| access-date = 2015-10-07

| quote = Java Generic Security Services Application Program Interface (JGSS) API for uniform access to security services atop a variety of underlying security mechanism, including Kerberos, which are building blocks for single sign-on and data encryption.

| isbn = 9780132715706}}</ref>

<!-- A standard for [[C Sharp|C#]] is forthcoming. C# work appears to have perished -->

Some limitations of GSSAPI are:

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

# standardizing only [[authentication]], rather not [[authorization]] too;

# assuming 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.

When the remote GSSAPI implementation's capabilities are unknown, the local GSSAPI implementation can negotiate a common mechanism by using [[SPNEGO]].

== Relationship to Kerberos ==

Line 40 ⟶ 73:

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.

== CompetingRelated technologies ==

* [[Remote Authentication Dial In User Service|RADIUS]]

[[RADIUS]],

* [[Simple Authentication and Security Layer|SASL]]

[[SASL]],

* [[Secure Sockets Layer|SSLTLS]].

* [[Security Support Provider Interface|SSPI]]

* [[SPNEGO]]

* [[RPCSEC GSS]]

== Key concepts ==

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

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

One significant shortcoming of SSPI is its lack of channel bindings, which may preclude interoperability for some GSS-API enabled application protocols.

;[[Credential]]s :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 (computing)|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 (protocol)|Kerberos]], [[NTLM]], [[Distributed Computing Environment]] (DCE), SESAME, [[SPKM]], LIPKEY.

;Initiator/acceptor :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.

== History ==

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.

* 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==

== Key concepts of the GSSAPI ==

*[[PKCS 11|PKCS #11]]

;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 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 (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]], [[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.

== History of the GSSAPIReferences ==

{{Reflist}}

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

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

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

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

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

== External links ==

* RFC{{IETF RFC|2743|link=no}} The Generic Security Service API Version 2 update 1

* RFC{{IETF RFC|2744|link=no}} The Generic Security Service API Version 2: C-Bindings

* RFC{{IETF RFC|1964|link=no}} The Kerberos 5 GSS-API mechanism

* RFC{{IETF RFC|4121|link=no}} The Kerberos 5 GSS-API mechanism: Version 2

* RFC{{IETF RFC|4178|link=no}} The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)

* RFC{{IETF RFC|2025|link=no}} The Simple Public-Key GSS-API Mechanism (SPKM)

* RFC{{IETF RFC|2847|link=no}} LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM

* {{cite web

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

| url=https://datatracker.ietf.org/wg/kitten/charter/

| title=Common Authentication Technology Next Generation (kitten)

| date=September 2013

| publisher=[[Internet Engineering Task Force]]}}

* {{cite web

| url=https://docs.oracle.com/cd/E19683-01/816-1331/

| title=GSS-API Programming Guide — Sun Solaris 9

| date=2002

| author=Sun Microsystems

| author-link=Sun Microsystems

| publisher=[[Oracle Corporation]]}}

* {{cite web

| url=https://docs.oracle.com/cd/E37838_01/html/E61050/secov-gss.html

| title=Writing Applications That Use GSS-API — Oracle Solaris 11.4, Developer's Guide to Security

| date=2020

| author=Oracle Corporation

| author-link=Oracle Corporation}}

{{Authentication APIs}}

[[Category:Operating system security]]

[[Category:Internet standardsStandards]]