Russ Allbery wrote:

My impression is that the broader Kerberos community is increasingly leaning towards not doing DNS canonicalization. That Kerberos libraries have been canonicalizing hostnames using DNS for quite some time is certainly true, but it's considered an unfortunate bug that needs to be supported for backward compatibility but that is clearly not the right way to do things. This is the reason why Kerberos implementations are increasingly adding options to disable DNS canonicalization.

(1) is a vulnerability that Kerberos can protect against if you use it properly. It's called the Zanarotti attack, and the way that you defend against it is by obtaining a service ticket for a principal in a local keytab after initial authentication and verifying that the service ticket matches. This uses your shared secret with the KDC to verify that you're talking to the right KDC.

Leaving aside your followup which clarified this clause: the obvious point is that a Kerberos client needs to have trusted *local* data to protect against this attack. Delegating the trust to the KDC obviously doesn't solve this problem. (Not to mention that again, a KDC is by definition a trusted 3rd party. If you can't trust it, then the entire Kerberos framework is compromised.)

Your analysis of (2) assumes that every ldap principal in your KDC is created by someone you trust not to spoof any other ldap principal in your KDC.

Yes, again, that is implicit in the fact that the KDC is a trusted 3rd party.

That's a high bar to meet and many sites are not going to meet that bar, nor want to given a competing desire for distributed administration.

Delegating administration authority still implies that you trust whoever you delegated it to. Again, if you can't trust everyone then your administrative procedures are broken and your framework has already been compromised.

For example, Stanford allows students to run Kerberized services on their personal computers if they wish, and therefore allows them to download keytabs (and hence create ldap principals) for those computers. If they can use DNS hijacking to return a CNAME for an LDAP server pointing to their computer instead, they can obtain a legitimate keytab for the ldap principal for that computer, and can successfully trick a client that trusts DNS canonicalization.

Trust within a realm is all-or-nothing. And of course, Kerberos trust is transitive... But the right way to handle regions under different administrative control is to place them in separate realms. For your example of students creating their own principals, independently from the centrally administered realm, you should be using a separate realm (and setup a cross-realm trust if that's appropriate.) That at least gives you consistent accountability, and you can uniformly limit the privileges granted to tickets from non-default realms.

Another, possibly more obvious case where (2) doesn't hold is in the presence of cross-realm trust. If I can use DNS spoofing to return a CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So you not only have to trust everyone who can create ldap principals in your local realm, but everyone who can create ldap principals in any realm with which you have cross-realm trust.

Yes, and again, that is basic to the definition of Kerberos. If you don't actually trust everyone, then you should not be adding them into your KDC, because their presence in the KDC is a declaration of trust.

Garbage-in-garbage-out applies here.

There are a lot of nasty things that you can do with DNS spoofing, and this almost certainly isn't the most likely attack, but it is a potential vulnerability that's been widely discussed within the Kerberos community, including transition plans for how to get away from always doing canonicalization. You can, for example, see part of the opinion of the MIT developers in the comments around the relevant segment of code:

         if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) {
             /*
              * Do a reverse resolution to get the full name, just in
              * case there's some funny business going on.  If there
              * isn't an in-addr record, give up.
              */
             /* XXX: This is *so* bogus.  There are several cases where
                this won't get us the canonical name of the host, but
                this is what we've trained people to expect.  We'll
                probably fix it at some point, but let's try to
                preserve the current behavior and only shake things up
                once when it comes time to fix this lossage.  */

This is the reason why there's an rdns option in krb5.conf to disable this code. There has been other discussion of it on krbdev and kerberos@mit.edu in the past.

I would agree that there's no way that you can change the default; too much stuff would break. That's also why the Kerberos libraries continue to do this by default. But I think the original bug reporter isn't unreasonable for wanting a way to disable canonicalization if they know that their code and environment will handle that appropriately.

You've already proven that the option being discussed here is *not appropriate* because a non-local KDC cannot be trusted. So once again, solve the real problem. What's been proposed here is not a solution.