3.5. The KRB_PRIV Exchange (Lo Scambio KRB_PRIV)

Il messaggio KRB_PRIV PUÒ essere utilizzato dai client che richiedono riservatezza e la capacità di rilevare modifiche dei messaggi scambiati. Ciò viene ottenuto crittografando i messaggi e aggiungendo informazioni di controllo.

3.5.1. Generazione di un Messaggio KRB_PRIV

Quando un'applicazione desidera inviare un messaggio KRB_PRIV, raccoglie i propri dati e le appropriate informazioni di controllo (specificate nella Sezione 5.7.1) e li crittografa sotto una chiave di crittografia (solitamente l'ultima chiave negoziata tramite subkey, o la chiave di sessione se non è avvenuta alcuna negoziazione). Come parte delle informazioni di controllo, il client DEVE scegliere di utilizzare un timestamp o un numero di sequenza (o entrambi); vedere la discussione nella Sezione 3.4.1 per le linee guida su quale utilizzare. Dopo che i dati utente e le informazioni di controllo sono crittografati, il client trasmette il testo cifrato e alcune informazioni di "busta" al destinatario.

3.5.2. Ricezione del Messaggio KRB_PRIV

Quando un'applicazione riceve un messaggio KRB_PRIV, lo verifica come segue. Se si verifica un errore, viene riportato un codice di errore per l'uso da parte dell'applicazione.

Il messaggio viene prima controllato verificando che i campi della versione del protocollo e del tipo corrispondano rispettivamente alla versione corrente e a KRB_PRIV. 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.

L'indirizzo del mittente DEVE essere incluso nelle informazioni di controllo; il destinatario verifica che il rapporto del sistema operativo sull'indirizzo del mittente corrisponda all'indirizzo del mittente nel messaggio. Se è specificato un indirizzo del destinatario o il destinatario richiede un indirizzo, allora uno degli indirizzi del destinatario DEVE anche apparire come indirizzo del destinatario nel messaggio. Dove l'indirizzo di un mittente o di un destinatario potrebbe non corrispondere altrimenti all'indirizzo in un messaggio a causa della traduzione degli indirizzi di rete, un'applicazione PUÒ essere scritta per utilizzare indirizzi del tipo di indirizzo direzionale al posto dell'indirizzo di rete effettivo.

Una corrispondenza non riuscita per entrambi i casi genera un errore KRB_AP_ERR_BADADDR. Per funzionare con la traduzione degli indirizzi di rete, le implementazioni POSSONO utilizzare il tipo di indirizzo direzionale definito nella Sezione 7.1 per l'indirizzo del mittente e non includere alcun indirizzo del destinatario.

Successivamente vengono controllati i campi timestamp e usec e/o il numero di sequenza. Se timestamp e usec sono attesi e non presenti, o se sono presenti ma non correnti, viene generato l'errore KRB_AP_ERR_SKEW. Se il nome del server, insieme al nome del client, il tempo e i campi microsecond dall'Authenticator corrispondono a qualsiasi tupla vista recentemente, viene generato l'errore KRB_AP_ERR_REPEAT. Se è incluso un numero di sequenza errato, o se è atteso un numero di sequenza ma non è presente, viene generato l'errore KRB_AP_ERR_BADORDER. Se né un timestamp e usec né un numero di sequenza sono presenti, viene generato un errore KRB_AP_ERR_MODIFIED.

Se tutti i controlli hanno successo, l'applicazione può assumere che il messaggio sia stato generato dal suo peer e sia stato trasmesso in modo sicuro (senza che intrusi vedessero i contenuti non crittografati).