Client identity selection: concepts and approach

[Nico Williams]

On Wed, Mar 23, 2011 at 2:56 PM,  <ghudson at mit.edu> wrote:
> We've been asked to take a stab at the problem of client identity
> selection.  The basic requirement is to improve the experience of a
> user who has krb5 credentials within multiple realms, with particular
> focus on using a web browser for negotiate auth.  (Other GSSAPI client
> programs are also in scope; non-GSSAPI clients are not.)  Right now a
> GSSAPI client using the default identity will only make use of the
> default principal of the default ccache, so you would have to restart
> the browser with a different KRB5CCNAME environment variable each time
> you wanted to contact a different realm's services.
>
> There are obvious expansions of this problem.  A user could have
> multiple credentials within the same realm for different roles.  A
> user could also have credentials for different GSSAPI mechanisms, or
> for non-GSSAPI mechanisms.  These expansions are not requirements for
> us at the moment, although we're keeping them in mind.

I would urge you to concern yourselves primarily with credential
selection in the context of the GSS-API.  The reason is that, as you
point out, one may want to select not just the initiator name, but the
mechanism as well based on context (i.e., the target acceptor name).

A mechglue could provide more extensive ID selection services than a
single mechanism.  On the other hand the mechglue may have fewer tools
at its disposal.  For example, a mechglue may not be able to avail
itself of mechanism-specific ID selection methods (in my last e-mail I
described a method based on target realm name, which has an
interesting-but-solvable catch-22), at least not for mechanisms that
can't do ID selection at the time of an initial call to
gss_init_sec_context() call.

You might want to do both, mechglue and mech-specific ID selection, in
which case you could start with the Kerberos mechanism and worry about
the mechglue later if you can convince yourself that you can mix the
two (see above).

> From first principles, there are a few ways this problem could be
> solved.  The app could take complete charge of the problem, developing
> knowledge of krb5 and presenting its own UI elements for selecting
> between identities.  The app could take partial charge of the problem,
> relying on new krb5 or GSSAPI functionality for resolving a client
> principal and then importing that into a GSSAPI name.  Or the problem
> could be handled completely within the GSSAPI implementation, using
> only the target service name and hostname to decide on a client
> principal.  For the moment, we need to handle the case where the app
> doesn't provide any hinting information.

Apps should allow users to make ID selection choices (possibly
indirectly, via out-of-band prompting), and to observe what ID was
selected.  However, when the default choice is used, then the app
should NOT make the choice.  Instead the mechglue/mechanism should.
This is another case where the lack of an caller context in the
GSS-APIv2u1 is obnoxious: there's no way to instruct the GSS-API as to
what the application's ID selection profile might be, should we want
per-app ID selection profiles.

[Complete aside follows.]

I'm starting to think that we need so badly to add such a feature
(caller contexts) to the API that... here's an idea: if apps define a
C macro called, say, GSS_C_APPLICATION_PROFILE, then GSS_C_NO_NAME and
GSS_C_NO_CREDENTIAL could expand into function calls.  And we could
add new a version of gss_import_name() that takes a profile name.  The
rest would follow.  I.e., something like this in the GSS header:

#ifdnef GSS_C_APPLICATION_PROFILE
#define GSS_C_NO_NAME ((gss_name_t)NULL)
#define GSS_C_NO_CREDENTIAL((gss_cred_id_t)NULL)
#else
#define GSS_C_NO_NAME (__gss_c_no_name(GSS_C_APPLICATION_PROFILE))
#define GSS_C_NO_CREDENTIAL (__gss_c_no_credential(GSS_C_APPLICATION_PROFILE))
#endif

then have those __gss_c_no_*() functions use thread-local storage to
store thread-local name/cred object handles.

Apps would:

#define GSS_C_APPLICATION_PROFILE "imap-client"
#include <gssapi/gssapi.h>

(This is based on an idea by Love.  I should really post this to KITTEN.)

Nico
--