Services4User review

[Nicolas Williams]

On Fri, Aug 21, 2009 at 05:36:51PM +0200, Luke Howard wrote:
> >
> >/* S4U2PROXY */
> >OM_uint32
> >gss_acquire_cred_with_creds(
> 
> Could you argue that it would be better to do away with this function,  
> and allow the "delegated" credential handle to be passed directly into  
> gss_init_sec_context()?

But where would the host's credentials go?  Sure, you could use
GSS_C_NO_CREDENTIAL for the host creds, but then you'd need a req flag
to tell the mechanism to do that, and that's not very robust: mechglue
can know whether a mech supports a new function/method, but not whether
it supports a new flag (well, there's extended inquiry, yes, and you
could find out from ret_flags after the fact, but still, that's all
rather awkward, don't you think?).

Sure, you could have a gss_init_sec_context_impersonate() that takes two
cred handles.  And so on, but I prefer to do all this purely at the cred
level for several reasons:

 - You can pass an impersonation cred around to any interface that takes
   a gss_cred_id_t:

    - gss_inquire_cred*()
    - gss_init/accept_sec_context()
    - gss_store_cred()
    - sasl_set_prop() (Cyrus SASL has option for passing in GSS creds to
      use)
    - ...

 - The cred-level abstraction fits very well in my mind; the fact that
   for the krb5 mechanism the actual KDC exchanges to get proxy creds
   would happen later, in the actual gss_init_sec_context() calls is
   irrelevant.

    - Other mechanisms might only need to get a proxy cred once (think
      of a PKIX-like mechanism).

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

      In this case the cred-level abstraction is much better.

> Or would this introduce problems for other mechanisms?

IMO: yes, it would, and even for alternative designs of S4U2PROXY.