Mail.app with multiple accounts using Kerberos

[Jeffrey Altman]

John Rudd wrote:

> Jeffrey Altman wrote:
> 
> 
>> 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.
> 
> 
> 
> That seems almost like an "over-engineered" type response.
> 
> What is wrong with making the application maintain that knowledge?

There is nothing wrong with having a mail application that already
stores large quantities of information about the connection types,
authentication methods, mailbox configuration, etc. from keeping track
of a Kerberos client principal.

There are also a small enough number of mailboxes that a user connects
from the mail client that it becomes reasonable to do so.

However, try to extend this model to a web browser where there are
literally thousands of destinations a user may visit in a year and you
will see that it becomes impractical for the user to configure this
information for each service (aka URL).

> Afterall, that's exactly the purpose of preferences databases and rc-files.
> 
> Using your email example:
> 
> 1) Have the application record:
> 
>    a) A default principle for the application,
> 
>    b) A default principle for each mail personality (which may itself
> default to "email-userid at defalt-realm" and let the user change that
> manually), and
> 
>    c) A specific principle for each folder/resource.

You can certainly do this.

> 2) If none of those preferences exist, ask the user which of the
> principles in their cache is the right one to use for that resource (and
> offer a "none of these" option; if they choose that, then invoke your
> kinit type program, and update your list of choices to offer when it
> returns).  And give them a checkbox for "remember this principle for
> this resource".

Now you are getting to the tricky part.   It is highly likely that the
user does not have the necessary principal in the cache.   Part of the
purpose of configuring the client principal up front in the mail
application case is so the Kerberos libraries (preferably via an
secure attention key mechanism) can obtain the required credentials
for the user.

Also remember that Kerberos is not the only authentication method
available.  Should the mail client use an X.509 certificate instead?
What about SASL Plain over TLS as is so popular?

If you cache the response for one folder, does this become the default
for all folders?   Will end users be savy enough to understand why they
suddenly can't access the desired resource when authentication succeeded
if they are using the wrong principal?

Think about the case in which there are multiple principals the user
might use with different authorization privileges.   It could be
multiple principals from the same realm or even multiple principals from
multiple realms if there are cross-realm trusts.

> 
> If they end up with a lesser degree of access to a folder because they
> didn't specify 1c, then they need to specify 1c.

99% of users are not going to grok this.   Support desks will suddenly
become extremely unhappy.

> For AFS, access to the local cell is presumably going to happen at a
> point where you only have 1 principle to choose from (assuming you're
> doing a kerberos PAM and then an afs PAM that leverages your kerberos
> ticket;  otherwise, it should default to username@(an explicit realm
> setting for that AFS cell) ).  Once you've got a home directory that you
> can read from, have a .afsrc file in your home directory which tells AFS
> which principle goes with which cell (or even which principle goes with
> directory within a volume within a cell).  Same thing as for email,
> really, just a slightly different implementation.

Is the kernel module supposed to be aware of "user home directory" so
it knows where to find the .afsrc for a given user?

Besides, the need for different client principals and therefore
different tokens in AFS is much less about the "cell" or even the
"path".  Its about what process is being executed and for what purpose.

There simply is not a single identity that can be used.   This is why
process authentication groups are so important to AFS users.

> As for multiple principles in one cache: if the limitation is that
> there's only one KDC time-offset entry in the cache, then extend the
> cache format so that it can have a different time-offset for each KDC
> that it needs to deal with.  (the idea that you would need to have a
> different cache file for each principle is rather repugnant)

There is nothing wrong with having separate caches for each principal.
You could theoretically define a new file based data structure that
is used to store multiple caches.   A cache in our view is a binding
of principal name to credentials that belong to that identity.  In
the CCAPI implementations, a cache contains credentials of multiple
types.

The real problem that needs to be solved here is how does the library
enumerate the list of available principals.  Not how they are stored.
In the CCAPI there is the ability to enumerate the list of caches and
obtain the associated principals.   However, it is not good enough to
assume that all of your caches are of the same type.   We need a
mechanism that allows enumeration to include:

	* files
	* ccapi
	* mslsa (on Windows)
	* memory
	* other system dependent credential stores

Jeffrey Altman


-- 
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu