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

[rra@stanford.edu]

Howard Chu <hyc@symas.com> writes:

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

All Kerberos clients have trusted local data.  It's required by the
Kerberos protocol; the server gives you a TGT that you can only decrypt
using your trusted local data.  So I'm not sure what you're getting at
here.  The problem with DNS canonicalization is that it allows you to
attack clients even if those clients have trusted local data to establish
mutual authentication with the KDC.

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

Yes, it implies that you trust them to take the actions that you delegated
to them.  However, it *doesn't* imply that you trust them universally.
You can delegate control of some principals and not others.  That's a
meaningful operation that is entirely valid within the Kerberos protocol
trust model.  Control of one principal in a realm should not imply an
ability to spoof authentications to other principals in the same realm.

Kerberos as a protocol can and is designed to be robust against attackers
who have control over principals within your local realm provided that a
client and a server agree on principal naming for a service.  Kerberos
clients are specifically cautioned in the Kerberos protocol specification
against using insecure DNS to establish that agreement naming.

Section 1.3 of RFC 4120, particularly the two paragraphs starting with:

   Implementations of Kerberos and protocols based on Kerberos MUST NOT
   use insecure DNS queries to canonicalize the hostname components of
   the service principal names (i.e., they MUST NOT use insecure DNS
   queries to map one name to another to determine the host part of the
   principal name with which one is to communicate).

and the security considerations section of RFC 4752, namely:

   When constructing the input_name_string, the client SHOULD NOT
   canonicalize the server's fully qualified domain name using an
   insecure or untrusted directory service.

are relevant here.

The delegated administrative model that I describe is in widespread use;
in fact, I don't know of any of my colleagues who *don't* do something
similar to that.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>