Mechanism extensions and the GSSAPI

[Wyllys Ingersoll]

Kevin Coffman wrote:

>>			  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
>change. 
>
>- If the app is linking directly with the single-mech
>implementation, and uses mech-specific functions, it all happily
>works.
>
>- 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?
>  
>

An app should never need to know or care that its linking against
a single-mech GSSAPI or a multi-mech GSSAPI.  The API is standard
and should not be broken or fractured among implementations.  

This sort of feature creep will start make it very hard to further
the adoption of GSSAPI into various open source projects.
A project that wishes to use GSSAPI today needs to make some minor
'configuration' script edits to make sure the build environment
has the correct path to the library and headers but doesn't need
to really be concerned about features contained in the GSSAPI libs
that it uses.  If the various implementations start adding
major new interfaces like this, it will then force incompatibilities
across the implementations and make applications less portable
to the various implementations.

I disagree that such an API should be necessary.  Mechanism specific
details like "ktypes" have no business anywhere in a generic GSSAPI
interface.  Just because Kerberos is the main GSSAPI mechanism today,
doesn't mean it will be so forever and GSSAPI should maintain
a design that will support new mechs in the future.  Besides, kerberos
enctypes can be configured several ways that do not involve hacking up the
GSSAPI interface in non-standard ways:

-  As Nico suggests, create your NFS principals with the desired enctypes
   in the first place.
-  Set the permitted_enctypes, default_tgs/tkt_enctypes settings in 
krb5.conf
   so that only the desired enctypes are used.

I can't believe this thread has gone this far...

-Wyllys