Session key extraction

[Luke Howard]

> Two additional APIs are defined, gssspi_set_cred_option() (which sets
> an attribute on a credential) and gssspi_mech_invoke() (which is a
> catch-all context/credential-handle-less mechanism for invoking a
> mechanism-specific API).


I should add some rationale as to why gssspi_mech_invoke() exists, as  
I almost forgot this morning (and ended up deleting and then  
reinstating a bunch of code).

On some platforms, applications might link against the mechanism  
plugin itself to get mechanism-specific APIs. This happens on  
OpenSolaris (where the Kerberos mechanism is built dynamically),  
however it is not portable; in particular, on Darwin, libraries and  
loadable modules not interchangeable. Instead, one can place mechanism- 
specific API in a separate library; that library can, internally, use  
gssspi_set_cred_option(), gssspi_mech_invoke(), etc, to call into the  
mechanism without linking against it. So, mechglue might live in  
libgss[api]; mechanism-specific API in libgssapi_somemech; and the  
mechanism itself in mech_somemech.

gssspi_mech_invoke() thus allows a way to modify internal mechanism- 
state without linking against the mechanism (for APIs such as  
krb5_gss_use_kdc_context()). The alternative of modifying that state  
using, say, weak symbols, is less portable. There is no requirement  
the mechanism provide mechanism-specific functionality through a  
wrapper library, although it is intended that the APIs prefixes with  
gssspi are only used by such a library. For SSPI session key  
extraction, for example, the application will call  
gss_inquire_sec_context_by_oid(GSS_C_INQ_SSPI_SESSION_KEY).

Recall gss_set_sec_context_option(), gssspi_set_cred_option(), etc,  
are necessary not only for this but also to unwrap context and  
credential handles, thus supporting stacked mechanisms.

Note there's presently no support in the Makefile for building the  
Kerberos mechanism dynamically. For ABI compatibility, we'll have to  
support both mechglue and mech_krb5 in libgssapi_krb5 for some time to  
come, and I haven't had time to do the necessary Makefile magic to  
support both types of builds. Steps for the interested reader:

(a) build gssapi/mechglue as libgss[api]
(b) build gssapi/spnego as mech_spnego (without -D_GSS_STATIC_LINK)
(c) build gssapi/krb5 as mech_krb5 (without -D_GSS_STATIC_LINK) except  
for krb5_gss_glue.c, which should be built as libgssapi_krb5
(d) configure /etc/gss/mech appropriately

Finally, note that the configuration of dynamically loadable  
mechanisms is identical to Solaris, with the addition of supporting  
mechanisms that simply export the GSS-API themselves, rather than the  
mechglue dispatch table.

Happy new year to everyone.

-- Luke