Client Principal Selection

Nicolas Williams Nicolas.Williams at
Mon Jul 11 16:31:43 EDT 2005

On Mon, Jul 11, 2005 at 03:41:19PM -0400, Alexandra Ellwood wrote:
> 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
> >
> >>3) Multiple client principals with different privileges (ie:
> >>user at EXAMPLE.COM and user/admin at EXAMPLE.COM)
> >>
> >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 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.

Right -- they're similar only assuming a solution that binds each
application instance to a single client principal and its credentials.

They are dissimilar otherwise.

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

I was referring to the need or desire to track groups of processes --
initial group members and progeny.  It isn't necessarily easy to do that
portably without making use of environment variables.

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

Sure, that's a lot of online work -- though it can be parallelized.  And
the results may not be deterministic (what if more than one client
principal can get a service ticket for the target?  how should one or
another be selected?).

> 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

Yes, clearly this approach has privacy issues.

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

I didn't suggest discussing technical details of referrals, but whether
there might be a need for a feature that could be brought to the KRB
WG's attention.  I don't see why that wouldn't be in scope here, except
unless you reject the use of referrals immediately due to the issues

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

Sure, which leads you down the distributed configuration/hints path.

> >
> >>* 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 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
> >>
> >                                   ^
> >                   not?
> >
> If the site is using cross realm, then a service at 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.

Ah, I get it.

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

Yes, such configuration should be delivered securely.  As securely as
DNS (i.e., if you want it secure deploy DNSSEC) is probably OK.


More information about the krbdev mailing list