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

Revision as of 09:36, 18 February 2005

Latest revision as of 19:40, 25 March 2025

(11 intermediate revisions by 9 users not shown)

Line 1:

{{WikiProject banner shell|class=Start|

== Copyright ==

{{WikiProject Computing|importance=mid}}

{{WikiProject Cryptography |importance=Low}}

}}

{{Technical|date=September 2010}}

== List of GSSAPI implementations ==

This article appears to have been taken in its entirety from the [http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#gssapi Kerberos FAQ]. That FAQ has the following copyright notice: ''(c) 2000 United States Government as represented by the Secretary of the Navy. All rights reserved.'', which I take to mean that it's not in the public ___domain like some U.S. Government works.

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

We could still do with a good article on GSSAPI (I'm particularly interested in its de-facto relationship to Kerberos).

I could find the following public ones:

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

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

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

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

-- [[User:JTN|JTN]] 12:18, 2005 Feb 10 (UTC)

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)

I have added a new version of the GSSAPI Text, this time copyrighted by myself ;-) Sorry for inconveniences because of that.

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.