Client Principal Selection
lxs at MIT.EDU
Mon Jul 11 15:41:19 EDT 2005
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
>> 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
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
> 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
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
>> 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
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
> 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
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
>> * 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
>> 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
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
> For the rest, clearly prompting is a vary bad idea. Don't do it.
> If it
> means more configuration, oh well. See above.
Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
More information about the krbdev