[Dovecot] Enhanced Kerberos support

[Richard A Nelson]

Sorry for the extreme delay in responding, I lost access to this mail account 
during the holidays :(


Greg Troxel wrote:
> Timo Sirainen <tss at iki.fi> writes:
> 
>>> SSH recently added this enhancement to address this common need:
>>>
>>>       GSSAPIStrictAcceptorCheck
>>>               Determines whether to be strict about the identity of the GSSAPI acceptor a client authenticates
>>>               against. If “yes” then the client must authenticate against the host service on the current hostname.
>>>               If “no” then the client may authenticate against any service key stored in the machine’s default
>>>               store. This facility is provided to assist with operation on multi homed machines.  The default is
>>>               “yes”.  Note that this option applies only to protocol version 2 GSSAPI connections, and setting it
>>>               to “no” may only work with recent Kerberos GSSAPI libraries.
>> Somehow this doesn't sound a very good idea.
> 
> This says "the host service on the current hostname", and I interpret
> this as the principal "host/$hostname at MY.REALM", where $hostname is the
> value returned by gethostname(3)/hostname(1).  There is no DNS involved
> in this at all.

Right, that is the 'strict' interpretation
> 
> The alternative is to accept authentication to any principal either of
> the form "host/$HOST@$REALM", as long as that key is stored in the
> machine's keytab.

And this is not 'strict'

>>> I've heard that other daemons support multi-names by instead of using gethostname(), obtain the hostname of the
>>> interface that the request came in on.
>> I guess this would mean a PTR DNS lookup for the local IP? I've wanted
>> to avoid DNS lookups in Dovecot so far, but proxying would also want to
>> use them..
> 
> Yes, you could do this, allowing authentication to various names,
> depending on the interface.  But I would think it's better to have an
> option to either a) just allow the name that's configured as hostname,
> or b) allow any host/ key that's in the keytab.

That split seems to mirror the OpenSSH opinion, and other daemons I've seen

> I don't see that it's useful from a security viewpoint to refuse
> authentication that's done to host/foo when the request is received on
> an interface that has an IP address that doesn't map to foo.  Actually,
> I'd say that it isn't meaningful, for TCP at least, to talk about the
> interface on which a request was received, and even for UDP packets can
> arrive on arbitrary interfaces due to routing changes, and generally
> these have no security consequences.

Agreed, especially considering the Linux philosophy that addresses belong
to the box, not an interface (in contrast to other Unix platforms)

  > What problem are we trying to solve?  The problem I can see is that if a
> server is known by two names, clients may attempt to authenticate to
> both of those names, and that should work (assuming both names have
> service keys present in the keytab).
> 
> Are people trying to run some inside/outside split mailserver that's
> both inside and outside a firewall?

That was, indeed, my first usage case - though I've mostly now manage to
work around this issue with some grief due to DNS changes - though some
edges of the issue remain :(

The next case I've hit the same underlying issue on is my laptop;  At home
it lives on on Kerberos realm, and at work - it lives on entirely another
(of course it talk to either realm at any time, but for sanity's sake it
must have a primary realm that makes sense at the time).

I've allowed cross-realm authentication, and that works somewhat well -
except that the Dovecot SASL implementation specifically disallows having
authc name != authz name (which I've only been able to trigger with
cross-realm authentication).

So, it seems for the laptop case, where DNS obfuscation is not an option,
supporting relaxed host/ checking seems to be the best/only option - the
laptop's keytab does have entries for both realms.

Oh, and yes, I run dovecot everywhere - and only use IMAP access - even to
localhost; for my usage, the benefits are enough to ignore those who argue
that a laptop shouldn't run services (they would be appalled at what else
runs on the box)

-- 
Rick