Delegated creds and SPNEGO
Nicolas.Williams at sun.com
Wed Aug 26 14:10:01 EDT 2009
On Wed, Aug 26, 2009 at 10:45:17AM -0700, Love Hörnquist Åstrand wrote:
> 26 aug 2009 kl. 10:09 skrev Luke Howard:
> > So, I'm wondering: was this fixed correctly? Is the expectation that,
> > when using pseudo-mechanisms
> pseudo mechs are mostly broken. basically every time you add a new
> pseudo or combined mech you are running into this problems what you
I mostly agree. You can get by with no SPNEGO-specials in libgss
though. The only place where a special is needed is in
gss_accept_sec_context() in the case where: a) there's a delegated cred
and b) actual_mech != the OID in the initial context token.
Solaris' libgss assumes that in that case the delegated credential
returned by the pseudo-mechanism is a libgss credential returned to the
pseudo-mechanism by a libgss gss_accept_sec_context() call for the
underlying mechanism. Thus Solaris has no code to check for SPNEGO in
libgss, though it does have a SPNEGO-special.
The gss_ctx_id_t returned by gss_init/accept_sec_context() where SPNEGO
was used is still a SPNEGO context. We could apply the same hack as we
do for delegated credentials though, which would allow us to avoid
having to have SPNEGO-wrapped MNs for the MNs returned by gss_inquire/
> for example acquiring NTLM initator credentials to use with SPNEGO is,
> well complicated and have performance problem since it will probably
> get kerberos initator credentials at the same time.
Bad example. That's supposed to work like this:
- optional: import a desired name
- required: call gss_acquire/add_cred() with SPNEGO as a desired_mech,
and, if you have one, a desired name (see above)
- optional: call gss_set_neg_mechs() on the acquired credential to set
the mechs that SPNEGO may negotiate
- required: call gss_init/accept_sec_context() with the resulting
Internally SPNEGO must extract the neg_mechs set from its cred handle
when its gss_init/accept_sec_context() method is called, and from that
it must extract the desired_name, import a new gss_name_t, and use the
result to acquire a cred handle for the optimistic and negotiated mechs,
and pass that to the re-entered gss_init/accept_sec_context().
I believe that works.
> I don't even think its possible to tell ISC what you want it to do.
I don't agree. See above.
> Does this discussion belong on KITTEN ?
Only if we find a problem we cannot surmount, and even if we can
surmount all such problems, we should document SPNEGO-specials as
implementor advice in an FYI.
> Special casing SPNEGO is bad
> since that cuts out all other pseudo
> combined mechs (like compression).
Not sure I follow.
More information about the krbdev