[3345] in Kerberos
Re: GSS-API - part of Kerberos ???
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Sun May 29 11:07:31 1994
To: kerberos@MIT.EDU
Date: 29 May 1994 14:48:02 GMT
From: jik@cam.ov.com (Jonathan I. Kamens)
In article <CqF6wE.8Ln@cup.hp.com>, skup@cup.hp.com (Irene_Skupniewicz) writes:
|> GSS-API is a specification for an API to a generic security service.
|> It was originally developed by DEC and is now accepted as an Internet
|> standard.
Both assertions in the latter sentence above are incorrect.
First of all, GSS-API was not "developed" by DEC. It was developed by the
Common Authentication Technology Working Group (CAT WG) of the Internet
Engineering Task Force (IETF). The CAT WG is chaired by John Linn, who
currently works for OpenVision (in the division of OpenVision that used to be
Geer Zolot Associates). Although some members of the CAT WG may work for DEC
(in fact, I believe that John Linn worked there before he came to OV), it is
certainly inaccurate to claim that GSS-API was "originally developed by DEC".
The IETF cannot be said to be under the auspices of any one particular vendor.
Second, GSS-API is not yet an Internet Standard. RFCs 1508 and 1509, which
document the abstract API and the C bindings to it, have the status of
Proposed Standard. There will be new revisions of both of them, because the
CAT WG has discussed and approved changes since the RFCs were released, and
then those changed versions will be released with new RFC numbers, again as
Proposed Standards. Once the CAT WG decides that no required changes to the
Porposed Standards have become evident for a long enough period of time, they
will be promoted to Internet Standards.
|> Also, Kerberos V5.1 is
|> expected to have hooks in for GSS-API.
I don't know exactly what you mean by "Kerberos V5.1". The MIT Kerberos 5
beta 3 release already has OpenVision's GSS-API implementation included with
it, and future MIT releases will continue to have our implementation.
Furthermore, I believe that future MIT releases will have DEC's GSS-API
implementation as well (I don't believe that beta 3 did).
I'm also not sure what you mean by "hooks in for GSS-API". In Kerberos 5, at
least, no "hooks" are required for a GSS-API implementation. GSS-API is a
library that sits on top of the standard Kerberos 5 API functions. No
modifications have been made or need to be made to the base Kerberos 5 code in
order to support the Kerberos 5 GSS-API mechanism.
|> Since GSS-API is a definition only, I researched what implementations
|> exist out there. For non-DCE platforms I found only two: Open*Secure
|> from OpenVision and NetSP from IBM.
I believe that DEC's GSS-API implementation supports non-DCE platforms.
Furthermore, I believe that Cybersafe (nee OCSG) sells a GSS-API
implementation that is independent of either DEC's or OV's.
Now, since other people have seen fit to post their responses to the initial
query, despite the fact that the original poster asked for responses to be
mailed, I guess I'll post my response as well :-). I responded to him in
E-mail as follows.
*****
The acronym GSS-API stands for Generic Security Services Application Program
Interface. It's an API designed by the common authentication technology (CAT)
working group within IETF, the Internet Engineering Task Force. It currently
has the status of proposed standard, and has been published as Internet RFC
1508, which documents the abstract API, and Internet RFC 1509, which documents
the C language bindings for it. The chairman of the CAT WG, who is also the
author of RFC 1508, is John Linn, who works for OV in Cambridge (the office
where I work).
The best way to explain what GSS-API is is to quote the beginning of the
abstract in RFC 1508:
This Generic Security Service Application Program Interface (GSS-API)
definition provides security services to callers in a generic
fashion, supportable with a range of underlying mechanisms and
technologies and hence allowing source-level portability of
applications to different environments.
In other words, the idea is that you can write a program that requires
authentication to use GSS-API function calls, and the actual GSS-API library
that you link it against can use Kerberos, or X.509, or some other
authentication technology to do the actual authentication. You can therefore
use different authentication technologies without changing your program's
source code at all.
GSS-API is an "up and coming" standard -- more and more vendors are embracing
it, and I suspect that it is going to be playing a much larger role in the
near future.
GSS-API relates to Kerberos in that there are at least two different GSS-API
implementations for Kerberos V5 -- one from OpenVision and one from DEC. The
OV implementation was included as part of the free MIT Kerberos V5
distribution (beta 3), and updates to it will continue to be included in later
MIT release (i.e., OV "gave away" our implementation to MIT). The DEC
implementation, which is also what will be shipped by the OSF with OSF DCE, I
believe, wasn't included in beta 3 but I believe is going to be included in a
later MIT Kerberos V5 release.
OpenV*Secure 1.0 includes the GSS-API libraries, I believe, but doesn't
include any support or documentation for them. OpenV*Secure 1.0.1, which will
probably be out by the middle of the summer for SunOS, Solaris, HP-UX and
possibly AIX, includes the libraries and programming documentation for them.
Therefore, if you purchase OpenV*Secure, you can write secure applications by
using GSS-API calls within your programs, and your programs will be portable
to systems using other forms of authentication besides Kerberos V5 (which is
what *Secure uses), as long as GSS-API front-ends to those forms of
authentication is available.
I hope that I have been helpful. Please feel free to contact me if you have
any other questions.
--
Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com
