[16723] in Kerberos_V5_Development
Re: Client identity selection: concepts and approach
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Mar 24 03:23:32 2011
MIME-Version: 1.0
In-Reply-To: <201103231956.p2NJuRwM009642@outgoing.mit.edu>
Date: Thu, 24 Mar 2011 02:23:21 -0500
Message-ID: <AANLkTikDuHSuNJT1tbWkAopmBQp1FR5XqVoc6Pq1gQ=W@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: ghudson@mit.edu
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Wed, Mar 23, 2011 at 2:56 PM, <ghudson@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 credentialselection in the context of the GSS-API. The reason is that, as youpoint out, one may want to select not just the initiator name, but themechanism as well based on context (i.e., the target acceptor name).
A mechglue could provide more extensive ID selection services than asingle mechanism. On the other hand the mechglue may have fewer toolsat its disposal. For example, a mechglue may not be able to availitself of mechanism-specific ID selection methods (in my last e-mail Idescribed a method based on target realm name, which has aninteresting-but-solvable catch-22), at least not for mechanisms thatcan't do ID selection at the time of an initial call togss_init_sec_context() call.
You might want to do both, mechglue and mech-specific ID selection, inwhich case you could start with the Kerberos mechanism and worry aboutthe mechglue later if you can convince yourself that you can mix thetwo (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 (possiblyindirectly, via out-of-band prompting), and to observe what ID wasselected. However, when the default choice is used, then the appshould NOT make the choice. Instead the mechglue/mechanism should.This is another case where the lack of an caller context in theGSS-APIv2u1 is obnoxious: there's no way to instruct the GSS-API as towhat the application's ID selection profile might be, should we wantper-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 aC macro called, say, GSS_C_APPLICATION_PROFILE, then GSS_C_NO_NAME andGSS_C_NO_CREDENTIAL could expand into function calls. And we couldadd new a version of gss_import_name() that takes a profile name. Therest 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 tostore 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--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
