Nicolas.Williams at sun.com
Fri Aug 21 12:26:13 EDT 2009
On Fri, Aug 21, 2009 at 05:36:51PM +0200, Luke Howard wrote:
> >/* S4U2PROXY */
> 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
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
- sasl_set_prop() (Cyrus SASL has option for passing in GSS creds to
- 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
- 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.
More information about the krbdev