Alcuni livelli limitati di autenticazione reciproca si verificano intrinsecamente come parte del processo di autenticazione Kerberos tra client e servizio app. Un servizio non dovrebbe essere in grado di decodificare il ticket di servizio a meno che non abbia la chiave associata al principal Kerberos che dovrebbe essere. Se non è in grado di decrittografare il ticket di servizio, non dovrebbe avere accesso alle informazioni sull'entità utente di cui ha bisogno per autenticare correttamente e creare una sessione per quell'utente.
Ora, immagino che un host malintenzionato in grado di impersonare un servizio legittimo possa fingere di essere in grado di decrittografare il ticket di servizio e di creare una sessione generica per qualsiasi utente che lo contatti. In alcuni casi, come l'accesso a un sito Web interno a cui tutti i dipendenti dispongono di autorizzazioni, potrebbe non essere ovvio all'utente che non sono autenticati nel loro contesto appropriato. In altri casi, ad esempio l'accesso a una condivisione di file personali, dovrebbe essere subito evidente che il servizio non ha i dati che l'utente si aspetta ed è falso.
Il processo di autenticazione reciproca di Kerberos dimostra al cliente che sta parlando del principio di servizio appropriato, piuttosto che presumere che sia stata stabilita una sessione con un servizio valido.
Il motivo per cui l'autenticazione reciproca non è attivata per impostazione predefinita è probabilmente dovuto in parte alla difficoltà di un utente malintenzionato di convincere un cliente a pensare che un servizio malevolo sia un servizio valido (ad esempio tramite spoofing DNS), e quindi a trarre beneficio da questo inganno. Inoltre, è un piccolo vantaggio in termini di prestazioni eliminare la fase di autenticazione reciproca dal processo di autenticazione.