3.2. The Client/Server Authentication Exchange (Lo Scambio di Autenticazione Client/Server)

Riepilogo

Direzione del messaggio	Tipo di messaggio	Sezione
1. Client a server applicativo	KRB_AP_REQ	5.5.1
2. [opzionale] Server applicativo a client	KRB_AP_REP o KRB_ERROR	5.5.2 / 5.9.1

Lo scambio di autenticazione client/server (CS) viene utilizzato dalle applicazioni di rete per autenticare il client al server e viceversa. Il client DEVE aver già acquisito credenziali per il server utilizzando lo scambio AS o TGS.

3.2.1. Il Messaggio KRB_AP_REQ

Il KRB_AP_REQ contiene informazioni di autenticazione che DOVREBBERO far parte del primo messaggio in una transazione autenticata. Contiene un ticket, un authenticator e alcune informazioni contabili aggiuntive (vedere Sezione 5.5.1 per il formato esatto). Il ticket da solo è insufficiente per autenticare un client, poiché i ticket vengono passati attraverso la rete in chiaro (i ticket contengono sia una porzione crittografata che non crittografata, quindi chiaro qui si riferisce all'unità intera, che può essere copiata da un messaggio e riprodotta in un altro senza alcuna abilità crittografica). L'authenticator viene utilizzato per prevenire il replay non valido dei ticket dimostrando al server che il client conosce la chiave di sessione del ticket e quindi ha il diritto di utilizzare il ticket. Il messaggio KRB_AP_REQ viene definito altrove come "authentication header".

3.2.2. Generazione di un Messaggio KRB_AP_REQ

Quando un client desidera avviare l'autenticazione a un server, ottiene (tramite una cache delle credenziali, lo scambio AS o lo scambio TGS) un ticket e una chiave di sessione per il servizio desiderato. Il client PUÒ riutilizzare qualsiasi ticket che detiene fino alla scadenza. Per utilizzare un ticket, il client costruisce un nuovo Authenticator dal tempo di sistema e dal suo nome, e opzionalmente da un checksum specifico dell'applicazione, un numero di sequenza iniziale da utilizzare nei messaggi KRB_SAFE o KRB_PRIV, e/o una subkey di sessione da utilizzare nelle negoziazioni per una chiave di sessione unica per questa particolare sessione. Gli Authenticator NON DEVONO essere riutilizzati e DOVREBBERO essere rifiutati se riprodotti a un server. Si noti che questo può rendere difficile codificare correttamente le applicazioni basate su trasporti inaffidabili. Se il trasporto potrebbe consegnare messaggi duplicati, o un nuovo authenticator DEVE essere generato per ogni nuovo tentativo, o il server applicativo DEVE abbinare richieste e risposte e riprodurre la prima risposta in risposta a un duplicato rilevato.

Se deve essere incluso un numero di sequenza, DOVREBBE essere scelto casualmente in modo che anche dopo che molti messaggi sono stati scambiati non sia probabile che entri in collisione con altri numeri di sequenza in uso.

Il client PUÒ indicare un requisito di autenticazione reciproca o l'uso di un ticket basato su chiave di sessione (per l'autenticazione user-to-user, vedere sezione 3.7) impostando i flag appropriati nel campo ap-options del messaggio.

L'Authenticator viene crittografato nella chiave di sessione e combinato con il ticket per formare il messaggio KRB_AP_REQ, che viene quindi inviato al server finale insieme a qualsiasi informazione aggiuntiva specifica dell'applicazione.

3.2.3. Ricezione del Messaggio KRB_AP_REQ

L'autenticazione si basa sul tempo corrente del server (gli orologi DEVONO essere sincronizzati in modo lasco), l'authenticator e il ticket. Sono possibili diversi errori. Se si verifica un errore, il server dovrebbe rispondere al client con un messaggio KRB_ERROR. Questo messaggio PUÒ essere incapsulato nel protocollo applicativo se la sua forma grezza non è accettabile per il protocollo. Il formato dei messaggi di errore è descritto nella Sezione 5.9.1.

