On January 6, 2017 10:21:18 AM EST, Adam Lewenberg <ada...@stanford.edu> wrote:
>1. One option is to require all of customers to use Kerberos with the 
>reverse DNS lookup disabled. How much extra risk do we take on by not 
>using the reverse DNS check?

Security-wise, none at all.  The reverse DNS lookup is not a feature of the 
Kerberos protocol, and in fact is expressly prohibited, because it allows an 
attacker to substitute a different Kerberos service principal name than the one 
you were expecting, potentially causing you to trust an a service operated by 
the attacker.

In practice, most Kerberos and GSSAPI implementations do the reverse lookup 
anyway, because it makes it more convenient when a service runs on a host with 
multiple aliases.  It's only been relatively recently that it's become possible 
to reliably turn it off. Fortunately, the attack is mostly theoretical -- it 
doesn't work if you're authenticating the server some other way (for example, 
by verifying its X.509 certificate or ssh host key), and it doesn't matter 
unless the client is trusting the server in some way (for example, by sending 
it a password or relying on it to make some authorization decision).

The problem you may be more likely to run into is that the server might not 
actually be able to accept tickets for more than one service principal at a 
time.  That is, it can be configured to accept the server's own principal name 
or the shared one, but not both.  Cyrus SASL had this problem for a long time, 
and I'm not sure it ever got fixed.

If you're willing to patch, the fix for that problem is actually pretty simple 
-- instead of acquiring GSSAPI acceptor credentials, the server's call to 
gss_accept_sec_context() should simply pass GSS_C_NO_CRED in place of the 
credential argument. Then the server will accept tickets for any principal in 
its keytab.

-- Jeff

Reply via email to