Session key extraction
lukeh at padl.com
Thu Jan 1 08:03:07 EST 2009
> 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
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.
More information about the krbdev