L'algoritmo per verificare le informazioni di autenticazione è il seguente. Se il tipo di messaggio non è KRB_AP_REQ, il server restituisce l'errore KRB_AP_ERR_MSG_TYPE. Se la versione della chiave indicata dal Ticket nel KRB_AP_REQ non è una che il server può utilizzare (ad esempio, indica una chiave vecchia, e il server non possiede più una copia della chiave vecchia), viene restituito l'errore KRB_AP_ERR_BADKEYVER. Se il flag USE-SESSION-KEY è impostato nel campo ap-options, indica al server che è in uso l'autenticazione user-to-user, e che il ticket è crittografato nella chiave di sessione dal TGT del server piuttosto che nella chiave segreta del server. Vedere Sezione 3.7 per una descrizione più completa dell'effetto dell'autenticazione user-to-user su tutti i messaggi nel protocollo Kerberos.

Poiché è possibile che il server sia registrato in più realm, con chiavi diverse in ciascuno, il campo srealm nella porzione non crittografata del ticket nel KRB_AP_REQ viene utilizzato per specificare quale chiave segreta il server dovrebbe utilizzare per decifrare quel ticket. Il codice di errore KRB_AP_ERR_NOKEY viene restituito se il server non ha la chiave appropriata per decifrare il ticket.

Il ticket viene decifrato utilizzando la versione della chiave del server specificata dal ticket. Se le routine di decifratura rilevano una modifica del ticket (ogni sistema di crittografia DEVE fornire protezioni per rilevare il testo cifrato modificato), viene restituito l'errore KRB_AP_ERR_BAD_INTEGRITY (è molto probabile che siano state utilizzate chiavi diverse per crittografare e decifrare).

L'authenticator viene decifrato utilizzando la chiave di sessione estratta dal ticket decifrato. Se la decifratura mostra che è stato modificato, viene restituito l'errore KRB_AP_ERR_BAD_INTEGRITY. Il nome e il realm del client dal ticket vengono confrontati con gli stessi campi nell'authenticator. Se non corrispondono, viene restituito l'errore KRB_AP_ERR_BADMATCH; normalmente questo è causato da un errore del client o da un tentativo di attacco. Gli indirizzi nel ticket (se presenti) vengono quindi cercati per un indirizzo che corrisponda all'indirizzo del client riportato dal sistema operativo. Se non viene trovata alcuna corrispondenza o il server insiste sugli indirizzi del ticket ma nessuno è presente nel ticket, viene restituito l'errore KRB_AP_ERR_BADADDR. Se il tempo locale (server) e il tempo del client nell'authenticator differiscono di più dello skew di orologio consentito (ad esempio, 5 minuti), viene restituito l'errore KRB_AP_ERR_SKEW.

A meno che il server applicativo non fornisca i propri mezzi adeguati per proteggersi dal replay (ad esempio, una sequenza challenge-response avviata dal server dopo l'autenticazione, o l'uso di una subkey di crittografia generata dal server), il server DEVE utilizzare una cache di replay per ricordare qualsiasi authenticator presentato entro lo skew di orologio consentito. Si raccomanda un'analisi attenta del protocollo applicativo e dell'implementazione prima di eliminare questa cache. La cache di replay memorizzerà almeno il nome del server, insieme al nome del client, tempo e campi microsecond dagli authenticator visti recentemente, e se viene trovata una tupla corrispondente, viene restituito l'errore KRB_AP_ERR_REPEAT. Si noti che il rifiuto qui è limitato agli authenticator dallo stesso principal allo stesso server. Altri principal client che comunicano con lo stesso principal server non dovrebbero avere i loro authenticator rifiutati se i campi tempo e microsecond capita che corrispondano all'authenticator di qualche altro client.

[Continua con le restanti sezioni 3.2.4, 3.2.5, 3.2.6...]