Client Principal Selection

[David M. O'Rourke]

this is a wonderful write up - I believe alexis did a fantastic job  
outlining the scenarios.

I've read most of the discussion and I'm still working to digest it.   
For our immediate needs the most interesting scenario is my opinion  
is the single user encountering multiple realms where there is no   
pre-arranged cross-realm authentication.  (item #2 for those of you  
working from the list).

The issue of multiple identities in the "same" realm is less  
interesting and has I believe existing workarounds in most OS's (i.e.  
I can simply log into two separate user sessions on the OS of my  
choice, Windows XP, and Mac OS both fully support this functionality  
via user switching).   While not ideal, I would hate to sacrifice a  
good solution to #1 because it doesn't fully address a solution for #3.

Also in the area of UI - I believe the UI in this circumstance can  
initially be intrusive and the user can train the UI to be less and  
less intrusive over time.  As I'm roaming the network the initial  
ticket aquisition UI could be modified to state....

     a) Mail.app is attempting to login to mail.apple.com @ realm  
kerberos.apple.com would you like to:

             Attempt to use an existing TGT [show pop-up list here]
             Obtain a new TGT
                     name
                     password
             Not use Kerberos for this authentication

                 Ã Save my preference to keychain/secure user preference

If you look at the safari interface for saving passwords for web- 
sites it's not too terrible: never save for this site, don't save  
this time, save for future use.

The support for multiple realm authentication needs to be present,  
but it doesn't require a fully automatic system and we can work with  
the user to allow them to adjust the degree of intrusion...

I'm giving this conversation much more thought but thought I would  
weigh in with some high-level thoughts...

On Jul 8, 2005, at 1:29 PM, Alexandra Ellwood wrote:

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