Delegated creds and SPNEGO

[Love Hörnquist Åstrand]

26 aug 2009 kl. 22:07 skrev Nicolas Williams:

> On Wed, Aug 26, 2009 at 09:09:32PM -0700, Love Hörnquist Åstrand  
> wrote:
>> 26 aug 2009 kl. 11:10 skrev Nicolas Williams:
>>> 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.
>
> SPNEGO should defer re-entering gss_acquire/add_cred() until the next
> step in the list below happens:
>
>>> - 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
>>>
>>> [...]
>
>> 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 ?
>
> You must first store them somewhere with gss_store_cred(), so that you
> can re-acquire; gss_store_cred(), like gss_acquire/add_cred() and
> GSS_C_NO_CREDENTIAL, refers to the "current credential store".   
> Setting
> up credential stores and changing the current credential store are
> outsire the scope of the GSS-API and really are OS-dependent matters
> (e.g., putenv("KRB5CCNAME=...")? setuid()?  setup keyrings?  PAGs?   
> all
> OS-specific).

gss_store_cred() is mostly unusable for just that reason, you can't  
use it inside a multi threaded application, and you are not sure how  
it will affect other processes if you call it. for example, two proxy  
smb fileservers store credentails for the same user, one might  
overwrite credentials for another process.

>
>>>>                           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.
>
> Our special case does not actually check for the SPNEGO OID.  It's a
> very simple special case (if (have_deleg_cred && actual_mech !=
> initial_context_token_mech) then expect the mech to have returned a
> mechglue cred, not a mech cred).  It could use a tiny tweak for the  
> case
> of composite mechs (instead of actual_mech !=  
> initial_context_token_mech
> it needs to check that initial_context_token_mech is equal to or a
> prefix of actual_mech).

Then you force all composed mechs to use mechglue layer credentials,  
so they can't have their own credentials. Somethings that you  
recommend doing for gss_acquire_cred (ie defer acquire until later)  
above.

Love