3.6. The KRB_CRED Exchange (Lo Scambio KRB_CRED)

Il messaggio KRB_CRED PUÒ essere utilizzato dai client che richiedono la capacità di inviare credenziali Kerberos da un host a un altro. Ciò viene ottenuto inviando i ticket insieme ai dati crittografati contenenti le chiavi di sessione e altre informazioni associate ai ticket.

3.6.1. Generazione di un Messaggio KRB_CRED

Quando un'applicazione desidera inviare un messaggio KRB_CRED, ottiene prima (utilizzando lo scambio KRB_TGS) le credenziali da inviare all'host remoto. Quindi costruisce un messaggio KRB_CRED utilizzando il ticket o i ticket così ottenuti, posizionando la chiave di sessione necessaria per utilizzare ciascun ticket nel campo key della corrispondente sequenza KrbCredInfo della parte crittografata del messaggio KRB_CRED.

Altre informazioni associate a ciascun ticket e ottenute durante lo scambio KRB_TGS sono anche posizionate nella corrispondente sequenza KrbCredInfo nella parte crittografata del messaggio KRB_CRED. Il tempo corrente e, se sono specificamente richiesti dall'applicazione, i campi nonce, s-address e r-address sono posizionati nella parte crittografata del messaggio KRB_CRED, che viene quindi crittografato sotto una chiave di crittografia precedentemente scambiata nello scambio KRB_AP (solitamente l'ultima chiave negoziata tramite subkey, o la chiave di sessione se non è avvenuta alcuna negoziazione).

Nota di implementazione: Quando si costruisce un messaggio KRB_CRED per l'inclusione in un token di contesto iniziale GSSAPI, l'implementazione MIT di Kerberos non crittograferà il messaggio KRB_CRED se la chiave di sessione è una chiave DES o triple DES. Per l'interoperabilità con MIT, l'implementazione Microsoft non crittograferà il KRB_CRED in un token GSSAPI se sta utilizzando una chiave di sessione DES. A partire dalla versione 1.2.5, MIT Kerberos può ricevere e decodificare token KRB_CRED crittografati o non crittografati nello scambio GSSAPI. L'implementazione Heimdal di Kerberos può anche accettare messaggi KRB_CRED crittografati o non crittografati. Poiché il messaggio KRB_CRED in un token GSSAPI è crittografato nell'authenticator, il comportamento MIT non presenta un problema di sicurezza, sebbene sia una violazione della specifica Kerberos.

3.6.2. Ricezione del Messaggio KRB_CRED

Quando un'applicazione riceve un messaggio KRB_CRED, lo verifica. Se si verifica un errore, viene riportato un codice di errore per l'uso da parte dell'applicazione. Il messaggio viene verificato controllando che i campi della versione del protocollo e del tipo corrispondano rispettivamente alla versione corrente e a KRB_CRED. Una mancata corrispondenza genera un errore KRB_AP_ERR_BADVERSION o KRB_AP_ERR_MSG_TYPE. L'applicazione quindi decifra il testo cifrato ed elabora il testo in chiaro risultante. Se la decifratura mostra che i dati sono stati modificati, viene generato un errore KRB_AP_ERR_BAD_INTEGRITY.

Se presente o richiesto, il destinatario PUÒ verificare che il rapporto del sistema operativo sull'indirizzo del mittente corrisponda all'indirizzo del mittente nel messaggio, e che uno degli indirizzi del destinatario appaia come indirizzo del destinatario nel messaggio. Il controllo dell'indirizzo non fornisce alcuna sicurezza aggiuntiva, poiché l'indirizzo, se presente, è già stato controllato nel messaggio KRB_AP_REQ e non c'è alcun beneficio da ottenere per un attaccante nel riflettere un messaggio KRB_CRED al suo originatore. Quindi, il destinatario PUÒ ignorare l'indirizzo anche se è presente per funzionare meglio in ambienti Network Address Translation (NAT). Una corrispondenza non riuscita per entrambi i casi genera un errore KRB_AP_ERR_BADADDR. I destinatari POSSONO saltare il controllo dell'indirizzo, poiché il messaggio KRB_CRED generalmente non può essere riflesso all'originatore. I campi timestamp e usec (e il campo nonce, se richiesto) vengono controllati successivamente. Se il timestamp e usec non sono presenti, o se sono presenti ma non correnti, viene generato l'errore KRB_AP_ERR_SKEW.

Se tutti i controlli hanno successo, l'applicazione memorizza ciascuno dei nuovi ticket nella sua cache delle credenziali insieme alla chiave di sessione e altre informazioni nella corrispondente sequenza KrbCredInfo dalla parte crittografata del messaggio KRB_CRED.