3.3. The Ticket-Granting Service (TGS) Exchange (Lo Scambio del Servizio di Concessione Ticket - TGS)

Riepilogo

Direzione del messaggio	Tipo di messaggio	Sezione
1. Client a Kerberos	KRB_TGS_REQ	5.4.1
2. Kerberos a client	KRB_TGS_REP o KRB_ERROR	5.4.2 / 5.9.1

Lo scambio TGS tra un client e il Kerberos TGS viene avviato da un client quando cerca di ottenere credenziali di autenticazione per un determinato server (che potrebbe essere registrato in un realm remoto), quando cerca di rinnovare o validare un ticket esistente, o quando cerca di ottenere un ticket proxy. Nel primo caso, il client deve aver già acquisito un ticket per il Servizio di Concessione Ticket utilizzando lo scambio AS (il TGT viene solitamente ottenuto quando un client si autentica inizialmente al sistema, come quando un utente effettua il login). Il formato del messaggio per lo scambio TGS è quasi identico a quello per lo scambio AS. La differenza principale è che la crittografia e la decifratura nello scambio TGS non avvengono sotto la chiave del client. Invece, viene utilizzata la chiave di sessione dal TGT o ticket rinnovabile, o la chiave di sotto-sessione da un Authenticator. Come nel caso di tutti i server applicativi, i ticket scaduti non sono accettati dal TGS, quindi una volta che un TGT rinnovabile o TGT scade, il client deve utilizzare uno scambio separato per ottenere ticket validi.

Lo scambio TGS consiste in due messaggi: una richiesta (KRB_TGS_REQ) dal client al Server di Concessione Ticket Kerberos, e una risposta (KRB_TGS_REP o KRB_ERROR). Il messaggio KRB_TGS_REQ include informazioni che autenticano il client più una richiesta di credenziali. Le informazioni di autenticazione consistono nell'authentication header (KRB_AP_REQ), che include il ticket-granting, rinnovabile o non valido precedentemente ottenuto dal client. Nei casi TGT e proxy, la richiesta PUÒ includere uno o più dei seguenti: un elenco di indirizzi di rete, una raccolta di dati di autorizzazione tipizzati da sigillare nel ticket per l'uso di autorizzazione da parte del server applicativo, o ticket aggiuntivi (il cui uso è descritto più avanti). La risposta TGS (KRB_TGS_REP) contiene le credenziali richieste, crittografate nella chiave di sessione dal TGT o ticket rinnovabile, o, se presente, nella chiave di sotto-sessione dall'Authenticator (parte dell'authentication header). Il messaggio KRB_ERROR contiene un codice di errore e testo che spiega cosa è andato storto. Il messaggio KRB_ERROR non è crittografato. Il messaggio KRB_TGS_REP contiene informazioni che possono essere utilizzate per rilevare i replay, e per associarlo al messaggio a cui risponde. Anche il messaggio KRB_ERROR contiene informazioni che possono essere utilizzate per associarlo al messaggio a cui risponde. Gli stessi commenti sulla protezione dell'integrità dei messaggi KRB_ERROR menzionati nella Sezione 3.1 si applicano allo scambio TGS.

3.3.1. Generazione del Messaggio KRB_TGS_REQ

Prima di inviare una richiesta al servizio di concessione ticket, il client DEVE determinare in quale realm si ritiene sia registrato il server applicativo. Questo può essere realizzato in diversi modi. Potrebbe essere noto in anticipo (poiché il realm fa parte dell'identificatore principal), potrebbe essere memorizzato in un nameserver, o potrebbe essere ottenuto da un file di configurazione. Se il realm da utilizzare viene ottenuto da un nameserver, c'è il pericolo di essere ingannati se il servizio di nomi che fornisce il nome del realm non è autenticato. Ciò potrebbe risultare nell'uso di un realm che è stato compromesso, il che comporterebbe la capacità di un attaccante di compromettere l'autenticazione del server applicativo al client.

[Il resto del contenuto segue la struttura del documento originale con tutte le sezioni 3.3.2, 3.3.3, 3.3.4 e le sottosezioni relative al controllo dei ticket revocati e alla codifica del campo transited]