Delegated creds and SPNEGO

[Nicolas Williams]

On Wed, Aug 26, 2009 at 10:39:51PM -0700, Love Hörnquist Åstrand wrote:
> 26 aug 2009 kl. 22:07 skrev Nicolas Williams:
> >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.

That's not necessarily true.  For example, it's not true on Linux, since
you can setup your per-thread keyrings appropriately and off it goes.

And we could introduce a notion of credential store handles.  This would
entail:

a) functions to create and release credentials stores;
b) a function to get a handle to the current credential store, and one
   to set the current credential store to a given handle;
c) new versions of gss_acquire/add/store_cred() that take a credential
   store handle;
d) OS-specific functions for finding and manipulating other processes'/
   threads' notion of current credential stores.

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

I got the sense of the check backwards, sorry, it should be:

	if (have_deleg_cred && actual_mech != init_ctx_tok_mech &&
	    !is_prefix(init_ctx_tok_mech, actual_mech))
		expect deleg cred to be a mechglue cred;

A stackable mech that returns a composite mech as the actual_mech will
be able to (will have to) have its own wrapper for the delegated
credentials.

Nico
--