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
