Services4User review

[Nicolas Williams]

On Thu, Aug 20, 2009 at 10:33:06PM +0200, Luke Howard wrote:
> >Delegated credential handles need not correspond to delegated
> >credentials in the RFC1964/4121 sense, nor should it be necessary that
> >the caller of GSS_Init_sec_context() have explicitly requested
> >credential delegation -- in the S4U2{Self,Proxy} the delegation is
> >specified in the authz-data of the initiator's service Ticket, and the
> >decision to delegate could be made by the KDC.
> 
> I'm not sure if I understand this: could you point me to where in [MS- 
> SFU] it says that delegation is specified in the authorization data of  
> the initiator's service ticket?

Oh, forget the authz-data thing -- clearly it's the whole of the
initiator's service Ticket that matters (the KDC might use authz-data in
it, but that's another story).  Excuse the brain-fart.

> > [proposal and two wrinkles]
> 
> In practice I'm not sure if this is a big issue. In the current  
> implementation unconstrained delegation (ie. forwarded credentials)  
> take precedence.

Sure.

> >- Let gss_accept_sec_context() always output a delegated cred handle  
> >in
> >  the krb5 case, even when there's no traditional credential  
> >delegation
> >  on the part of the initiator.  Let gss_store_cred() fail if there's
> >  no traditional "forwarded Ticket" in the delegated credential.
> 
> Note we don't have gss_store_cred() yet.

We do.  It's useful, though really only in sshd :)

> >- For S4U2Proxy add gss_acquire_cred_impersonate_deleg() with two
> >  credential handle inputs:
> >
> >   - service_cred_handle (the caller's own cred handle)
> >   - subject_cred_handle (the delegated credential whose subject is to
> >     be impersonated)
> >
> >  and let it output a new cred handle corresponding to "the subject as
> >  impersonated by the service".
> 
> Where does one specify the service to which to delegate to? Would that  
> be another input?

That would be the target_name from the subsequent gss_init_sec_context()
call.

> >Also, are you sure that there are no non-GSS-API applications where
> >S4U2{self,Proxy} might be needed?
> 
> I'm not sure, but I think for 1.8 I'd prefer to expose at GSS-API  
> first, and then for a future release we can think about exposing the  
> underlying krb5 APIs. I don't feel too strongly about this though.

Sure.

> How do others feel about this? The proposed changes seem reasonable to  
> me. One change is that I was initially planning to make these  
> mechanism-specific APIs; do we want to commit to introducing new  
> mechanism-agnostic APIs?

I think these should be mechanism-agnostic.  A PKIX equivalent for
constrained delegation and impersonation is easily imaginable.

Nico
--