3.1 The Authentication Service Exchange (Lo Scambio del Servizio di Autenticazione)

3.1. The Authentication Service Exchange (Lo Scambio del Servizio di Autenticazione)

Sommario

Direzione del messaggio	Tipo di messaggio	Sezione
1. Client a Kerberos	KRB_AS_REQ	5.4.1
2. Kerberos a client	KRB_AS_REP o KRB_ERROR	5.4.2, 5.9.1

Lo scambio del servizio di autenticazione (Authentication Service, AS) tra il client e il server di autenticazione Kerberos viene avviato da un client quando desidera ottenere credenziali di autenticazione per un dato server ma attualmente non detiene credenziali. Nella sua forma base, la chiave segreta del client viene utilizzata per cifratura e decifratura. Questo scambio viene tipicamente utilizzato all'inizio di una sessione di login per ottenere credenziali per un server di concessione ticket (Ticket-Granting Server), che saranno successivamente utilizzate per ottenere credenziali per altri server (vedi Sezione 3.3) senza richiedere ulteriore uso della chiave segreta del client. Questo scambio viene anche utilizzato per richiedere credenziali per servizi che non devono essere mediati attraverso il servizio di concessione ticket, ma richiedono piuttosto la conoscenza della chiave segreta di un principal, come il servizio di modifica password (il servizio di modifica password nega le richieste a meno che il richiedente non possa dimostrare la conoscenza della vecchia password dell'utente; richiedere questa conoscenza previene modifiche non autorizzate della password da parte di qualcuno che si avvicina a una sessione incustodita).

Questo scambio non fornisce di per sé alcuna garanzia dell'identità dell'utente. Per autenticare un utente che effettua il login a un sistema locale, le credenziali ottenute nello scambio AS possono prima essere utilizzate in uno scambio TGS per ottenere credenziali per un server locale; tali credenziali devono poi essere verificate da un server locale attraverso il completamento con successo dello scambio client/server.

Lo scambio AS consiste in due messaggi: KRB_AS_REQ dal client a Kerberos, e KRB_AS_REP o KRB_ERROR in risposta. I formati per questi messaggi sono descritti nelle Sezioni 5.4.1, 5.4.2 e 5.9.1.

Nella richiesta, il client invia (in chiaro) la propria identità e l'identità del server per cui sta richiedendo credenziali, altre informazioni sulle credenziali che sta richiedendo, e un nonce generato casualmente, che può essere utilizzato per rilevare replay e per associare le risposte alle richieste corrispondenti. Questo nonce DEVE essere generato casualmente dal client e ricordato per il controllo contro il nonce nella risposta attesa. La risposta, KRB_AS_REP, contiene un ticket per il client da presentare al server, e una chiave di sessione che sarà condivisa dal client e dal server. La chiave di sessione e informazioni aggiuntive sono cifrate nella chiave segreta del client. La parte cifrata del messaggio KRB_AS_REP contiene anche il nonce che DEVE corrispondere al nonce dal messaggio KRB_AS_REQ.

Senza pre-autenticazione, il server di autenticazione non sa se il client è effettivamente il principal nominato nella richiesta. Invia semplicemente una risposta senza sapere o preoccuparsi se sono lo stesso. Questo è accettabile perché nessuno tranne il principal la cui identità è stata data nella richiesta sarà in grado di utilizzare la risposta. Le sue informazioni critiche sono cifrate nella chiave di quel principal. Tuttavia, un attaccante può inviare un messaggio KRB_AS_REQ per ottenere plaintext noto per attaccare la chiave del principal. Specialmente se la chiave è basata su una password, questo può creare un'esposizione di sicurezza. Quindi la richiesta iniziale supporta un campo opzionale che può essere utilizzato per passare informazioni aggiuntive che potrebbero essere necessarie per lo scambio iniziale. Questo campo DOVREBBE essere utilizzato per la pre-autenticazione come descritto nelle sezioni 3.1.1 e 5.2.7.

