Services4User review

[Luke Howard]

Not so hypothetical. I realise I misunderstood some attributes of  
Nico's original suggestion.

So, now: a delegated credentials handle is always returned by  
gss_accept_sec_context() (and GSS_C_DELEG_FLAG is set). That handle  
can be passed into gss_init_sec_context(): the actual constrained  
delegation request is deferred until then, because only then is the  
target name known.

Similarly, an impersonation credential handle from  
gss_acquire_cred_impersonate_name() can also be passed to  
gss_init_sec_context(). (The S4U2Self request is not deferred.)

Under the hood, there is a flag set in the credentials handle that  
indicates it is a "proxy" handle, in which case the impersonator's TGT  
is also present (necessary to perform the S4U2Proxy request). This is  
only the case for forwardable tickets; if the initiator's ticket is  
not forwardable, or S4U2Self issued a non-forwardable ticket, then a  
normal, TGT-less credentials handle is returned, and the only valid  
target is the impersonator.

I've updated the wiki and the code.

-- Luke

On 21/08/2009, at 6:53 PM, Luke Howard wrote:

>> But where would the host's credentials go?  Sure, you could use
>
> <hypothetical>
> If the acceptor and impersonate credentials are the same thing (which,
> for constrained delegation in the Kerberos world, they must be), then
> a single acceptor credential handle with GSS_C_BOTH would work:
>
> gss_accept_sec_context() could then return a credentials handle
> containing both the verifier's initiator credentials and the evidence
> ticket (ie. from the initiator to the acceptor).
> (gss_acquire_cred_impersonate_cred() does just this.)
> </hypothetical>
>
> Anyway, I'm fine with the existing design :-)
>
>>   - One could imagine alternative ways to design S4U2PROXY for
>>     Kerberos where the proxy gets a TGT to impersonate the subject,
>>     but the TGT carries authz-data that constrains what service
>>     principals it can be used to get service tickets for.
>
> Ah yes, that would be interesting too!
>
> -- Luke
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
www.padl.com | www.fghr.net