[kitten] On GSS credential "stores"

[Nico Williams <[e-mail]>]

The GSS-API, all versions up to and including v2 update 1, with all
Standards-Track extensions to date, has a purposefully nebulous concept
of credential store (the "place(s)" where credentials are kept).
GSS_Acquire_cred(), GSS_Add_cred(), the default CREDENTIAL HANDLE, and
the GSS_Store_cred() extension, all interact with a "credential store",
but the details are specific to each operating system / implementation.

There is no discussion in the specs of how one finds this "credential
store" in any other context, how one creates a store, or how one ensures
that a "session" or a "process" has a "credential store" associated with
it.  All out of scope; see RFC2743 section 1.1.1.2 [0].

For implementors of common sorts of acceptor applications (e.g., SSHv2
servers) that want to make delegated credentials available to other
processes, some of these details matter a great deal.  But even knowing
such details, before GSS_Store_cred() implementors needed special access
to a mechanism's internals to be able to make a delegatged credential
available to a user session's processes, or simply could not do anything
with delegated credentials.

That's because delegated CREDENTIAL HANDLEs are a sort of anonymous
object[1], with a manifestation only in the process that called
GSS_Accept_sec_context().  In the original GSS-API there was no way to
make delegated credentials available to other processes.

GSS_Store_cred() fixes that problem, still leaving the background
details about "credential stores" in the background.

As far as I'm concerned, the GSS-APIv2u1 with GSS_Store_cred() has a
sufficiently complete and usable (and used!) interface to credentials
for most applications.  Sure, it's not rich enough to replace "kinit"
with "gssinit", and "klist" with "gsslist", and so on.  But applications
like "ssh" and "sshd" can be written correctly.

It's worth pointing out that CREDENTIAL HANDLEs are really just that: a
way to reference what is typically an external object (like file handles
in most programming language environments).  But delegated CREDENTIAL
HANDLEs are anonymous objects, as explained above.  This is useful to
know, if we consider future extensions, such as functions for obtaining
credentials with passwords, smartcards, and so on.

As we consider such extensions, we can either have them interact with
the credential store, or have them produce CREDENTIAL HANDLEs that are
like delegated ones, and which need to be explicitly "stored" to be made
available to other processes in a session.  The GSS_Store_cred()
approach is nice: it allows us to limit side-effects in functions that
output CREDENTIAL HANDLEs, and lets us separate the function of storing
them from the function of making them.  I urge this approach on anyone
working in this space.

That's not to say that we couldn't also develop a more complete
interface to the credential store.  One could have functions to create
and destroy credential stores, set the current credential store for a
process or session, get a handle to the current credential store, get a
list of credentials in the store, destroy credentials in the store,
refresh/replace them, get handles to credentials in the store, add
credentials to the store, and so on.  Such aren't strictly necessary,
though perhaps they would be useful enough to design and implement.
Just that as long as we don't go there, we should stick with the
GSS-APIv2u1+GSS_Store_cred() model of credential stores.

[0] We wouldn't want these RFCs to talk about such mundane details as
    "fork()", "exec()", "spawn()", "process", "access token", "real,
    effective, and saved UID", "environment variables", and all sorts of
    other OS-specific details.  Indeed they don't.

[1] Note: not anonymous _principal_.

Nico
--