Possono verificarsi vari errori; questi sono indicati da una risposta di errore (KRB_ERROR) invece della risposta KRB_AS_REP. Il messaggio di errore non è cifrato. Il messaggio KRB_ERROR contiene informazioni che possono essere utilizzate per associarlo al messaggio a cui risponde. I contenuti del messaggio KRB_ERROR non sono protetti nell'integrità. In quanto tale, il client non può rilevare replay, fabbricazioni o modifiche. Una soluzione a questo problema sarà inclusa in una versione futura del protocollo.

3.1.1. Generation of KRB_AS_REQ Message (Generazione del Messaggio KRB_AS_REQ)

Il client può specificare un numero di opzioni nella richiesta iniziale. Tra queste opzioni ci sono se deve essere eseguita la pre-autenticazione; se il ticket richiesto deve essere rinnovabile, proxiable o forwardable; se deve essere postdatato o consentire la postdatazione di ticket derivati; e se un ticket rinnovabile sarà accettato al posto di un ticket non rinnovabile se la data di scadenza del ticket richiesto non può essere soddisfatta da un ticket non rinnovabile (a causa di vincoli di configurazione).

Il client prepara il messaggio KRB_AS_REQ e lo invia al KDC.

3.1.2. Receipt of KRB_AS_REQ Message (Ricezione del Messaggio KRB_AS_REQ)

Se tutto va bene, l'elaborazione del messaggio KRB_AS_REQ risulterà nella creazione di un ticket per il client da presentare al server. Il formato per il ticket è descritto nella Sezione 5.3.

Poiché Kerberos può funzionare su trasporti inaffidabili come UDP, il KDC DEVE essere preparato a ritrasmettere le risposte in caso vengano perse. Se un KDC riceve una richiesta identica a una che ha elaborato con successo recentemente, il KDC DEVE rispondere con un messaggio KRB_AS_REP piuttosto che con un errore di replay. Per ridurre il ciphertext dato a un potenziale attaccante, i KDC POSSONO inviare la stessa risposta generata quando la richiesta è stata gestita per la prima volta. I KDC DEVONO obbedire a questo comportamento di replay anche se il trasporto effettivo in uso è affidabile.

3.1.3. Generation of KRB_AS_REP Message (Generazione del Messaggio KRB_AS_REP)

Il server di autenticazione cerca i principal del client e del server nominati nel KRB_AS_REQ nel suo database, estraendo le rispettive chiavi. Se il principal del client richiesto nominato nella richiesta è sconosciuto perché non esiste nel database dei principal del KDC, viene restituito un messaggio di errore con KDC_ERR_C_PRINCIPAL_UNKNOWN.

Se richiesto di farlo, il server pre-autentica la richiesta, e se il controllo di pre-autenticazione fallisce, viene restituito un messaggio di errore con il codice KDC_ERR_PREAUTH_FAILED. Se la pre-autenticazione è richiesta, ma non era presente nella richiesta, viene restituito un messaggio di errore con il codice KDC_ERR_PREAUTH_REQUIRED, e un oggetto METHOD-DATA sarà memorizzato nel campo e-data del messaggio KRB-ERROR per specificare quali meccanismi di pre-autenticazione sono accettabili.

3.1.4. Generation of KRB_ERROR Message (Generazione del Messaggio KRB_ERROR)

Vengono restituiti messaggi di errore in varie condizioni. Il formato del messaggio KRB_ERROR è descritto nella Sezione 5.9.1.

3.1.5. Receipt of KRB_AS_REP Message (Ricezione del Messaggio KRB_AS_REP)

Quando il client riceve il KRB_AS_REP, decifra la parte cifrata utilizzando la propria chiave segreta. Il client verifica quindi che il nonce nella risposta corrisponda al nonce che ha inviato nella richiesta. Se non corrispondono, il client DEVE scartare la risposta. Il client memorizza quindi il ticket e la chiave di sessione per uso futuro.

3.1.6. Receipt of KRB_ERROR Message (Ricezione del Messaggio KRB_ERROR)

Se il client riceve un messaggio KRB_ERROR invece di un KRB_AS_REP, esamina il codice di errore e agisce di conseguenza. Alcuni errori comuni includono la richiesta di pre-autenticazione, errori di tipo di cifratura, o errori di principal sconosciuto.