[Dovecot] Enhanced Kerberos support
Richard A Nelson
cowboy at linux.vnet.ibm.com
Mon Dec 31 19:09:32 EET 2007
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
More information about the dovecot
mailing list