living in a multi-mech world

[Sam Hartman]

>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:

>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
    Nicolas> On Mon, Apr 30, 2007 at 12:16:44AM -0500, Nicolas
    Nicolas> Williams wrote:
    >>>> Pseudo-mechs shouldn't get direct access to other mechs --
    >>>> they should always re-enter the mechglue (recursion ends
    >>>> because the various input parameters refer to other
    >>>> mechanisms -- as long as the pseudo-mechanism itself is not
    >>>> infinitely recursive).
    >>>> 
    >>>> Re-entering the mechglue from pseudo-mechanisms should add
    >>>> some overhead (extra frames on the stack), but not data
    >>>> copies.

    Nicolas> Although, provided
    Nicolas> gss_get/set_name/cred/context_mech_specific() functions
    Nicolas> and a gss_dlopen() then it would be reasonable for
    Nicolas> pseudo-mechs to invoke the mechanisms directly.  And that
    Nicolas> would save a bit of overhead.
    Nicolas> _______________________________________________ krbdev
    Nicolas> mailing list krbdev at mit.edu
    Nicolas> https://mailman.mit.edu/mailman/listinfo/krbdev

    Sam> I think your first statement was more correct.  While you
    Sam> might make bypassing the mechglue work, it seems like it adds
    Sam> a lot of complexity.

    Tom> I think it's reasonable for someone to want to have a SPNEGO
    Tom> mechanism support only the krb5 mech, for example, so the
    Tom> SPNEGO mech could load the krb5 mech and dlsym() the GSS-API
    Tom> entry points.

I think this is overly complex.
You can specify a specific oid into the mechglue.