GSSAPI pseudo-mechs and context unwrapping
Nicolas.Williams at oracle.com
Fri Apr 30 16:44:35 EDT 2010
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
> 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
Q1: Is the extra overhead of re-entrance a problem? For what
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
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).
> 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.
More information about the krbdev