3.4. The KRB_SAFE Exchange (Lo Scambio KRB_SAFE)

Il messaggio KRB_SAFE PUÒ essere utilizzato dai client che richiedono la capacità di rilevare modifiche dei messaggi che scambiano. Ciò viene ottenuto includendo un checksum a prova di collisione con chiave dei dati utente e alcune informazioni di controllo. Il checksum ha una chiave con una chiave di crittografia (solitamente l'ultima chiave negoziata tramite subkey, o la chiave di sessione se non è avvenuta alcuna negoziazione).

3.4.1. Generazione di un Messaggio KRB_SAFE

Quando un'applicazione desidera inviare un messaggio KRB_SAFE, raccoglie i propri dati e le appropriate informazioni di controllo e calcola un checksum su di essi. L'algoritmo di checksum dovrebbe essere il checksum con chiave obbligatorio da implementare insieme al sistema crittografico utilizzato per la sotto-sessione o la chiave di sessione. Il checksum viene generato utilizzando la chiave di sotto-sessione, se presente, o la chiave di sessione. Alcune implementazioni utilizzano un algoritmo di checksum diverso per i messaggi KRB_SAFE, ma farlo in modo interoperabile non è sempre possibile.

Le informazioni di controllo per il messaggio KRB_SAFE includono sia un timestamp che un numero di sequenza. Il progettista di un'applicazione che utilizza il messaggio KRB_SAFE DEVE scegliere almeno uno dei due meccanismi. Questa scelta DOVREBBE essere basata sulle esigenze del protocollo applicativo.

I numeri di sequenza sono utili quando tutti i messaggi inviati saranno ricevuti dal proprio peer. Lo stato della connessione è attualmente richiesto per mantenere la chiave di sessione, quindi mantenere il prossimo numero di sequenza non dovrebbe presentare un problema aggiuntivo.

Se il protocollo applicativo è previsto tollerare messaggi persi senza che vengano reinviati, l'uso del timestamp è il meccanismo appropriato di rilevamento dei replay. L'uso dei timestamp è anche il meccanismo appropriato per i protocolli multi-cast in cui tutti i propri peer condividono una chiave di sotto-sessione comune, ma alcuni messaggi saranno inviati a un sottoinsieme dei propri peer.

Dopo aver calcolato il checksum, il client trasmette quindi le informazioni e il checksum al destinatario nel formato del messaggio specificato nella Sezione 5.6.1.

3.4.2. Ricezione del Messaggio KRB_SAFE

Quando un'applicazione riceve un messaggio KRB_SAFE, 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_SAFE. Una mancata corrispondenza genera un errore KRB_AP_ERR_BADVERSION o KRB_AP_ERR_MSG_TYPE. L'applicazione verifica che il checksum utilizzato sia un checksum con chiave a prova di collisione che utilizza chiavi compatibili con la sotto-sessione o la chiave di sessione come appropriato (o con la chiave applicativa derivata dalle chiavi di sessione o sotto-sessione). Se non lo è, viene generato un errore KRB_AP_ERR_INAPP_CKSUM. 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, e (se è specificato un indirizzo del destinatario o il destinatario richiede un indirizzo) che uno degli indirizzi del destinatario appaia come indirizzo del destinatario nel messaggio. Per funzionare con la traduzione degli indirizzi di rete, i mittenti POSSONO utilizzare il tipo di indirizzo direzionale specificato nella Sezione 8.1 per l'indirizzo del mittente e non includere indirizzi del destinatario. Una corrispondenza non riuscita per entrambi i casi genera un errore KRB_AP_ERR_BADADDR. Quindi 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. I timestamp non sono richiesti essere strettamente ordinati; sono solo richiesti essere nella finestra di 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 (inviata o ricevuta), 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. Infine, il checksum viene calcolato sui dati e sulle informazioni di controllo, e se non corrisponde al checksum ricevuto, viene generato un errore KRB_AP_ERR_MODIFIED.

Se tutti i controlli hanno successo, l'applicazione è assicurata che il messaggio sia stato generato dal suo peer e non sia stato modificato in transito.

Le implementazioni DOVREBBERO accettare qualsiasi algoritmo di checksum implementato che abbia sia sicurezza adeguata che chiavi compatibili con la sotto-sessione o la chiave di sessione. I checksum senza chiave o non a prova di collisione non sono adatti per questo uso.