This is a discussion on Re: Kerberize MS Exchange? - Kerberos ; >Luke Scharf schrieb: >> I use Thunderbird with GSSAPI with Dovecot on my home-network. It works >> nicely. The only weird thing was that they used the term "Secure >> Authentication" -- instead of "GSSAPI" or "Kerberos5" or "krb5". >Thats ...
>Luke Scharf schrieb:
>> I use Thunderbird with GSSAPI with Dovecot on my home-network. It works
>> nicely. The only weird thing was that they used the term "Secure
>> Authentication" -- instead of "GSSAPI" or "Kerberos5" or "krb5".
>Thats by design. Technically GSSAPI is only one of the SASL mechanisms
>offered by the server. "secure authentication" just enables the SASL
>negotiation procedure which might result in something completely
>different than GSSAPI (DIGEST-MD5 in my case, or NTLM for Outlook, etc).
>Besides: "GSSAPI" or "Kerberos5" in a general purpose UI? WTF!
Urrrrk. I STRONGLY disagree with you on this! Here are my reasons:
- From the programmer/network protocol perspective, being able to write one
program or define one protocol that negotiates a whole group of SASL
mechanisms is great. But from an administrator perspective, it
bites. I don't want to have users fall back to DIGEST-MD5 if
Kerberos fails, I want to fix the Kerberos problem! (And very likely
if GSSAPI fails, DIGEST-MD5 isn't going to work for that user anyway;
of course that depends on your site, but I think that's more true
than not). If the user explicitly picks a mechanism to use, these
problems are eliminated. Since many mainstream apps have each SASL
mechanism coded explicitly (Thunderbird among them) there's not even
a programming reason to obfuscate the choice of SASL mechanism (and
explicitly picking the mechanism prevents a downgrade attack).
- From a user and administrator perspective, the whole situation with
Thunderbird bites. Note: I've talked with Simon about this; I
understand the situation he was faced with regarding Thunderbird and
GSSAPI support, and I'm glad he was able to get it in there. But I
believe even he would admit the current situation is not ideal (and
I know that it would be tough for him to address it).
I've helped a number of people get GSSAPI with Thunderbird working.
The general flow of questions looks like this:
- Uh, does it support Kerberos? I don't see anything where I can enable
it under Preferences.
- So, uh, if it supports Kerberos, how do I turn it on?
- Okay, I checked "Secure Authentication", but that didn't work, and
it asked me for a password. I typed in my Kerberos password, but that
First off, "Secure Authentication" is a ****TY checkbox. What this
means is not clear, even to me. Does this mean "Use TLS?" Does this
mean "Negotiate SASL?" Does it mean both? It's confusing to the
user. If it was one user, I would say that this confusion is an
anomaly, but it seems like EVERYONE that tries to use Thunderbird
here has problems with this.
Secondly, the "attempt to negotiate all mechanisms" problem generates
a number of practical issues. The first is error reporting - let's
say you try GSSAPI, and that fails. Should you then report GSSAPI
errors back to the user? Well, in Thunderbird that doesn't happen; I
can sort-of understand why Thunderbird doesn't do that, because most
of the users don't use GSSAPI and any GSSAPI errors would be the
"wrong" errors, but this illustrates the problem with multi-mechanism
negotiation: which errors do you report to the user when you try
Another problem with multi-mechanism negotiation is that they have
different user interactions. For example, CRAM-MD5 and DIGEST-MD5
likely want to prompt the user for a password, but of course for
GSSAPI/Kerberos you normally wouldn't have the app do that; it would
be done via a Kerberos application (or perhaps the GSSAPI library
would do that). So should an application prompt for a password no
matter what the mechanism? Probably not, but I've seen cases where
that happens; again, more confusion for the user.
Now, to be fair part of the problem with Thunderbird seems to spring
from the fact that at least on Windows it's using third-party GSSAPI
libraries (at least when we want to use it), and many of the problems
come from finding those GSSAPI libraries. And I know that it is
possible to get the GSSAPI errors by setting some arcane environment
variables. It kinda bites that you have to go through this crappy
process to GET those errors; like I said, I understand why this is
the case, but it still sucks.
Part of the confusion may be historical; many of our users were
previously using Eudora, and that had a weird dance where you in some
cases EXPLICITLY had to not turn on the "Use secure authentication"
dialog (but it also had an explicit Kerberos configuration dialog).
I can contrast this with people who use Apple Mail, which has a very
clear configuration dialog which explicitly says, "Use Kerberos 5
(GSSAPI)". No one ever asks me if Apple Mail supports Kerberos, or how
to turn it on. The Kerberos errors (in most cases) are presented to
the user. It just works better. Presenting the SASL mechanism to the
user is a clear win. A lot has to happen under the scenes to make
it all work, but I cannot see any reason why presenting this to the
user is bad.