Brian May <[EMAIL PROTECTED]> writes:
>>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
> Russ> It may be that they were trying to provide an indirection
> Russ> layer between MIT and Heimdal so that people could choose
> Russ> whichever they want at runtime. I'm not sure of another
> Russ> reason for it. The UMich library doesn't actually implement
> Russ> GSSAPI at all; it requires that another implementation (MIT
> Russ> or Heimdal) be available and just calls into the other
> Russ> library.
> GSSAPI isn't limited to just Kerberos, you could implement other
> protocols in GSSAPI too.
Yes; the MIT library, for example, implements both a krb5 mechanism and an
SPNEGO mechanism, and the Heimdal library implements krb5, SPNEGO, and
NTLM.
> Having said that, the only GSSAPI libraries in Debian I know of are
> the two Kerberos libraries.
No one inside of Debian or out, so far as I know, ships separate mechanism
implementations for existing mechglue layers. One reason why not is
probably that the maintainers of existing mechglue layers have been happy
to include all mechanisms with those layers.
Here, here's a table that summarizes my understanding of the situation and
may help:
Library Mechglue? Mechanisms
--------------- --------- ------------------------------
Heimdal yes Kerberos, SPNEGO, NTLM
MIT yes Kerberos, SPNEGO
UMich libgssapi yes -none- [1]
libgss yes Kerberos [2]
[1] Requires that some other GSSAPI library be installed and calls into
the mechglue layer of *that* library to provide all of its
functionality.
[2] Uses Shishi for its Kerberos implementation, which is wire-compatible
with other Kerberos implementations but not, so far as I know, fully
compatible with ticket caches, configuration, and similar local
infrastructure.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
