Mail.app with multiple accounts using Kerberos

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Mail.app with multiple accounts using Kerberos

Ross L. Hatton
I've been trying to get Mail.app to work simultaneously with my IMAP  
accounts at two institutions, each of which uses Kerberos  
authentication.  The best I've been able to do as of yet is to  
acquire tickets for each realm, then manually switch primary tickets  
and the online status of the mailboxes.

Is there a more  efficient way to get Mail or another program to  
correctly present the appropriate ticket to each server?

Thanks,
Ross
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

David Botsch
We are also dealing with the same problem here -- on Mac, Windows, and Linux.

What I don't understand is why the kerberos client doesn't seem to be able to
keep multiple tickets for multiple realms in the same cache and choose the
right tgt/service ticket based on the dns name -> realm mapping


Is the only way to accomplish this via crossrealm auth?


On Mon, Aug 15, 2005 at 05:22:36PM -0400, Ross L. Hatton wrote:

> I've been trying to get Mail.app to work simultaneously with my IMAP  
> accounts at two institutions, each of which uses Kerberos  
> authentication.  The best I've been able to do as of yet is to  
> acquire tickets for each realm, then manually switch primary tickets  
> and the online status of the mailboxes.
>
> Is there a more  efficient way to get Mail or another program to  
> correctly present the appropriate ticket to each server?
>
> Thanks,
> Ross
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
[hidden email]
********************************
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

Ken Hornstein
>We are also dealing with the same problem here -- on Mac, Windows, and Linux.
>
>What I don't understand is why the kerberos client doesn't seem to be able to
>keep multiple tickets for multiple realms in the same cache and choose the
>right tgt/service ticket based on the dns name -> realm mapping

There are a couple of problems:

- There is something in the credential cache called the "primary principal",
  or the "default principal".  It's the first thing printed out by klist.

  The Kerberos APIs need to have a client principal fed into them to
  construct the service ticket request.  Virtually all code today gets
  this principal from the primary principal in the credential cache.
  While it's possible to put multiple TGTs in the credential cache today,
  no apps will make use of them.  On some platforms you can have multiple
  TGTs in seperate "sessions" and switch between them (MacOS X), but
  when the "session" is switched, so is the primary principal.

- Let's pretend this isn't a problem.  The problem then becomes ... how do
  you decide what to do?  Do you attempt cross-realm authentication?  Do
  you search the credential cache for a TGT in the foreign realm and use
  that?  There is, unfortunately, no good answer ... although people are
  exploring the options.

The sites that I've seen address this today do so by setting up cross-realm
authentication.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

David Botsch
>
> There are a couple of problems:
>
> - There is something in the credential cache called the "primary principal",
>   or the "default principal".  It's the first thing printed out by klist.

I want to make sure we are clear here... I am dealing with the problem of > 1
principals in multiple realms (eg principal a in realm xyz.com and principal b
in realm abc.com) and not the same realm (eg principal a in realm xyz.com and
principal b also in realm xyz.com) -- 2 different problems.

At first glance, it would seem that given more than 1 principal w. each
principal in a separate realm, if you want to choose the default, well, there
is this "default_realm" value in the  kerberos config file. Otherwise, look at
the dns name of the server to which we want to connect.

>
>   The Kerberos APIs need to have a client principal fed into them to
>   construct the service ticket request.  Virtually all code today gets
>   this principal from the primary principal in the credential cache.
>   While it's possible to put multiple TGTs in the credential cache today,
>   no apps will make use of them.  On some platforms you can have multiple

Does this no apps making use of the multiple TGTs have to do w. the design of
the credentials? Or just programmers making the assumption that no one would
ever want to, say, check mail in 2 different realms at the same time?


>   TGTs in seperate "sessions" and switch between them (MacOS X), but
>   when the "session" is switched, so is the primary principal.

And, interesting things happen if I, say, select the principal from a different
realm than the server to which I am trying to connect. I've seen it do things
such as take the principal and slap the wrong realm name on there and send that
to the server.

>
> - Let's pretend this isn't a problem.  The problem then becomes ... how do
>   you decide what to do?  Do you attempt cross-realm authentication?  Do
>   you search the credential cache for a TGT in the foreign realm and use
>   that?  There is, unfortunately, no good answer ... although people are
>   exploring the options.
>

The easy out is, what does the config file say to do?


> The sites that I've seen address this today do so by setting up cross-realm
> authentication.

