Delegated creds and SPNEGO

[Nicolas Williams]

On Thu, Sep 24, 2009 at 04:03:53PM +0200, pk wrote:
> > So, I'm wondering: was this fixed correctly? Is the expectation that,  
> > when using pseudo-mechanisms, you will acquire credentials for the  
> > pseudo-mechanism or for the concrete mechanism? If it's the former,  
> > well, it doesn't work right now. I ask because it impacts some other  
> > work.
> 
> Given `src_name' is mechanism specific and `mech_type' also contains
> the actually chosen mechanism, returning a mechanism specific delegated
> credential would be by far the most sensible thing to do. 
> 
> 
> See also my post to the krbdev list from May 22, 2007 for an alternative
> fix, which is cleaner, IMHO, because it avoids hard-coding the
> SPNEGO OID and allows the composite/stacked mechamism implementation
> to decide what to return.

Please see the rest of this thread.

The simplest thing to do w.r.t. delegated credential in the mechglue is
this: if the mechanism returned an actual_mech other than the
mechanism's OID, then assume that the delegated credential is already a
mechglue object.  In other words: assume that pseudo-mechanisms re-enter
the _same_ mechglue [as the one calling the pseudo-mechanisms] in order
to call other mechanisms, and that pseudo-mechanisms will return a
mechglue gss_cred_id_t object when the actual_mech != the OID from the
initial context token.

The same need not apply to src_name; it could be made to apply, but it's
not necessary.  In the case of src_name, as with all other mechanism-
specific objects, the mechglue will assume that the object returned by
the mechanism is allocated by the mechanism itself and therefore must be
wrapped by the mechglue.

(There's a slight change to the above to account for stackable
mechanisms.  See the rest of this thread.)

This approach does not result in hardcoding of mechanism OIDs in the
mechglue.  It is a heuristic based on what you might call an ABI
requirement imposed by a system's mechglue, specifically: that
pseudo-mechanisms must re-enter the same mechglue that is calling them
in order to invoke other mechanisms from inside a pseudo-mechanism.
This is a very reasonable requirement to impose, though it implies a
requirement that pseudo-mechanisms be able to find the mechglue to
re-enter.

If one wishes to have pseudo-mechanisms be mechglue-like and call
directly into other mechanisms then one can adjust the above scheme
accordingly ("deleg cred is a mechanism-level object for the
actual_mech, not for the pseudo-mechanism"), with a similar requirement
resulting: the mechglue and pseudo-mechanisms must use the same
mechanism providers.

Nico
--