Re: (ITS#5812) New option to disable SASL host canonicalization

[hyc@symas.com]

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/