rra@stanford.edu writes:
(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.
I'm sorry -- this is wrong. I overthought this. The scenario discussed here is not the Zanarotti attack. The Zanarotti attack involves spoofing the KDC so that you don't have to know the correct key for a principal; you instead use a key that you know and fool the system into talking to a KDC that uses the same key. It's an attack on login or a screen saver to allow someone to use a bogus password to authenticate.
The protection against the scenario (1) listed here is integral into the Kerberos protocol. The Kerberos authentication process involves requesting a TGT from the KDC that's encrypted in your private key and then decrypting the return with your private key. You cannot spoof Kerberos initial authentication from a keytab or a correct password by using DNS to redirect the authentication to a bogus KDC because the bogus KDC won't know your correct private key and hence won't be able to return a TGT that you can decrypt. Similarly, you can't successfully redirect a TGS_REQ to a bogus KDC because that KDC doesn't have the private key and can't complete the protocol exchange.
This is why kinit doesn't bother to protect against the Zanarotti attack; there's no need, since kinit doesn't provide increased local privileges and the Zanarotti attack is an attack only on the local system, not against a network service.