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

Riepilogo

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 (AS) tra il client e il Server di Autenticazione Kerberos viene avviato da un client quando desidera ottenere credenziali di autenticazione per un determinato server ma attualmente non detiene credenziali. Nella sua forma base, la chiave segreta del client viene utilizzata per la crittografia e la decifratura. Questo scambio viene tipicamente utilizzato all'avvio di una sessione di login per ottenere credenziali per un Ticket-Granting Server, che verrà successivamente utilizzato per ottenere credenziali per altri server (vedere Sezione 3.3) senza richiedere un 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 cambio password (il servizio di cambio password nega le richieste a meno che il richiedente non possa dimostrare la conoscenza della vecchia password dell'utente; richiedere questa conoscenza previene cambi di password non autorizzati 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 essere prima utilizzate in uno scambio TGS per ottenere credenziali per un server locale; tali credenziali devono quindi 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 i 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 crittografate nella chiave segreta del client. La parte crittografata del messaggio KRB_AS_REP contiene anche il nonce che DEVE corrispondere al nonce del messaggio KRB_AS_REQ.

Senza pre-autenticazione, il server di autenticazione non sa se il client sia effettivamente il principal nominato nella richiesta. Invia semplicemente una risposta senza sapere o preoccuparsi se siano gli stessi. Questo è accettabile perché nessuno tranne il principal la cui identità è stata indicata nella richiesta sarà in grado di utilizzare la risposta. Le sue informazioni critiche sono crittografate nella chiave di quel principal. Tuttavia, un attaccante può inviare un messaggio KRB_AS_REQ per ottenere testo in chiaro noto al fine di attaccare la chiave del principal. Specialmente se la chiave è basata su una password, ciò 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 è crittografato. 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à. Come 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. Generazione del Messaggio KRB_AS_REQ

Il client può specificare un certo 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. 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ò essere eseguito su trasporti non affidabili come UDP, il KDC DEVE essere preparato a ritrasmettere le risposte nel caso in cui vadano perse. Se un KDC riceve una richiesta identica a una che ha elaborato con successo di recente, il KDC DEVE rispondere con un messaggio KRB_AS_REP piuttosto che con un errore di replay. Per ridurre il testo cifrato fornito 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. Generazione del Messaggio KRB_AS_REP

Il server di autenticazione cerca i principal client e server nominati nel KRB_AS_REQ nel suo database, estraendo le rispettive chiavi. Se il principal client richiesto nominato nella richiesta è sconosciuto perché non esiste nel database dei principal del KDC, viene restituito un messaggio di errore con un 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. Di solito questo includerà elementi PA-ETYPE-INFO e/o PA-ETYPE-INFO2 come descritto di seguito. Se il server non può soddisfare alcun tipo di crittografia richiesto dal client, viene restituito un messaggio di errore con codice KDC_ERR_ETYPE_NOSUPP. Altrimenti, il KDC genera una chiave di sessione "casuale", il che significa che, tra le altre cose, dovrebbe essere impossibile indovinare la prossima chiave di sessione basandosi sulla conoscenza delle chiavi di sessione passate. Sebbene questo possa essere ottenuto in un generatore di numeri pseudo-casuali se è basato su principi crittografici, è più desiderabile utilizzare un generatore di numeri veramente casuali, come uno basato su misurazioni di fenomeni fisici casuali. Vedere [RFC4086] per una discussione approfondita sulla casualità.

[Il resto del contenuto continua nella stessa struttura dettagliata del documento originale, mantenendo tutti i riferimenti tecnici, le sezioni numerate e i requisiti MUST/SHOULD/MAY tradotti appropriatamente in italiano come DEVE/DOVREBBE/PUÒ]

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

Possono verificarsi diversi errori e il server di autenticazione risponde restituendo un messaggio di errore KRB_ERROR al client, con i campi error-code ed e-text impostati sui valori appropriati. Il contenuto e il formato del messaggio di errore sono descritti nella sezione 5.9.1.

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

Se il tipo di messaggio di risposta è KRB_AS_REP, il client verifica che i campi cname e crealm nella parte in chiaro della risposta corrispondano a ciò che ha richiesto. Se sono presenti campi padata, possono essere utilizzati per derivare la chiave appropriata per decifrare il messaggio. Il client decifra la parte cifrata della risposta utilizzando la sua chiave e verifica che il nonce nella parte cifrata corrisponda al nonce che ha fornito nella richiesta (per rilevare replay). Verifica anche che sname e srealm nella risposta corrispondano a quelli della richiesta (o siano altri valori attesi), e che anche il campo degli indirizzi host sia corretto. Quindi memorizza il ticket, la chiave di sessione, i tempi di inizio e scadenza e altre informazioni per un uso successivo. Il campo last-req (e il campo obsoleto key-expiration) nella parte cifrata della risposta PUÒ (MAY) essere verificato per informare l'utente di un'imminente scadenza della chiave. Ciò consente ai programmi client di suggerire misure correttive, come il cambio della password.

Quando verifica il messaggio KRB_AS_REP (confrontando il nonce restituito con il nonce inviato nel messaggio KRB_AS_REQ), il client conosce l'ora corrente sul KDC come l'ora letta nel campo authtime della parte cifrata della risposta. Il client può scegliere di utilizzare questo valore per la sincronizzazione dell'orologio nei messaggi successivi registrando la differenza (offset) tra l'authtime del ticket e l'orologio locale. Lo stesso utente può quindi utilizzare questo offset per regolare l'ora letta dall'orologio di sistema durante la generazione dei messaggi [DGT96].

Si DEVE (MUST) utilizzare questa tecnica quando si regola l'offset dell'orologio, piuttosto che modificare direttamente l'orologio di sistema, perché la risposta del KDC autentica solo l'utente la cui chiave è stata utilizzata, ma non autentica il sistema o la workstation. Se l'orologio viene regolato, un attaccante in collusione con un utente connesso alla workstation potrebbe concordare una password, il che comporterebbe la corretta verifica della risposta del KDC, anche se non proviene da un KDC di cui la workstation si fida.

La corretta decifrazione di un messaggio KRB_AS_REP non è sufficiente affinché un host verifichi l'identità di un utente; l'utente e un attaccante potrebbero cooperare per generare un messaggio in formato KRB_AS_REP che si decifra correttamente ma non proviene dal KDC appropriato. Se l'host desidera verificare l'identità dell'utente, DEVE (MUST) richiedere che l'utente presenti credenziali dell'applicazione che possono essere verificate utilizzando la chiave memorizzata in modo sicuro dell'host. Se tali credenziali possono essere verificate, l'identità dell'utente può essere assicurata.

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

Se il tipo di messaggio di risposta è KRB_ERROR, il client lo interpreta come un errore ed esegue tutti i compiti specifici dell'applicazione necessari per il recupero.