Spiega come ho 5 anni: Kerberos-cos’è Kerberos, e perché dovrei preoccuparmi?
Mentre questo argomento probabilmente non può essere spiegato a un bambino di 5 anni ed essere compreso, questo è il mio tentativo di deframmentare la documentazione con alcuni ausili visivi e linguaggio digeribile.,
In sintesi
in sostanza, Kerberos tratta solo di questo:
- un protocollo per l’autenticazione
- utilizza i biglietti per l’autenticazione
- evita di memorizzare le password in locale o l’invio di loro su internet
- implica una fiducia di 3 ° parti
- costruito su crittografia a chiave segreta
Hai un biglietto per la prova di identità crittografato con una chiave segreta per particolari servizi a richiesta – sulla tua macchina locale (creazione di un biglietto è descritto di seguito); purché sia valida, è possibile accedere al servizio richiesto, che è all’interno di un’area di autenticazione Kerberos.,
In genere, questo viene utilizzato all’interno di ambienti aziendali/interni. Forse vuoi accedere al tuo sito di paghe interno per rivedere quel piccolo bonus che il tuo capo ti ha dato. Invece di reinserire le credenziali utente/password, il ticket (memorizzato nella cache del sistema) viene utilizzato per l’autenticazione consentendo il single sign-on.
Il tuo biglietto viene aggiornato quando accedi al tuo computer o quandokinit USER all’interno del tuo terminale.
Per le persone che amano le curiosità, il nome di Kerberos deriva dalla mitologia greca, il cane da guardia a tre teste di Ade., È abbastanza appropriato dal momento che ci vuole una terza parte (un centro di distribuzione chiave) per autenticarsi tra un client e un servizio o una macchina host.
Kerberos Realm
Gli amministratori creano reami – reami Kerberos – che comprenderanno tutto ciò che è disponibile per l’accesso. Certo, potresti non avere accesso a determinati servizi o macchine host definiti all’interno della gestione dei criteri: gli sviluppatori non dovrebbero accedere a nulla di finanziario, cose del genere. Ma un reame definisce ciò che Kerberos gestisce in termini di chi può accedere a cosa.,
La tua macchina, il Client, vive all’interno di questo reame, così come il servizio o l’host che vuoi richiedere e il Centro di distribuzione delle chiavi, KDC (no, non il KGB, anche se penso sempre anche a questo). Nell’esempio seguente, separo il server di autenticazione e il server di concessione dei ticket, ma entrambi si trovano all’interno del KDC.
Per rimanere nella parte posteriore della tua mente
Potresti voler tornare qui dopo aver letto i dettagli grintosi su come funziona l’esempio.,
Quando si richiede l’accesso a un servizio o host, si verificano tre interazioni tra l’utente e:
- il Server di autenticazione
- il Server di concessione dei ticket
- il Servizio o la macchina host a cui si desidera accedere.
Altri punti importanti:
- Con ogni interazione, riceverai due messaggi. Ogni messaggio è uno che si può decifrare, e uno che non si può.
- Il servizio o la macchina a cui si richiede l’accesso non comunica mai direttamente con il KDC.,
- Il KDC memorizza tutte le chiavi segrete per macchine e servizi utente nel suo database.
- Le chiavi segrete sono password più un sale che sono hash-l’algoritmo di hash viene scelto durante l’implementazione della configurazione di Kerberos. Per i servizi o le macchine host, non ci sono password (chi lo inserirebbe). Una chiave viene effettivamente generata da un amministratore durante la configurazione iniziale e memorizzata sul servizio/macchina host.
- Ancora una volta, queste chiavi segrete sono tutte memorizzate nel database KDC; ricordiamo la dipendenza di Kerberos dalla crittografia a chiave simmetrica.,
- Il KDC stesso è crittografato con una chiave master per aggiungere un livello di difficoltà dal furto di chiavi dal database.
- Esistono configurazioni e implementazioni Kerberos che utilizzano la crittografia a chiave pubblica invece della crittografia a chiave simmetrica.
A parte: l’ordine dei messaggi e il loro contenuto discussi qui non riflette l’ordine in cui vengono inviati tramite TCP o UDP.
L’esempio seguente descrive cosa succede quando si richiede qualcosa da un servizio HTTP interno, come informazioni relative al libro paga all’interno della intranet aziendale.,
Tu e il server di autenticazione
Vuoi accedere a un servizio HTTP, ma prima devi presentarti al Server di autenticazione. L’accesso al computer, o kinit USERNAME, avvia tale introduzione tramite una richiesta in chiaro per un Ticket Granting Ticket (TGT)., Il testo e il messaggio contiene:
- il tuo nome/ID
- il nome, l’ID del servizio richiesto (in questo caso, il servizio è il Ticket Granting Server),
- il tuo indirizzo di rete (può essere un elenco di indirizzi IP per più macchine, o può essere null se si desidera utilizzare su qualsiasi macchina), e
- richiesto vita per la validità del TGT,
e viene inviato al Server di Autenticazione.
Il Server di autenticazione controllerà se ci si trova nel database KDC. Questo controllo serve solo per vedere se esisti; non vengono controllate le credenziali.,
Se non ci sono errori (ad esempio l’utente non viene trovato), genererà casualmente una chiave chiamata chiave di sessione da utilizzare tra te e il Ticket Granting Server (TGS).
Il server di autenticazione invierà quindi due messaggi all’utente., Un messaggio è il TGT che contiene:
- il tuo nome/ID,
- il TGS nome/ID,
- timestamp
- il tuo indirizzo di rete (può essere un elenco di indirizzi IP per più macchine, o può essere null se si desidera utilizzare su qualsiasi macchina)
- durata del TGT (potrebbe essere quello inizialmente richiesto, inferiore se voi o il TGS segreto di chiavi stanno per scadere, o un altro limite che è stata realizzata durante la configurazione di Kerberos), e
- TGS Chiave di Sessione,
ed è codificato con il TGS Chiave Segreta ., L’altro messaggio contiene:
- il nome/ID TGS,
- timestamp,
- lifetime (come sopra) e
- TGS Session Key
ed è crittografato con la chiave segreta del client. Si noti che la chiave di sessione TGS è la chiave condivisa tra l’utente e il TGS.
La chiave segreta del client viene determinata richiedendo la password, aggiungendo un sale (composto da ) e hashing del tutto. Ora puoi usarlo per decifrare il secondo messaggio per ottenere la chiave di sessione TGS., Se la password non è corretta, non sarà possibile decifrare il messaggio. Si prega di notare che questo è il passaggio in cui la password immessa viene implicitamente convalidata.
Non è possibile, tuttavia, decifrare il TGT poiché non si conosce la chiave segreta TGS. Il TGT crittografato viene memorizzato nella cache delle credenziali.
Tu e il server di concessione dei biglietti
A questo punto, hai il TGT che non puoi leggere perché non hai la chiave segreta TGS per decifrarlo. Tuttavia, hai la chiave di sessione TGS.,
Ora è il tuo turno di inviare due messaggi. Per prima cosa prepara l’autenticatore, crittografato con la chiave di sessione TGS, contenente:
- il tuo nome/ID e
- timestamp.
Si invia un messaggio non crittografato che contiene:
- il nome/ID del servizio HTTP richiesto a cui si desidera accedere e
- durata del Ticket per il Servizio HTTP,
insieme all’autenticatore crittografato e al TGT al server di concessione del ticket.
Il Server di concessione dei ticket prima controllerà il database KDC per vedere se il Servizio HTTP esiste.,
In tal caso, il TGS decrittografa il TGT con la sua chiave segreta . Poiché il TGT ora non crittografato contiene la chiave di sessione TGS, il TGS può decrittografare l’autenticatore inviato.,grazie:
- confronta il tuo ID cliente dall’Autenticatore a quella del TGT
- confrontare il timestamp dall’Autenticatore a quella del TGT (tipico Kerberos-sistema di tolleranza della differenza è di 2 minuti, ma può essere configurato in caso contrario)
- controllare per vedere se il TGT è scaduto (il ciclo di vita dell’elemento),
- verificare che l’Authenticator non è già al TGS cache (per evitare attacchi di tipo replay), e
- se l’indirizzo di rete nella richiesta originale non è null, mette a confronto la fonte indirizzo IP per l’indirizzo di rete (o nell’elenco richiesto) entro il TGT.,
Il Ticket Granting Server quindi genera in modo casuale il Servizio HTTP Chiave di Sessione, e si prepara HTTP Servizio di biglietteria per te, che contiene:
- il tuo nome/ID,
- HTTP nome del Servizio/ID,
- il tuo indirizzo di rete (può essere un elenco di indirizzi IP per più macchine, o può essere null se si desidera utilizzare su qualsiasi macchina),
- timestamp
- durata della validità del biglietto, e
- Servizio HTTP Chiave di Sessione,
e la cifra con il Servizio HTTP Chiave Segreta.
Quindi il TGS ti invia due messaggi., Uno è il ticket del servizio HTTP crittografato; l’altro contiene:
- Nome/ID del servizio HTTP,
- timestamp,
- durata della validità del ticket e
- HTTP Service Session Key,
crittografato con la chiave di sessione TGS.
La macchina decrittografa quest’ultimo messaggio con la chiave di sessione TGS che ha memorizzato nella cache in precedenza per ottenere la chiave di sessione del servizio HTTP.
La tua macchina non può, tuttavia, decifrare il ticket del servizio HTTP poiché è crittografato con la chiave segreta del servizio HTTP.,
Tu e il Servizio HTTP
Per accedere al Servizio HTTP, la macchina prepara un altro Autenticatore messaggio che contiene:
- il tuo nome/ID,
- timestamp
ed è codificato con il Servizio HTTP Chiave di Sessione. Il computer invia quindi l’autenticatore e il ticket di servizio HTTP ancora crittografato ricevuto dal TGS.
Il Servizio HTTP decrittografa quindi il Ticket con la sua Chiave segreta per ottenere la chiave della sessione del servizio HTTP., Utilizza quindi la chiave di sessione per decrittografare il messaggio di autenticazione inviato.,es il tuo ID cliente dall’Autenticatore a quello del Biglietto,
Il Servizio HTTP invia quindi un messaggio di autenticazione contenente il suo ID e timestamp per confermare la sua identità e viene crittografato con la chiave della sessione del servizio HTTP.
La macchina legge il messaggio dell’autenticatore decrittografando con la chiave della sessione del servizio HTTP memorizzata nella cache e sa che deve ricevere un messaggio con l’ID e il timestamp del servizio HTTP.
E ora sei stato autenticato per utilizzare il Servizio HTTP., Le richieste future utilizzano il ticket del servizio HTTP memorizzato nella cache, purché non sia scaduto come definito nell’attributo lifetime.
Mentre scriverò su questo in seguito, il servizio HTTP stesso deve essere in grado di supportare Kerberos. Come pure, è necessario disporre anche di un browser che supporta SPNEGO/Negoziare.,
Forse rileggere i punti precedentemente delineati; controllare questa o questa implementazione corrente, in particolare quella su cui sono pagato per lavorare che comunica con questa implementazione popolare; o rivedere un tutorial, guida alle risorse, il video go-to che mi è stato inviato quando ho iniziato a conoscere Kerberos, o la RFC stessa.
Le immagini di cui sopra sono stati resi con Keynote con le icone utilizzate da font awesome e glyphicons, e sono disponibili su slideshare.