Uso continuato di Kerberos

Kerberos ha implementazioni mature e interoperabili su piattaforme principali con comunità di utenti attive e in continuo sviluppo (MIT Kerberos, Heimdal, Microsoft, Java) e attraverso livelli di astrazione standard come GSSAPI e SASL, è facile usare anche Kerberos direttamente o indirettamente per proteggere molte applicazioni e protocolli standard, tra cui:

• SSH (OpenSSH, ssh.com, VanDyke VShell / SecureCRT)
• IMAP e SMTP (Cyrus, sendmail, postfix, Thunderbird, OS X Mail, Alpine)
• Subversion
• CIFS / SMB (Samba, Windows, Netapp)
• Database (SQL Server, Postgres, jTDS, FreeTDS)
• HTTP (Apache, nginx, tutti i principali browser Web, arricciatura, librerie HTTP client in Perl / Python / Java / C /...)
• DNS (autenticazione per l'aggiornamento dinamico, implementato da Windows e BIND)
• NFS

Tutti questi protocolli e implementazioni hanno il supporto Kerberos integrato pronto per essere utilizzato, se solo tu fornisci l'infrastruttura e sai come farlo. Questo non è solo teorico; dove lavoro, sono responsabile dell'infrastruttura Kerberos per la mia azienda, e abbiamo tutte queste applicazioni e altro ancora. Interagiscono tutti perfettamente sia su Windows che su Unix; i nostri utenti accedono al loro desktop Windows o Unix, digitano la loro password una volta, e poi non lo digitano più mentre accedono a tutti questi servizi, sia direttamente che dopo aver utilizzato SSH per accedere ad altri host (dove le loro credenziali Kerberos vengono automaticamente inoltrate e utilizzate). La delega delle credenziali in diversi formati è disponibile per consentire ai server autorizzati di accedere a ulteriori servizi per conto di un utente tramite l'uso controllato dell'identità dell'utente. Non abbiamo l'incubo di gestire i tasti host SSH su varie piattaforme e client (file OpenSSH conosciuti, chiavi di registro PuTTY, ecc.); Kerberos autentica i nostri server SSH e i loro client.

Se hai esigenze strettamente definite, puoi cavartela con altri sistemi. Se tutto ciò che si desidera è l'accesso singolo alle applicazioni Web da browser Web completi, ad esempio, è possibile utilizzare uno qualsiasi dei diversi schemi, ma se si desidera accedere a tale app Web in modo programmatico da un semplice programma che non dispone di un Motore di Javascript e un utente per digitare una password, sei praticamente bloccato. Con Kerberos, le stesse credenziali funzionano allo stesso modo in entrambi gli scenari.

Nulla di ciò significa che Kerberos non ha i suoi punti deboli, o cose che dovrebbero essere migliorate. L'uso di Kerberos in HTTP ("HTTP Negotiate") è un hack con problemi; in realtà, ciò di cui abbiamo bisogno è un'implementazione pervasiva delle cifrazie di Kerberos in TLS. L'utilizzo di Kerberos per proteggere il traffico di dati non consente la segretezza, che è sempre più importante in questi giorni; abbiamo bisogno di un meccanismo GSSAPI che combini l'autenticazione Kerberos con uno scambio Diffie-Hellman, come fanno gli scambi di chiavi GSSAPI SSH; una volta che esiste, può funzionare in modo trasparente con qualsiasi client SASL correttamente scritto che utilizza un livello di sicurezza (come molti dei casi citati sopra). Questo evita la combinazione di Kerberos e TLS in livelli separati, che ha troppi round trip e richiede PKI quando Kerberos di per sé è sufficiente.

Inoltre, gran parte di questa utilità è dovuta all'ampia adozione di GSSAPI e SASL nei protocolli attraverso cui viene utilizzato Kerberos, piuttosto che le proprietà specifiche di Kerberos stesso; altri meccanismi resi utilizzabili come meccanismi GSSAPI potrebbero godere di un'usabilità simile, e ad OAuth è attualmente in corso il lavoro per farlo, ad esempio. Kerberos ha il vantaggio di consentire una semplice autenticazione basata su password, consentendo anche metodi più potenti (i certificati a chiave pubblica tramite PKINIT e gli schemi OTP sono entrambi supportati), mentre la PKI è legata alla necessità di un secondo fattore di qualche tipo da tenere la chiave privata dell'utente e i certificati CA affidabili, che ne ha limitato l'adozione per l'autenticazione dell'utente per un certo periodo di tempo.

In ogni caso: se si desidera il single-signon oggi , con i sistemi esistenti pronti all'uso, su una vasta gamma di applicazioni e protocolli in particolare in un ambiente open-system, Kerberos è praticamente l'unico gioco in città: nient'altro corrisponde alla sua pervasiva disponibilità, usabilità e supporto in prodotti e protocolli esistenti, sia commerciali che open source.

Per sostituire i vecchi protocolli con quelli più recenti, non è sufficiente che il vecchio protocollo sia inefficiente, goffo, complesso e abbia più buchi di Emmental cheese . Che il nuovo protocollo sia lucido, veloce, semplice, alla moda e sicuro non garantisce l'aggiornamento.

Per liberarti davvero di un vecchio protocollo, devi uccidere tutti gli umani che si sono abituati ad esso. Immagina un giovane studente; lo chiameremo Herbert. Negli anni '80 Herbert ha imparato a conoscere Kerberos e, nella follia della sua gioventù, ha immaginato che fosse il picco di ingegno e perfezione nella sicurezza. Avanti veloce di 30 anni: è ora il 2014. Herbert si è sposato, divorziato, ingrassato di 40 libbre, ha raggiunto l'età di 50 anni e ha intrapreso una carriera di successo come professionista IT. Ora è un "architetto senior" e decide in merito agli orientamenti tecnologici in una grande organizzazione (forse un'istituzione governativa di più di 10000). È arrivato lì attraverso la magia delle promozioni basate sul tempo, e rimane nel nesso dei circoli decisionali perché è il migliore amico di un manager di alto livello.

Sfortunatamente, nonostante tutte le sue abilità nel superare i concorrenti e uccidere reputazioni con alcune voci finemente sintonizzate, Herbert non ha mai ritenuto opportuno aggiornare le sue capacità tecnologiche e, ad esempio, prendersi del tempo per capire veramente cosa potrebbe fare questa cosa "Internet" essere. Pertanto, Herbert risponde ancora a tutte le domande: "Kerberos, abbiamo bisogno di Kerberos". E, nella terra del capitalismo trionfante, se Herbert vuole Kerberos, troverà alcune persone a vendergli dei Kerberos (in questo caso, Microsoft, che usa Kerberos preferenzialmente per tutte le cose di Active Directory).

Herbert sarà ancora attivo per altri 10 o 15 anni. Peggio ancora, è contagioso: giovani ambiziosi di circa 35 anni navigano nella sua ombra e imitano le sue posizioni nella speranza di raggiungere livelli più alti nella gerarchia locale; e anche questi pappagallo la posizione di Kerberos, perché ha funzionato per Herbert, e loro non capiscono veramente di cosa si tratta. Tra 30 anni queste persone continueranno ad essere tossiche.

Su una nota simile, medita questo estratto di una pagina di Wikipedia :

In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software. 36% of managers said they planned to migrate from COBOL and 25% said they would like to if it was cheaper. Instead, some businesses have migrated their systems from expensive mainframes to cheaper, more modern systems, while maintaining their COBOL programs.

Se il cadavere di COBOL non è ancora solo una contrazione, ma attivamente cammina e sta iniziando la sua attività, allora non puoi aspettarti che Kerberos sparisca presto.