Client Principal Selection

[Alexandra Ellwood]

On Jul 11, 2005, at 2:31 PM, Nicolas Williams wrote:

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

They're similar problems given the current KRB5CCNAME/system default  
principal model of client principal selection.  However, once we  
start caching or searching they become different problems because in  
#2 it's very likely that only one of the client principals can  
actually authenticate to the service -- or that one authentication  
path is obviously preferable to the other.  In #3 both the user at REALM  
and user/admin at REALM principals can successfully authenticate.

Note that the KRB5CCNAME/system default principal model is  
insufficient for applications like Mail.app or Eudora which support  
getting email for multiple accounts.  Fortunately right now we  
haven't gotten users with two Kerberos-using email accounts, but if  
we're successful in increasing Kerberos deployment we'll eventually  
have some.


> In any case, use of any OS facility more advanced than environment
> variables runs into portability problems.

Once the CCAPI gets ported to Unix we should have a lot more  
flexibility in what we can do.  The CCAPI only requires the OS  
provide a local RPC and has been written to support two platforms  
with wildly different local RPC models (Mac OS X and Windows).  The  
rest of the CCAPI functionality is provided through the RPC layer  
including the ability to have multiple ccaches and iterate over them.


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

No, the KLL is actually primarily intended for GUI programs that  
perform the functionality of kinit/klist/kdestroy/etc (ie: a  
replacement for the krb5_get_init_creds* APIs).  It provides APIs for  
seamless acquisition and control of both v4 and v5 tickets,  
controlling ticket options, graphical hardware preauth prompting, and  
plugins for automatically performing operations (like getting AFS  
tokens) on ticket acquisition and renewal.

Much of the KLL use is internal to the Kerberos for Macintosh  
product.  However, the Mac platform also has a reasonable number of  
callers which use the KLL to "get around" the limitations of the  
current KRB5CCNAME/system default principal model or to provide their  
own custom interface for ticket acquisition.  I've seen several  
postings to the Kerberos lists from folks calling krb5_init_creds*  
from their application for basically the same reasons so I assume if  
we provide a KLL for Unix and Windows they will come. :-)

Since all the platform specific GUI code for ticket acquisition lives  
in the KLL, it's also what the krb5 library calls on the Mac to  
automatically prompt the user to renew their tickets.  The call that  
does this is private, but makes extensive use of the regular KLL APIs.


The initial reason we started redesigning the KLL is that it needs to  
become thread-safe and lose a lot of its Macintosh specific aspects  
before it can become cross-platform.  We'd also like to make it more  
object-oriented so it's easier to write an OOP version of the API.   
However, once I started working on it, I realized that the current  
API is focused on client principals.  In particular it expects  
callers to always know the client principal or want to use the one in  
KRB5CCNAME/the system default ccache.  I got to talking to Sam about  
how this model meshes with the concept of client principal selection  
and we realized that it would be very difficult to use the current  
KLL with some of the algorithms we were proposing.  So I'd like to  
pick a client principal selection algorithm before doing the KLL  
rewrite.


I don't think the new KLL is ever going to be a good fit for a  
generic initial credential API.  In order to provide a good user  
experience, it needs to expose far too much of the details of  
Kerberos (principal formats, ticket options, etc).  If it didn't, the  
GUI authors wouldn't be able to give the user enough control.  What  
the KLL is good at is masking a lot of the details from the novice  
Kerberos developer by providing sane defaults.  So if you don't know  
what ticket options you want to set, you don't need to.  This is in  
contrast to the krb5_get_init_creds APIs which have a bunch of  
usually unnecessary arguments that the caller needs to know should be  
0 or NULL to get the default behavior.


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

Sure, but you can't detect the presence of cross-realm without  
trying.  Which means if we search for the tickets, we will end up  
trying to get referrals from the realm of each of the client  
principals in the cache collection.

This also brings up a point Sam made but I forgot to add to my  
initial email.  If a user uses a Kerberized service they don't want  
people to know they use, our searching algorithm may end up asking  
other realms for a referral for it.  This exposes information about  
the user that they might not want exposed.  For example we might end  
up asking the KDC for COMPANY.COM for a referral for the HTTP service  
for www.porn.com.

> Perhaps we need a requirement for the referrals work that it allow for
> referrals where no cross-realm keys have been exchanged.

I think that's probably outside the scope of this discussion.

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

Some of our customers seem to have performance requirements due to  
using Kerberos over high-latency networks, networks with no DNS and  
networks where large numbers of ports are blocked (causing timeouts).

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

Yes, we will need some interface for editing the cache and/or hints  
table.

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

If the site is using cross realm, then a service at server.a.com may  
actually use the client principal user at B.COM.  I'm not sure how a  
novice user would know that realm A.COM and realm B.COM share keys  
and thus that user at B.COM is the correct client principal to choose.   
If there's no cross realm (and you aren't some ancient thing like  
MIT), then your realm is probably the uppercase of the server's domain.

Of course you may also have no DNS, in which case again, it's not  
easy to intelligently guess.

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

Yes, I'm talking about the site providing this.  I'd also be  
interested in people's thoughts on whether these need to be delivered  
in a secure manner (ie: integrity protected?  privacy protected?).   
Having the hints table be public seems like an information leak and  
being able to add bogus hints it seems like a good way to irritate  
the user, but not much worse than unauthentic DNS SRV records.

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


--lxs

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