Services4User review

Greg Hudson ghudson at MIT.EDU
Fri Sep 4 23:10:15 EDT 2009

On Fri, 2009-09-04 at 17:49 -0400, Nicolas Williams wrote:
> Actually, S4U2Self and Proxy *both* are in the same boat: they can be
> used without new gss_*cred*() extentions because in both cases they can
> be used solely through the delegated credentials returned by
> gss_accept_sec_context().

That doesn't match my understanding.  As I understand it, the general
use case of S4U2Self is that you've authenticated a user by some other
means (like an X.509 certificate or a password over TLS) and you want to
get a ticket as that user to examine the PAC information or for use with
S4U2Proxy.  You never accepted a GSS security context.  So you need
gss_acquire_cred_impersonate_name to do S4U2Self, but you can then pass
the resulting credentials to gss_init_sec_context to do S4U2Proxy,
without needing a second extension.

> >   * I see no benefit in adding unstandardized APIs for no particular
> > reason, nor do I see any benefit in standardizing
> > gss_acquire/add_cred_impersonate_cred.
> What's the difference between "for no particular reason" and "[for]
> which we don't have an identified need"?  It must be subtle :)

In one bullet point I said "standardized" and in the next I said
"unstandardized".  Basically, I'm saying that stuff coming out of the
IETF gets a presumption of usefulness, but extensions we dream up do

> I don't have a current use for these extensions, therefore I won't mind
> if they go.  But I can imagine uses for these (think of a PAM module
> that uses host and user creds to impersonate the user to other
> services).

>   Typically one has no need for such a thing because the PAM
> module will be running with all privileges and it can assert any ID to
> any other service on the same host.  But suppose now that you want to be
> able to convey KDC-issued authz-data for that user to those other
> services; suddenly these APIs become useful!

If the PAM module has user creds on hand for some reason, it can use
those directly.  If the PAM module doesn't have user creds on hand, it
can use S4U2Self (via the extension API) to get them, and can pass the
result to gss_init_sec_context to do S4U2Proxy.

More information about the krbdev mailing list