GSSAPI pseudo-mechs and context unwrapping

[ghudson@MIT.EDU]

We have one pseudo-mech in the MIT krb5 tree (SPNEGO) and one incoming
(IAKERB).

Both have the property that they add complexity to context
establishment, but once a context is established, they don't add any
complexity to wrap/unwrap.  Because of this, both have no reason to
carry around extra state after context establishment, and they take
advantage of this by freeing their "wrapper" context structures and
substituting the underlying context into *context_handle.  However,
they have no way of changing the mech_type in the mechglue union
context.

Perhaps the biggest wart here is that the SPNEGO or IAKERB
gss_delete_sec_context function doesn't know whether it has a
SPNEGO/IAKERB wrapper context or an underlying context.  IAKERB uses a
magic field to recognize which kind of context it has; SPNEGO does the
same, but in a less correct fashion (since a union context has no
magic field).

There is also a desire for gss_inquire_context to return the actual
mechanism instead of the pseudo-mech, but that could potentially be
accomplished without doing any unwrapping at all, so I consider it a
separate problem.

The similarities between SPNEGO and IAKERB are not perfect.  For
SPNEGO, the underlying context is a second mechglue union context for
whatever mechanism was negotiated.  For IAKERB, the underlying context
is a krb5 internal context, created with a special variant of
krb5_gss_init/accept_sec_context which receives additional information
(the IAKERB conversation).  Put another way, SPNEGO is a generic
pseudo-mechanism while IAKERB is a specific one.

Nico's proposal for unwrapping, targeted at "generic" pseudo-mechs
like SPNEGO, was thus:

  * The mechglue notices when the mechanism's init/accept_sec_context
    returns a different *actual_mech from req_mech_type.

  * The mechglue assumes that in this case, *context_handle contains a
    mechglue union context.

  * The mechglue effectively copies the contents of that union context
    into its own, so that mech_type becomes the actual mech type.

Unfortunately, this idea can't work for IAKERB, since IAKERB cannot
use the mechglue to construct the subsidiary krb5 context--there is no
way to pass the IAKERB conversation if it goes through
gss_accept_sec_context with the krb5 mech.

I'm soliciting ideas on how to make this better for both SPNEGO and
IAKERB.  One idea is for the pseudo-mech to provide a subsidiary
context matching the *actual_mech value--but to do this, a "generic"
pseudo-mech like SPNEGO would need some way to reach into a union
context and pull out the internal_ctx_id--either by understanding the
mechglue structures or by using some kind of callback into the
mechglue.  I know Nico dislikes both ideas, so I'm presenting this
option mostly as a straw man.