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Ò]