Client identity selection: concepts and approach

[ghudson@MIT.EDU]

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.

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

There was a previous project to solve this problem within the context
of Kerberos for Mac, called KIM.  As best I can tell from the
available documentation and code, KIM provides a framework for apps to
select ccaches based on hinting information, but does not change the
user experience for a dumb GSSAPI client app.  KIM's approach is to
prompt the user (via an OS-specific agent) to select an identity the
first time a resource is contacted, and then to cache the result (in
an OS-specific manner) for the future.  The KIM agent can also prompt
the user to acquire credentials for the selected identity if they
don't exist.

Whether or not we use KIM, there are two fundamentals to be addressed:
first, how to access and represent credentials for multiple client
principals, and second, how to represent mappings from service names
and/or hints to client principals.  I'll be starting separate threads
for each of those issues.

The way I currently expect to attack this problem is:

1. Decide, at least for the moment, how to represent credential
collections.

2. Decide how to represent mappings from target service (and/or
hinting information) to client principals.

3. In GSSAPI-krb5, when using the default initiator cred in
gss_init_sec_context, look up the target service in the mappings and
use the resulting client principal from the credential collection.

This is as far as I expect us to get for 1.10, meaning that the
mappings will initially be populated out of band.  Future work may
address:

4. Populating the mappings, either in-band by prompting, or out of
band by establishing some kind of service enrollment operation.

5. Optional app-provided hints about the target service.

6. Prompting to acquire credentials (this raises concerns about
phishing, but I believe is standard behavior in KfM and KfW).