Kerberos authentication to load-balanced services in AWS and reverse DNS

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Kerberos authentication to load-balanced services in AWS and reverse DNS

Adam Lewenberg
The Stanford OpenLDAP service relies almost exclusively on GSSAPI
authentication for its access control. This means clients doing LDAP
searches use Kerberos. Normally, Kerberos authentication depends on
specific DNS configuration.

----
Example: A client search

   ldapsearch -h ldap.stanford.edu uid=joeuser

1. The client resolves ldap.stanford.edu resolves to address 171.64.13.16

2. The client does a reverse DNS lookup on this IP address to get a
hostname, in this case, ldap-lb.stanford.edu

3. If the hostname from step 2 does not match the host part of the
principal in one of the entries on the server's keytab file, the
Kerberos authentication will fail. In our example, 171.64.13.16 resolves
to ldap-lb.stanford.edu, which is the name used in the keytab file, so
everything is fine.
----

Because we control the IP addresses and DNS records on campus, it is no
problem to make sure that the PTR (i.e., "reverse") DNS records are
configured so that process works properly.

However, for services in the cloud this becomes more of a problem. It
seems that Amazon Web Services does not give us the option to control
the PTR DNS records to support Kerberos's reverse DNS authentication, at
least not when we are using their ELB (Elastic Load Balancer) service.

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?

2. Is there another way to configure our Kerberos and/or OpenLDAP so
that clients using Kerberos with reverse DNS as part of the
authentication process still works?

Thanks, Adam Lewenberg




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication to load-balanced services in AWS and reverse DNS

Jeffrey Hutzelman
On January 6, 2017 10:21:18 AM EST, Adam Lewenberg <[hidden email]> 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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication to load-balanced services in AWS and reverse DNS

Russ Allbery-2
Jeffrey Hutzelman <[hidden email]> writes:

> 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.

Originally, we locally patched Cyrus SASL to fix this bug.  I don't recall
if that was still the case or if we managed to at least get that patch as
far upstream as the Debian package.

> 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.

Yup, that was the fix.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication to load-balanced services in AWS and reverse DNS

Henry B (Hank) Hotz, CISSP-2
That is recommended in any case. The service should have its own keytab, and you control the allowed names by what's in the keytab. Much simpler coding as well.

Personal email. [hidden email]

> On Jan 6, 2017, at 9:13 AM, Russ Allbery <[hidden email]> wrote:
>
> Jeffrey Hutzelman <[hidden email]> writes:
>
>> 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.
>
> Originally, we locally patched Cyrus SASL to fix this bug.  I don't recall
> if that was still the case or if we managed to at least get that patch as
> far upstream as the Debian package.
>
>> 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.
>
> Yup, that was the fix.
>
> --
> Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>

Loading...