Kerberize MS Exchange?

[Ken Hornstein]

>> - 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! 
>As you probably know, you can do that with the sasl mechlist server side.

Well, of course I can limit mechanisms on the server side; that's easy
and nearly all of the server software support this.  But I don't want to.

Why, you ask?  The normal mode for us is to have people use GSSAPI.  But
occasionally we get someone who, for some strange reason, cannot use
GSSAPI.  These people are, on a case-by-case basis, permitted to use
another SASL mechanism, like DIGEST-MD5 (actually, it's always CRAM-MD5,
which is the one mechanism that everyone seems to support).  So I want
my _SERVER_ to be able to support multiple mechanisms.  You might claim
that I could run servers that support different mechanisms on different
ports; that would be a violation of the DoD Ports and Protocols Policy,
but aside from that, not only is that a pain in the ass from a client
configuration standpoint it also sort of defeats the whole point of
SASL, which is to create a protocol framework where multiple security
protocols can be negotiated on the same port.  In my experience, the
servers all handle multi-mechanism negotation fine; it's the clients
(like, say, Thunderbird) that need work.

>I's not common put possible (you'd have to have credentials in more than 
>one place (not so good)), however DIGEST-MD5 and others might still work 
>where GSSAPI will fail (e.g. roadwarriors with broken time sync, no 
>ticket, KDC not reacheable from the client, etc.)

Well, in theory, maybe; perhaps you maintain synchronization between
your DIGEST-MD5 and KDC database.  But very likely if you have a user
using GSSAPI, Thunderbird does not have their password stored, because
all the GSSAPI mechanism has access to is their TGT; this will involve
an additional prompt, or as you mention Thunderbird will have this
stored.  But trying multiple mechanisms causes the problems I mentioned
earlier; I would argue that is more common than having multiple valid
mechanisms for every user.

>>   If the user explicitly picks a mechanism to use, these
>>   problems are eliminated.  
>My point is that SASL mechanisms are all greek to average users, it is 
>pointless to force a choice on them they can't reasonably make.

I would argue that my experience with Apple Mail contradicts this
assertion.  Note that Apple Mail doesn't present the user with a choice
of SASL dialogs right up front; it's under an "Advanced" dialog.  And
there are plain-text names for the SASL mechanisms, like "Kerberos 5
(GSSAPI)", and "MD5 Challenge-Response".  This seems like a reasonable
choice to me; it doesn't confuse the average user who would have no idea
what GSSAPI is, but the advanced user can adjust the appropriate knobs.

>>   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).
>Again, you can configure SASL server side to prevent this. Postfix for 
>example has options to allow different mechanisms over TLS secured 
>connections vs. plain SMTP.

See above; this simply isn't good enough.

>As I said, a log would be nice. IMO if the site policy *allows* GSSAPI 
>and say NTLM fallback there should be no error if GSSAPI fails and NTLM 
>succeeds. A user visible failure is only required if all allowed 
>mechanisms failed because this ultimately results in a failed service 
>(reading email).

Personally, I think is a rather bizarre site policy (do you still
support cleartext telnet just in case ssh doesn't work?), but
nevertheless ... I think that most people would agree that it is at
least uncommon.  To me this argues that you might (as a user) want to
select a range of valid mechanisms for your site; you could click a
series of checkboxes for valid mechanisms to use when connecting to a
server.  But I think that if you normally use Kerberos at your site,
and Kerberos isn't working, the user should be notified!  That's not
the normal behavior!

>Well, afaik if GSSAPI is the only mechanism advertised by the server 
>there will be no password prompt. If the fallback is allowed you'd get a 
>prompt. It's pretty much the same thing as you get with HTTP-Negotiate 
>where NTLM will prompt but kerberos will not. It's the admins choice...

That may be true for Thunderbird, but I have personally seen programs
that still ask for a password prompt even when they were using Kerberos.
Yes, that's a bug; no argument there.

>Hmm, I can see where you are coming from... You say TB is hard to debug 
>wrt. failures because you don't get error messages? Granted, if TB had a 
>"use kerberos" checkbox you'd at least know that it was kerberos that 
>failed (but still no error messages, no?). And with proper error 
>messages you'd get all the info in the "secure authentication" case as well.

Well ... except that you'd have to try to dig out the "right" errors from
the failures with mechanisms you don't care about.  I've stared at too many
ssh debugging traces to think that's a good idea.

--Ken