Talk:Generic Security Services Application Programming Interface: Difference between revisions

Revision as of 03:36, 1 October 2006

Latest revision as of 19:40, 25 March 2025

(8 intermediate revisions by 7 users not shown)

Line 1:

{{WikiProject banner shell|class=Start|

{{technical}}

{{WikiProject Computing|importance=mid}}

{{WikiProject Cryptography |importance=Low}}

}}

{{Technical|date=September 2010}}

== List of GSSAPI implementations ==

== Kerberos relationship ==

I think the article would do well with a list of known GSSAPI implementors.

From what I have seen, the reasons why gssapi is used when kerberos is available are

I could find the following public ones:

* the Kerberos API is absolutely attrocious for common use, unless you're very keen on the low level stuff. gss is simpler

*Heimdal[http://www.pdc.kth.se/heimdal/heimdal.html],

* most krb5 implementations come with gssapi anyway, and the concepts map well between the two

*MIT[http://web.mit.edu/Kerberos/],

* the krb5 C API moves too much. The schism between mit and heimdal krb5 apis is an enormous driver of people towards gssapi.

*Globus [http://www.globus.org/toolkit/security/standards/],

* microsoft has built-in api called SSPI which is basically GSSAPI in disguise (wire compatible, but uses different named functions) and it uses their krb5 implementation ("active directory") as well as snego.

*Shishi [http://www.gnu.org/software/shishi/],

*SSPI [http://msdn.microsoft.com/library/en-us/secauthn/security/authentication_functions.asp] (wire-compat only),

*SAP [ftp://ftp.sap.com/pub/ietf-work/gssapi/gsskrb5/],

**SAP is not a GSS-API implementation; it simply uses GSS-API [[User:SamHartman|SamHartman]] 21:28, 16 October 2007 (UTC)

but who else?

- [[User:Dleonard|DLeonard]] 04:42, 1 October 2006 (UTC)

As for mechanisms, Martin Rex in Nov 2004 wrote to kitten-at-ietf.org with this info:

-- DLeonard

I was surprized how many independent (mostly proprietary) implementations

of gssapi mechanism exist. I got to know then only because the vendors

asked for interoperability certification of their product with our

application. I don't know how many of them (if any) are or have

ever participated in IETF activities. Here's a quick list of companies:

ietf mechanism: Company (Country)

Kerberos 5 MIT, CyberSafe, CA/Platinum, Microsoft, heimdal

SPKM Entrust (CA), Shym (US), Baltimore (US)

proprietary mechanisms:

AM-DCE Bull (FR)

(propr.) Sagem (FR)

sdti,rsakeon,trustnet TFS-Tech (SE) former RSA/SDTI

safelayer Safelayer (SP)

NEC Secureware NEC (JP)

itsec UBS/ITsec (CH)

Adnovum GSSv2 UBS/Adnovum (CH)

ISign/secui Penta Security Systems (South Korea)

Sisler Siemens India (India)

cpro Mecomp (RU)

lissi Lissi (RU)

kobil Kobil GmbH (DE)

T-Secure secunet/Telekom (DE)

how many do you recognize?

==Problems With the Article==

I read the article and noticed several problems that I don't have time to work on now so I decided to document them.

* I don't understand how [[RADIUS]]is a competing technology

* I think the proper abbreviation is GSS-API not GSSAPI; see RFC 2743.

* I'm not convinced that impersonationa is incompatible with IETF GSS-API. in particular GSS-API does provide a credential delegation mechanism. The only interisting thing behind impersonation is that you are able to tell the local OS to use the credential for everything including local access checks. For every GSS-API operation you can use the delegated credential just as in Windows. However you need a specific OS call to use that for local operations and that is in fact outside the scope of GSS-API.