Delegated creds and SPNEGO

[Love Hörnquist Åstrand]

26 aug 2009 kl. 11:10 skrev 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)

How does this get you only NTLM credentials and not Kerberos  
credentials ? Getting Kerberos credential might have side-effects you  
don't want to trigger.

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

And then you delegate, get your delegated credentials on the acceptor,  
how to turn that back into SPNEGO/.... credentials so that you can use  
SPNEGO/compression/whatever-psuedo-mech again ?

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

if you special case SPNEGO, you also need to special case all other  
combined mechs.

Love