Delegated creds and SPNEGO

[Nicolas Williams]

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

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/
accept_sec_context().

> 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
   credential handle

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

Yes.

>                              since that cuts out all other pseudo  
> combined mechs (like compression).

Not sure I follow.

Nico
--