Re: multi-mechanism gssapi

["Douglas E. Engert" <deengert@anl.gov>]

Luke Howard wrote:

> Hi Johan,
> 
> 
>>Yes, we should fix this, but I'm afraid that my time is very limited
>>right now. I don't know what Love is up to.
>>
>>Just to let you know we're listening. :-)
> 
> 
> What if we were to:
> 
> (a) move SPNEGO and Kerberos GSS-API mechanisms in Heimdal into
>     libmech_spnego and libmech_krb5 libraries, respectively
> (b) have each library export a gss_mechanism dispatch table
> (c) use the CITI libgssapi to implement the exposed GSS API
> 
> For binary compatability, libgssapi would link in the Kerberos/SPNEGO
> mechanisms (also because we have programs that use mechanism-specific
> API such as gss_krb5_ccache_name()). 

One of the other issues with the application calling mechanism-specific
APIs has to do with passing of the context or cred. If there is a mechglue
it will most likely have defined its own structure for the contect or
cred, which contain pointers to the underlying context or cred for all
the mechanisums it is fronting. The mechglue would then take care of
passing the correct context or cred. But if the application bypasses the
mechglue what does it pass for the contect or cred?

How do you plan on handling this?

This should be an issue for Kitten.

Your example of getting the name of the credentials store is one that
the GSI ran into. Rather then calling mech specific routines the
GGF GSSAPI extensions added the  generic gss_export_cred that  could return
a handle to the  stored credentials, suitable to be used with putenv. i.e.
With Kerberos it would return  "KRB5CCNAME=FILE:/tmp/krb5cc_uid" or whatever
is the handle for the cache. With the GSI it would return "X509_USER_PROXY=/tmp/..."

http://www.ggf.org/documents/GWD-I-E/GFD-E.024.pdf
Kitten is addressing the issues as rasied in this GGF document.


> But others, on platforms that
> support it, could be dynamically loaded by exporting a gss_mechanism
> table. (I prefer this approach to looking for each GSS function as
> it allows applications to use mechanism-specific API by linking against
> the mechanism library directly. The only problem is versioning,
> particularly as we would want to support API extensions such as
> gss_wrap_ex().)
> 
> Before I start down this track (or a related one), I'd like to know the
> likelihood of it being integrated into Heimdal. I'm prepared to write
> from scratch if you would prefer. :-)
> 
> (FWIW the CITI code originates from Sun and is under a BSD license
> without the advertising clause.)
> 
> Also, there is the Sun TI-RPC mechglue library around somewhere, which
> apparently is the Solaris 8 code, but I can't seem to find it anywhere
> and it is released under a different license.
> 
> -- Luke
> 
> --
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444