GSSAPI pseudo-mechs and context unwrapping

[Nicolas Williams]

On Fri, Apr 30, 2010 at 07:07:52AM -0400, ghudson at MIT.EDU wrote:
> 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.

Q1: Is the extra overhead of re-entrance a problem?  For what
    applications?

    E.g., it's almost certainly not a problem for SSHv2 implementations.

Q2: Do we want to say that IAKERB sets the mech_type output parameter
    (of gss_init_sec_context() and gss_accept_sec_context()) like SPNEGO
    does?

    If not then we may have to treat SPNEGO and IAKERB differently.

> 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).

Not good.

> 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.

For a stackable mechanism there'd be no need to do that: you can just
decompose the mechanism's OID into a top-level mechanism and the rest
below.  But IAKERB, though it could have been a stackable mechanism,
isn't.  This sounds like we want the answer to Q2 to be "yes".

Having IAKERB set the mech_type output parameter would help lots.

> 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.

This argues for answering Q2 with "no" and then having IAKERB share
per-message token code with the RFC4121 mech.

Alternatively IAKERB should re-enter the mechglue to use the RFC4121
mechanism, though this may require a gss_acquire_cred extension (since
the credential acquired by IAKERB will not be available for acquisition
in the implicit credential store used by gss_acquire_cred()) -- e.g.,
gss_acquire_cred_with_ccache(), or something like that.

> 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.

No need to copy -- just return it.

> 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.

Several solutions described or hinted at above.

Nico
--