Mechanism extensions and the GSSAPI

Kevin Coffman kwc at
Thu Apr 29 11:09:00 EDT 2004

I agree with Nico that this is an excellent survey of the options.

> Here is what I believe the goal is.  We want to find a way to have
> general extensions to GSSAPI mechanisms.  Sun and apparently other
> parties as well would like to have the API between the multi-mechanism
> glue layer and the mechanism implementation be the GSSAPI.  That means
> that any extensions we need to the glue layer need to be things we are
> willing to standardize.  It might also mean that there can be no
> up-calls from the mechanism to the glue layer.

Yes, I agree this makes the life of the "core glue" library sane.

> 			  Shim around Ioctl
> Mechanisms could provide a shim library that exports
> mechanism-specific APIs that end up calling the appropriate gss_ioctl
> function.  That means that the responsibility of encoding the
> arguments  is now the mechanism's rather than the application's.  This
> proposal is as easy to use as the upcall approach although it is as
> hard to write  for mechanism authors as the ioctl approach.
> This has the same disadvantage of the ioctl approach if  multiple
> objects are  used.  
> This approach solves the dynamic linking problem in that there is no
> reason the shim cannot be in its own dynamic object.

I think I agree with Nico that this seems like the best option, but
let me see if I fully comprehend.

- When building the application, you need to know whether it is
linking against a single-mechanism gssapi implementation or a
multi-mechanism glue layer.  Either way, it's interface doesn't

- If the app is linking directly with the single-mech
implementation, and uses mech-specific functions, it all happily

- If the app is linking with the multi-mechanism "core glue" and
uses mech-specific functions, it needs to know to link with the
mech-specific "glue shim(s)" and not directly against the mech-specific
library. (i.e. the "core glue" library shouldn't have to know about
mech-specific glue shims.)

Is this what you were thinking?

More information about the krbdev mailing list