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.