Client Principal Selection

[Nicolas Williams]

On Fri, Jul 08, 2005 at 04:29:27PM -0400, Alexandra Ellwood wrote:
[...]
> 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.

[...]

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

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


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

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

> ---------------
> 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  
                                   ^
				   not?
> 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
desirable.

For the rest, clearly prompting is a vary bad idea.  Don't do it.  If it
means more configuration, oh well.  See above.

Cheers,

Nico
--