Client Principal Selection

[Nicolas Williams]

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

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 www.porn.com.

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

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

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.

Nico
--