Client Principal Selection
lxs at MIT.EDU
Fri Jul 8 16:29:27 EDT 2005
I'm a little concerned that we're starting to look at this from an
implementation standpoint before we have a clear idea of what our
constraints are, what the algorithm needs to do, and which site
configurations it will support. Before launching into proposals for
a client principal selection algorithm, I'd like to outline our goals
Over the past couple years MIT has been seeing an increasing number
of requests for better support for users with multiple client
principals. Currently these users must manually switch back and
forth between client principals, resulting in a cumbersome and
frustrating user experience. We would like to improve this process.
The reason for the sudden interest in this is that we are in the
early stages of redesigning Kerberos for Macintosh's KLL (Kerberos
Login Library) to be cross platform. The KLL is fundamentally an API
for initial ticket acquisition, and in an environment with multiple
client principals that also means it needs to be aware of client
principal selection. As a result, we feel that it is important to
decide how we are going to solve the client principal selection
problem before redesigning the KLL. Otherwise the new KLL may end up
limiting what we can do.
A number of different site configurations affect client principal
selection. Since many of these can be combined at a single site, and
a given user may use multiple sites, it is critical that we behave
reasonably when these configurations or combinations of them are used
In particular, it is important that our new client principal
selection algorithm not result in behavior which is less desirable
than the existing behavior for any given configuration. Otherwise we
will effectively "break" that configuration.
1) Cross-realm authentication
The cross-realm authentication is currently the best-supported
configuration. Users acquire a TGT for a single client principal
automatically get service tickets for other realms without any user
input. Since there is only one client principal, no principal
selection algorithm is needed.
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.
Now if John has both his email and ticket tracking applications
running, each application needs to find the right tickets, and the
current "system default client principal" and KRB5CCNAME model
becomes problematic. To check his email, John must select the ticket
cache containing tickets for "johndoe at COMPANY.COM" and then click the
"check mail" button. To view the contents of a ticket in the ticket
tracking system, John must then select the ticket cache containing
tickets for "johndoe at QA.COMPANY.COM" and open the ticket. As you
might imagine, manually switching client principals gets old fast.
Currently sites in this situation create scripts which set KRB5CCNAME
to the cache with the appropriate tickets and then launch the
relevant application. Users then use these scripts to launch the
application rather than launching the application itself so that each
application gets its own default ccache. Unfortunately this requires
sysadmin involvement in the setup of client machines and interacts
poorly with the graphical user experience on some OSes (eg: Windows
and Mac OS X).
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.
4) Use of SASL/TLS/SPNEGO to negotiate something other than Kerberos
Unfortunately, not all organizations and services use Kerberos. When
negotiating authentication (ie: SASL/TLS/SPNEGO/etc), it is important
that we not interfere with the negotiation of other authentication
Currently Kerberos for Macintosh does a rather poor job of this. If
the user has no tickets at all and tries to connect to a service
which can negotiate Kerberos, KfM will prompt the user to get
Kerberos tickets. If the user can't use Kerberos to connect to that
service, they have to hit cancel every time they connect. We have
alleviated this problem somewhat by only prompting if a krb5.conf
file is present, which means that only Kerberos users who do not
currently have tickets see this problem. This is really a band-aid
5) Use of applications which perform scheduled tasks in the background
A number of sites make use of long running processes which perform
Kerberos-authenticated operations at regular intervals. Probably the
most common of these are mail applications which check mail every N
When designing our selection algorithm we should be aware that if we
prompt the user from inside the library, we may be doing it
frequently and not in response to any user action. In particular we
need to avoid popping up questions over whatever task the user is
really doing, interrupting them and stealing focus from the frontmost
6) Ticket acquisition via secure authentication screens
Windows tries to get users to authenticate via its secure login
screen. Due to the fact that it's really easy to spoof regular
authentication dialogs and steal the user's password, I suspect that
other operating systems are eventually going to implement something
similar. At that time we should probably start using it and would no
longer be able to seamlessly prompt the user for new tickets.
Traditional Kerberos installations use fully qualified hostnames and
domain-realm mappings to generate service principals (ie: the "imap"
service on "po12.mit.edu" maps to the service principal "imap/
po12.mit.edu at ATHENA.MIT.EDU"). This allows clients to generate the
service principal from the configuration entered by the user.
Unfortunately this feature requires that the Kerberos sysadmins have
DNS servers (so clients can reverse resolve the server name) and
tightly couple domains and realms so that the client correctly maps
the server's domain to the correct realm. In addition, without
secure DNS this technique is vulnerable to spoofing.
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.
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.
Rather than suggesting a complete and finished algorithm, I'd like to
suggest a series of sub-algorithms which we can use to make a final
algorithm. The reason for this is that I think that there is no one
"ideal" algorithm and that there are multiple reasonable algorithms.
By breaking the algorithms down into the components, we should be
able to describe and compare them more easily.
* 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
For example, another hypothetical user, Jane Doe, works for the IT
department of a company (company.com) that does not use cross-realm
and has separate realms for each department. In addition, Jane also
has an account with a Kerberized email service (secure-email.com) for
her personal email. Here's an example of what she would see when she
runs her mail program:
> janedoe % email
> The application 'email' would like to use Kerberos to communicate
> with the server 'imap26.company.com' using the service 'imap'.
> Which Kerberos identity would you like to use?
> N: Don't use Kerberos.
> 1: janedoe at COMPANY.COM
> 2: janedoe at IT.COMPANY.COM
> 3: jane2643 at SECURE-EMAIL.COM
> P: None of the above. (Prompt to get tickets for a new
The problem is that Jane may not know what principal to use. Most of
us could guess that the first principal "janedoe at COMPANY.COM" is the
right one to use. But maybe the IT department has its own email
services (but not its own subdomain) and the answer is really
"janedoe at IT.COMPANY.COM".
To make matters worse, Jane may have configured her mail program to
check mail for both her work email and her secure-email account. If
this is the case she will get this question twice (once for each
mailbox) and need to answer "2" the first time and "3" the second
time. If she hasn't already gotten tickets for
'janedoe at QA.COMPANY.COM' and 'jane2643 at SECURE-EMAIL.COM', then she
will have to answer "P" twice and enter those two principal names
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.
* Negative Caching:
Let's say Jane has a third email account which does not use Kerberos,
but runs servers which are capable of negotiating Kerberos via TLS.
To avoid prompting Jane to answer "N" every time through, we would
also need to cache negative cache entries (ie: 'don't use any client
principal for service 'imap' and server 'imap.company.com').
Unfortunately, if we do negative caching, then we will run into
problems when a site using SASL/TLS/SPNEGO adds Kerberos support for
a service that previously didn't support it. Because the service
didn't previously support Kerberos, users will have cache entries
that say not to use Kerberos. Rather than a seamless upgrade, the
site would have to force all the users to run some tool that removes
the negative entry from their cache. This greatly reduces the
usefulness of wrapping Kerberos in authentication negotiation systems
like SASL, SPNEGO and TLS.
(Note that stale data is not a problem for positive caching because
if the client principal fails to get the service ticket for the
service then we know the entry is stale and can delete it.)
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
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.
Rather than prompting the user and having the site's support staff
hand-holding all their users through these questions, we could search
for the correct principal in the cache collection. Here's a
potential simplistic cache search order:
1) client principal of the system default cache
Searching the system default cache first allows the user to control
which principal is selected if user has tickets for multiple
principals which can access the service. So if the user has
user at REALM and user/admin at REALM they can keep user at REALM selected as
the default and know that user/admin at REALM won't accidentally get used.
2) client principals in the realm mapped to by the server's domain
Searching matching realms next prevents obscure cross-realm paths
from being used when there is a direct path available. For example
if realms A.COM and B.COM share keys and the user has tickets for
user at A.COM and user at B.COM, when the user tries to connect to
server.a.com, they won't accidentally end up using their user at B.COM
tickets. (Note that we could come up with an even more elaborate
algorithm so that we use the shortest cross-realm path or the most
trusted one -- I just don't want to get bogged down in details.)
3) remaining client principals
Necessary to catch any referrals-based or cross-realm paths.
* 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.
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
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.
Initial Ticket Acquisition:
As you've probably noticed, I have yet to discuss how the user gets
TGTs in the first place. The reason I delayed this discussion is
that it's probably the hardest part to get right. On the one hand
we'd like to make Kerberos as easy to use and prompt the user rather
than producing a "no tickets -- go run kinit" error. On the other
hand we can't harass non-Kerberos users with Kerberos related questions.
Whether or not it's okay to prompt depends on what information the
Kerberos libraries currently have about the server and service. As a
result I'll break this discussion down into the various states the
library can be in at the time it would like to ask the user for more
information. Note that in all the cases here that the library has
already tried all the tickets in the cache collection.
* A cache entry exists for the server/service pair
In this case it should be safe to prompt if no tickets (or only
expired tickets) for the client principal exist. If a cache entry
exists then we know the user has successfully used Kerberos for this
service already, and we know which client principal the user needs to
get. Because we know the client principal, we can even pre-fill the
authentication dialog/prompt with the client principal in the cache
entry so the user knows which principal they need to get tickets for.
* A hint exists for the server/service pair but no cache entry
Whether or not we prompt here really depends on how we decide hints
should be used. If hints are something you provide even if the
service doesn't use Kerberos, then we shouldn't prompt. But if the
presence of a hint indicates the service probably uses Kerberos, then
we should prompt, filling in as much information about the client
principal as possible. I would recommend the latter since it allows
sites to use hints to improve the user experience (ie: Kerberos will
work without a hint, but will be more user-friendly if you have one).
* No hint or cache entry exists
This is the real problem case. I would argue that you can't prompt
here. The problem is that if you are using SPNEGO/TLS/SASL, you
don't know whether or not the user even wants to use Kerberos. If
they don't, then prompting will only irritate them.
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
Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
More information about the krbdev