Client Principal Selection
Nicolas.Williams at sun.com
Mon Jul 11 14:31:33 EDT 2005
On Fri, Jul 08, 2005 at 04:29:27PM -0400, Alexandra Ellwood wrote:
> 2) Client principals for multiple realms with no cross-realm
> In this configuration users have identities in multiple realms.
> These realms correspond to departments in an organization or multiple
> organizations. For political (ie: not technically solvable) reasons
> the realms cannot shared keys. As a result, users must
> independently acquire ticket granting tickets for multiple realms.
> Selecting for the correct client principal is critical to sane
> application behavior. For example, let's say we have a user John Doe
> who has identities with his company's IT department
> (johndoe at COMPANY.COM), which he uses for email and also the QA
> department (johndoe at QA.COMPANY.COM) which he uses to connect to the
> QA department's ticket tracking system. Due to political reasons
> inside his company, COMPANY.COM and QA.COMPANY.COM don't share keys.
> 3) Multiple client principals with different privileges (ie:
> user at EXAMPLE.COM and user/admin at EXAMPLE.COM)
> Some sites like to provide highly privileged users (sysadmins,
> financial staff, etc) with client principals with different
> privileges. For example, a sysadmin who just wants to read a
> newsgroup doesn't need the ability to delete it and wouldn't want to
> accidentally do so anyway. In this configuration users use their
> unprivileged identities when performing basic activities and only
> switch over to the privileged identity when they need it.
> Currently these users switch back and forth between identities using
> the system default client principal (KfM) or KRB5CCNAME. It is
> important that our new principal selection algorithm continue to
> provide these users with some control over which principal gets
> used. However, since these users are usually more technical than the
> average user, we can make this functionality more obscure than a
> regular user feature.
I see these two as very similar problems. Both can be addressed with
notions of environment variables, trust partitions, AFS-like PAGs or
variants thereof -- each application instance then has access to only
one set of TGTs for only one client principal. I think that could be
seen as very user-friendly in some cases, as not at all user-friendly in
In any case, use of any OS facility more advanced than environment
variables runs into portability problems.
> 4) Use of SASL/TLS/SPNEGO to negotiate something other than Kerberos
Are you saying that you may want KLL to support initial credential
acquisition for mechanisms other than Kerberos V?
A generic facility (i.e., not mechanism-specific, though perhaps with
mechanism-specific options) for initial credential acquisition is highly
> 7) Referrals
> Instead of using DNS, Kerberos referrals use the KDC. Referrals
> allow the client to contact a KDC in the client principal's realm to
> find out the service principal corresponding to a given service and
> server name pair.
But this implies cross-realm configuration, if not even cross-realm
Perhaps we need a requirement for the referrals work that it allow for
referrals where no cross-realm keys have been exchanged.
> What this means for client principal selection is that figuring out
> if a given client principal is correct for a given server/service
> pair requires an extra communication with the client principal's KDC
> to get the service principal via a referral.
Which the client was going to do anyways. I don't mind the
infrastructure -- everyone seems to want some online infrastructure
> The Algorithms:
> * Prompting the User:
> The most trivial algorithm is just to ask the user which principal to
> use. The problem with asking is that once a large number of sites
> and services start using Kerberos, the questions become longer and
> more complicated.
Also, it isn't always possible to ask.
> * Caching:
> Obviously asking this question every time the user performs an
> operation is unacceptable. Fortunately we can cache mappings from
> server/service to client principal. This means that if Jane uses
> Kerberos for email, she will only be asked the first time. This
> functionality is critical for applications which perform periodic
> tasks from the background.
But you'd still have to ask when priming the cache, and you'd have to
know how long to cache mappings for, a way to clean the cache...
> * Searching:
> Caching doesn't prevent the user from being prompted the first time,
> and the more wide-spread Kerberos adoption gets, the longer the
> client principal selection list will be. If the user's first
> experience with Kerberos is a series of long thought-provoking
> questions from each Kerberized application, we're not going to be
> winning any popularity contests -- especially with the site support
> staff. :-)
> In particular, if the correct client principal is obvious (eg:
> connecting to a server at secure-email.com requires tickets at SECURE-
> EMAIL.COM), the user will wonder why the system didn't just select
> the correct ticket automatically. If the correct client principal
> isn't obvious (eg: cross-realm is involved), then novice users won't
> know which one to select.
> * Site-provided Hints:
> Unfortunately, as the number of principals the user has tickets for
> increases, searching will get expensive. Under pessimal network
> conditions this could be unacceptably slow.
And the prompts get longer too.
> Another way to generate the initial mappings would be to create a
> command line tool, API or protocol extension for generating hints.
> These hints would assist the Kerberos library in finding appropriate
> client principals, greatly reducing the number of client principals
> the search algorithm would have to try. Then each site the user uses
> could populate a hints table for their users.
> For example, a hint like "imap,imap*.company.com" -> "*@COMPANY.COM"
> could tell the cache that for the imap service server
> imap26.company.com, it should search for client principals in the
> realm COMPANY.COM.
> Note that hints are not the same as a cache entry. A cache entry
> corresponds to a successful authentication and indicates which
> specific client principal should be used for a given server/service
> pair. A site-provided hint is really just a suggestion for which
> client principals to try first to optimize searching.
But since many users could not be expected to provide these this
approach implies more distributed configuration/online infrastructure.
> At this point I'd like to ask folks for their opinions on this before
> getting any further into the details. In particular I'd like to know
> if I've missed any configurations that impact client principal
> selection and whether folks agree with my views on prompting the user
> for client principal selection (don't if you can possibly avoid it)
> and initial ticket acquisition (only if you know the user wants to
> use Kerberos).
This is going to be fun.
The need for interaction in initial ticket acquisition [usually :)]
cannot be avoided; use of a consistent system-wide mechanism for this is
For the rest, clearly prompting is a vary bad idea. Don't do it. If it
means more configuration, oh well. See above.
More information about the krbdev