Mechanism extensions and the GSSAPI

[hartmans@mit.edu (Sam Hartman)]

I have no idea whether Heimdal and MIT have compatible goals in this
area.  However I'd rather  try to find a common solution than fail to
do so.


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.


So what are some approaches that manage this?

			    IOCTL Approach

We could define a function gss_cred_ioctl(minor_status, gss_cred_id_t,
mechanism_oid, operation, in_buffer, out_buffer) that calls certain
mechanism-specific operations.  We would probably also want gss_ioctl
(no credential), gss_ctx_ioctl (for established contexts),
gss_name_ioctl, etc.  I mean this approach fairly broadly.  IN
particularly, note that the GGF's credential extensions fall into this
category of approach.

This approach is fairly general in that it is clearly not mechanism
dependent.  It requires few changes to the general API band gets you
mechanism-specific extensions.

I see two significant disadvantages.  The first is that it works
poorly if you need two generic objects.  If I have an operation that
needs to take a context and a credential type, I cannot implement that
operation.  The second problem is that it is hard to use.  Both the
application and the mechanism need to  encode and parse the
arguments.  It also does not allow for compile time type checking.

			 The Upcall Approach

This is the approach I suggested yesterday to Kevin.  You provide an
API in the glue layer for the mechanism to coerce glue layer objects
into mechanism-specific objects.  The application just calls the
extension API and the mechanism manages to convert objects
appropriately.  In order for this solution to meet the mechanism API
== GSSAPI constraint, you need to standardize these extensions to glue
layers.

This solution has several disadvantages.  It requires upcalls; the
mechanism needs to be able to find and call the glue layer.  It
requires coersion routines be standardized.  It also may pose
challenges for dynamic linking: an application needs to make sure that
it gets the glue layer's gss_init_sec_context and friends while
getting the mechanism's extension functions.  Another significant
problem is that mechanisms need to be able to figure out whether an
object is a glue layer object or a mechanism object.  

There is one major advantage to this approach.  It's easy for
applications to use.    The usage model of this extension
proposal--that applications just call certain functions--is already
implicitly required by the Heimdal and MIT Kerberos mechanisms.

		       Application Makes Right

We could expose the coersion routines from the previous proposal, but
require the application to call them rather than the mechanism.  That
is, you need to get a mechanism credential before passing it into the
mechanism-specific extension.  This assumes that credential types,
contexts and names can be mutated by the mechanism.  For this to work,
you would need to guarantee that if i coerce c, a glue layer
credential into a mechanism credential, mutate the mechanism
credential and then later use c in a glue layer call, the right thing
happens.  I think this is true in practice, but I'm not  sure it is
guaranteed by the C bindings.

A disadvantage of this approach is that it requires more work for
applications although not as much as gss_ioctl.  Also, it requires
exposing coersion APIs.    This approach has the same dynamic linking
problem as the previous approach.

			  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.

			 Shim Around Coersion

Another approach is to expose the coersion APIs and to write a shim
layer.  The shim coerces the objects and then calls the mechanism
specific extension.  This approach is as easy for the application
author as the upcall approach and is somewhat easier for mechanism
authors than the upcall approach.  It does not suffer from the
multiple object problem.  The shim does need to deal with the dynamic
linking problem, although the application does not.

These are my initial thoughts.  Discussion is welcome.

--Sam