Unfortunately, this has a whole slew of "do I trust the other realm?" problems
:(

>
> --Ken
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
[hidden email]
********************************
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

Ken Hornstein
>> There are a couple of problems:
>>
>> - There is something in the credential cache called the "primary principal",
>>   or the "default principal".  It's the first thing printed out by klist.
>
>I want to make sure we are clear here... I am dealing with the problem of > 1
>principals in multiple realms (eg principal a in realm xyz.com and principal b
>in realm abc.com) and not the same realm (eg principal a in realm xyz.com and
>principal b also in realm xyz.com) -- 2 different problems.

Yes, I understand you; that's what I'm talking about as well.

>At first glance, it would seem that given more than 1 principal w. each
>principal in a separate realm, if you want to choose the default, well, there
>is this "default_realm" value in the  kerberos config file. Otherwise, look at
>the dns name of the server to which we want to connect.

Technially, you don't care about the DNS name of the server ... what you
care about is the _realm_ the server is in.  A minor, but important
distinction.

Now ... to answer your question more completely ...

- There isn't a good way for an application to get access to the
  "default_realm" value in the config file.  Yes, there is
  krb5_get_default_realm() ... but that can be overridden by
  krb5_set_default_realm().  But what that configuration option
  really means is "append this when you're converting a user-supplied
  unqualified principal".  It doesn't have any other meaning, and it's
  really designed to be used internally by the library.

- How exactly do I know that I _want_ to use the default, versus some other
  realm's client principal?  This is the crux of the problem, and I don't
  think you've quite grasped the issue here.  There is currently no way
  to determine if I should do cross-realm versus try a different client
  TGT ... and since the current library really doesn't support multiple client
  principals in the credential cache, no one has figured out the right
  behavior to do when you _do_ have multiple client tickets in the
  credential cache.  Even MacOS X cheats; when you switch principals,
  it changes the whole credential cache out.

>Does this no apps making use of the multiple TGTs have to do w. the design of
>the credentials? Or just programmers making the assumption that no one would
>ever want to, say, check mail in 2 different realms at the same time?

Technically, you _can_ check mail in two different realms at the same time.
You just can't use two different client principals in the same credential
cache.

It's a combination of:

- Not-wonderful API

        When you get credentials for a service, you need to fill in the
        client credential structure.  Under the current API, this is not
        optional - so you need to fill it in with _something_.  How
        do you determine what "something" is?  Well, the only way to
        reasonably deal with that today is to take the default principal
        out of the credential cache and use that to fill it in.

        Now, you're going to say, "Well, look at the service realm" ...
        okay, assuming that was a good idea (it would break for sites
        that do cross-realm), _that_ just gets me the realm.  Where
        do I get the username portion of the principal?  You could
        in theory iterate over the credential cache and look for TGTs
        that match the service realm, but that ends up being a lot of
        code.  And that's assuming that you're using the raw Kerberos
        API.  If you're checking email, then you're using GSSAPI, and
        I'm not sure there is a way to pass in a client identity to that
        API (it may be possible, I am not the GSSAPI expert).

- Lack of documentation/example programs

        All of the example programs I've ever seen out there all get
        the client principal from the default principal in the credential
        cache.  So there is now a large body of code that does it this
        way.

- Original model where most people did cross-realm authentication.

        Like I said, the original model for this was that you should
        cross-realm in this scenario.  That of course affected the
        API and application design.

>>   TGTs in seperate "sessions" and switch between them (MacOS X), but
>>   when the "session" is switched, so is the primary principal.
>
>And, interesting things happen if I, say, select the principal from a different
>realm than the server to which I am trying to connect. I've seen it do things
>such as take the principal and slap the wrong realm name on there and send that
>to the server.

That surprises me, but I could believe that it happens.

>> - Let's pretend this isn't a problem.  The problem then becomes ... how do
>>   you decide what to do?  Do you attempt cross-realm authentication?  Do
>>   you search the credential cache for a TGT in the foreign realm and use
>>   that?  There is, unfortunately, no good answer ... although people are
>>   exploring the options.
>>
>
>The easy out is, what does the config file say to do?

Except the config file doesn't really have a setting today that addresses
this.

>> The sites that I've seen address this today do so by setting up cross-realm
>> authentication.
>
>Unfortunately, this has a whole slew of "do I trust the other realm?" problems
>:(

There's essentially no reason for you to not do cross-realm with anyone.
The real problem is that people don't understand that.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

Jeffrey Altman-3
In reply to this post by David Botsch
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 joe@A and joe@B and wants to access mailboxes with service names
of mail@A and mail@B.  Ok.  This seems simple enough, we can just
match the realm names.  But what if you have multiple mailboxes
served by mail@B and one of them is an administrative account.  How is
the mail application supposed to be able to choose between joe@B and
joe/admin@B when contacting mail@B for the personal and admin mailboxes?

What about the case where you have a distributed file system such as
AFS and you have cell@A and cell@B with a cross-realm trust between
A and B.  It is possible for joe@B to be used to contact cell@A and
doing so will get different access than joe@A 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

John Rudd
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?
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@defalt-realm" and let the user change that
manually), and

    c) A specific principle for each folder/resource.

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


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.

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.


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)
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

Jeffrey Altman-3
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@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
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Mail.app with multiple accounts using Kerberos

hartmans
>>>>> "Jeffrey" == Jeffrey Altman <[hidden email]> writes:

    Jeffrey> 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?

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

Note that we have been having a series of meetings to try and
determine our direction with regard to supporting these features.  It
seems fairly clear that we will end up making it easier for
applications that want to specify a specific client principal to do
so.  We are also working on solving the more general problems Jeff
describes.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos