The recent addition of auth_gssapi_hostname is a welcome addition, but a little
more is needed
for multi-homed (or multi-domained) sites.
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.
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.
Can either approach be looked at for dovecot ?
Thanks,
--
Richard A Nelson (Rick) cowboy@((linux.)?vnet|us).ibm.com
Phone: 1-408-463-5584 Fax: 1-408-463-3873
COBOL Development IBM Silicon Valley Laboratory
http://www.ibm.com/software/awdtools/cobol/
On Tue, 2007-11-13 at 14:16 -0800, Richard A Nelson wrote:> The recent addition of auth_gssapi_hostname is a welcome addition, but a little more is needed > for multi-homed (or multi-domained) sites.I haven't implemented Dovecot's GSSAPI code and my GSSAPI/Kerberos knowledge is pretty limited. I guess some day I should find out more about it. So, Cc'd Jelmer in case he has some comments/ideas.> 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'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.. 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). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20071126/50f2bbf5/attachment-0002.bin>
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. 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. None of this involves DNS lookups.>> 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. 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.> I guess blocking DNS lookups for local IPs should be pretty safe and > fast.Why? If the local DNS responder is hosed, it will be messy. But this is much less scary than lookups on random addresses. 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?