David:

There are two very different issues that you raise:

(1) why can't a ccache contain TGTs for multiple principal names?

First, on a system that supports the CCAPI such as MacOS X and
Windows, there is no need to attempt this.   It is possible to query
the list of ccaches and therefore the list of Kerberos principal
names.

Secondly, the ccache does not only contain tickets but it also
stores some information that is realm specific such as the time
offset between the client and the KDCs.   This is used to adjust
the ticket times so that we know when they will actually be valid
instead of just approximating it.

(2) why can't an application just know which client principal is
the correct one for the given service?

This answer is extremely complicated since there are lots of edge
cases.   You are describing a scenario in which the user has tickets
for [EMAIL PROTECTED] and [EMAIL PROTECTED] and wants to access mailboxes with 
service names
of [EMAIL PROTECTED] and [EMAIL PROTECTED]  Ok.  This seems simple enough, we 
can just
match the realm names.  But what if you have multiple mailboxes
served by [EMAIL PROTECTED] and one of them is an administrative account.  How 
is
the mail application supposed to be able to choose between [EMAIL PROTECTED] and
joe/[EMAIL PROTECTED] when contacting [EMAIL PROTECTED] for the personal and 
admin mailboxes?

What about the case where you have a distributed file system such as
AFS and you have [EMAIL PROTECTED] and [EMAIL PROTECTED] with a cross-realm 
trust between
A and B.  It is possible for [EMAIL PROTECTED] to be used to contact [EMAIL 
PROTECTED] and
doing so will get different access than [EMAIL PROTECTED] would.   How would the
file system client automatically choose?

The reality is that in the current day you either need to use
cross-realm or your applications have to maintain knowledge of which
principal should be used to access the given resource.

This is a non-trivial problem.

Jeffrey Altman
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to