Re: Support for multiple GSS libs

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

Did some work with mechglue from the MIT Kerberos 1.2.2, and got it to build as
a shared library under Solaris, and link with openssh-2.9p2, but not run.

The code needs a lot of work. It looks like it was designed for gssapi v1, and 
has not been updated for v2.

Mechglue expects the implementation to have a gss_mech_initialize routine which will 
return a mechanism and an array of entry points. GSI does not have such an array.
(But it would not take much to add it.) The MIT code does not have one now
as the routine which did have it was dropped some time ago, but the source code 
is still there. 

The mechglue was designed to work with either static or dynamic linking,
thus the need for the above table and some redefinitions of entry points
if both mechglue and libgssapi_krb5.a where linked. Now that most systems can handle 
dynamic loading there would be a better approach. This would be to 
load the gssapi implementation, then do a dlsym() call for each entry
point, rather then just the gss_mech_initialize with the mechglue building 
the gss_mechanism table at run time. This should work with the MIT, GSI,
or Hiemdal code without changes to the libraries and should work with W2K DLLs too. 

The gss_mechanism table also assumes only one mechanism per library.
This is not general, as a single implementation may support multiple 
mechanisms. This to could be fixed. 

SASL does something similar with dynamic plugins too. 

Another problem is that the GSSAPI does not define how delegated credentials 
are to be saved. It is left up to the implementation to provide extra implementation
specific routines to handle the delegated credentials. The gss_krb5_* and Kerberos 
routines are called to do this from the openssh for the Kerberos credentials, where 
there is a ssh_gssapi_krb5_storecreds().   

With GSI, we addressed delegated credentials in two ways: 

 (1) A hacked up version of gss_inquire_cred was developed that if called with a 
     specific minor status, would write out the credential. We have an MIT krb5-1.2.2 
     equivalent mod. This can be used by the gatekeeper with either GSI or K5. 
     No new entry points, and its generic, returing a string to be set in the environment. 

 (2) We have an extensions draft for IETF for GSSAPI which addresses this as  
     one issue and adds some generic calls to handle the delegated credentials.
     gss_export_cred() which is implemented for GSI, but I never wrote one for Krb5. 

So mechglue looks promising, but it needs a lot of work. 


Daniel Kouril wrote:
> 
> Hello,
> 
> I'm trying the GSI patch for OpenSSH from
> http://www.globus.org/Security/v1.1/openssh/install.html
> (it is based on Simon Wilkinson's patch from
>  http://www.sxw.org.uk/computing/patches/openssh.html)
> 
> The patch seems to work well for both kerberos5 (http://www.pdc.kth.se/heimdal)
> and GSI (SSL based implementation from www.globus.org) based libraries when
> compiled separately. But what I would like to have is a support for both the
> GSS mechanisms in only one binary.  Does anybody have any experience of using
> more GSS implementations together?  In the MIT distribution of Kerberos there
> is a mechglue library that seems to create an abstract layer between an
> application and GSS libraries and choose right implementation at runtime
> (according to mech_type). Does anyone tryied to use this library (or anything
> other) in order to make more GSS implementation work together?
> 
> Thanks in advance for any response.
> 
> --
> Daniel Kouril

-- 

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