Hi Timo, Richard,

On Tue, 2007-11-13 at 14:16 -0800, Richard A Nelson wrote:

...

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. I'm a bit curious as to why you would want to be strict about this - is

On Mon, 2007-11-26 at 15:54 +0200, Timo Sirainen wrote: this serving multiple realms?

...

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.. Perhaps we can just do this in case the option equivalent to GSSAPIStrictAcceptorCheck is enabled or perhaps some other option to enable gssapi multi-homing?

I guess blocking DNS lookups for local IPs should be pretty safe and fast. Perhaps a new %D variable modifier, so you could do auth_gssapi_hostname = %Dl. Since these shouldn't be used for remote lookups, Dovecot could also cache them (with upper limit 100 or something). Yeah, that would make sense I think.

Cheers,

Jelmer

Jelmer Vernooij jelmer@samba.org - http://samba.org/~jelmer/

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

Greg Troxel wrote:

Timo Sirainen tss@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@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