Projects/GSS-API mechanism plug-in support

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

GSS-API mechanism plug-in support

We want to have loadable mechanism plug-in modules for GSS-API.

Goals

• ordinary mechanism modules need only provide GSS-API C bindings
• pseudomech modules do not need to know implementation-specific things
• allow pseudomechs to "pop" themselves off the stack, e.g. SPNEGO gets out of the way and replaces its context with underlying mechanism once context negotiation is complete
• do not require modules to do anything special for memory management; each module's gss_release_buffer() gets used for memory it has allocated

OS requirements

• RTLD_LOCAL or equivalent functionality to avoid injecting plug-in symbols into global namespace
• modules should work with RTLD_GROUP but not require it

Requirements for mechglue

• register gss_buffer_t values from mechanisms in order to call correct gss_release_buffer()
• register gss_context_t values from mechanisms in order to detect pseudomech "pop"
• gss_dlsym() (or whatever we call it) for pseudomechs to obtain mechglue GSS-API entry points

Requirements for mechanism modules

• provide GSS-API C bindings (gss_*) entry points
• do not link against mechglue
• only use internal names to call internal entry points

Additional requirements for pseudomech modules

• provide entry point (name TBD) for mechglue to call at module load time to provide gss_dlsym() entry point
• use gss_dlsym() to obtain mechglue entry points
• always call other mechanisms via the mechglue
• must not internally register objects obtained from other mechanisms