1.3. Choosing a Principal with Which to Communicate (Scelta di un Principal con cui Comunicare)
1.3. Choosing a Principal with Which to Communicate (Scelta di un Principal con cui Comunicare)
Il protocollo Kerberos fornisce i mezzi per verificare (soggetto alle assunzioni nella sezione 1.6) che l'entità con cui si comunica è la stessa entità che è stata registrata con il KDC utilizzando l'identità dichiarata (nome del principal). È ancora necessario determinare se tale identità corrisponde all'entità con cui si intende comunicare.
Quando sono stati scambiati in anticipo dati appropriati, l'applicazione può eseguire questa determinazione sintatticamente in base alla specifica del protocollo applicativo, alle informazioni fornite dall'utente e ai file di configurazione. Ad esempio, il nome del principal del server (incluso il realm) per un server telnet potrebbe essere derivato dal nome host specificato dall'utente (dalla riga di comando telnet), dal prefisso "host/" specificato nella specifica del protocollo applicativo e da una mappatura a un realm Kerberos derivata sintatticamente dalla parte di dominio del nome host specificato e dalle informazioni del database dei realm Kerberos locali.
Si può anche fare affidamento su terze parti fidate per effettuare questa determinazione, ma solo quando i dati ottenuti dalla terza parte sono adeguatamente protetti per l'integrità mentre risiedono sul server della terza parte e quando vengono trasmessi. Quindi, ad esempio, non si dovrebbe fare affidamento su un record DNS non protetto per mappare un alias host al nome primario di un server, accettando il nome primario come la parte che si intende contattare, poiché un attaccante può modificare la mappatura e impersonare la parte.
Le implementazioni di Kerberos e i protocolli basati su Kerberos NON DEVONO utilizzare query DNS non sicure per canonizzare i componenti hostname dei nomi dei principal di servizio (cioè, NON DEVONO utilizzare query DNS non sicure per mappare un nome a un altro per determinare la parte host del nome del principal con cui si deve comunicare). In un ambiente senza servizio di nomi sicuro, gli autori di applicazioni POSSONO aggiungere un nome di dominio configurato staticamente agli hostname non qualificati prima di passare il nome ai meccanismi di sicurezza, ma non dovrebbero fare altro. Le strutture di servizio di nomi sicure, se disponibili, potrebbero essere fidate per la canonizzazione del nome host, ma tale canonizzazione da parte del client NON DOVREBBE essere richiesta dalle implementazioni KDC.
Nota di implementazione: Molte implementazioni attuali eseguono un certo grado di canonizzazione del nome di servizio fornito, spesso utilizzando DNS anche se ciò crea problemi di sicurezza. Tuttavia, non c'è coerenza tra le implementazioni su se il nome del servizio venga convertito in minuscolo o se venga utilizzata la risoluzione inversa. Per massimizzare l'interoperabilità e la sicurezza, le applicazioni DOVREBBERO fornire ai meccanismi di sicurezza nomi che risultano dalla conversione in minuscolo del nome inserito dall'utente senza eseguire altre modifiche o canonizzazioni.