Client Principal Selection

[Alexandra Ellwood]

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


---------
The Goal:
---------

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.


-------------------
Timing Constraints:
-------------------

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.


-----------------
The Requirements:
-----------------

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

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  
authentication

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

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


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

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


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.


7) Referrals

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.



---------------
The Algorithms:
---------------

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

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  
> identity.)
> (Default=1):

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


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


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


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

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



---------------------------
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  
use Kerberos).


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>