4. Encryption and Checksum Specifications (Specifiche di Crittografia e Checksum)
4. Encryption and Checksum Specifications (Specifiche di Crittografia e Checksum)
I protocolli Kerberos descritti in questo documento sono progettati per crittografare messaggi di dimensioni arbitrarie, utilizzando cifrari di crittografia a flusso o a blocchi. La crittografia viene utilizzata per dimostrare le identità delle entità di rete che partecipano agli scambi di messaggi. Il Key Distribution Center per ciascun realm è fidato da tutti i principal registrati in quel realm per memorizzare una chiave segreta in confidenza. La prova della conoscenza di questa chiave segreta viene utilizzata per verificare l'autenticità di un principal.
Il KDC utilizza la chiave segreta del principal (nello scambio AS) o una chiave di sessione condivisa (nello scambio TGS) per crittografare le risposte alle richieste di ticket; la capacità di ottenere la chiave segreta o la chiave di sessione implica la conoscenza delle chiavi appropriate e l'identità del KDC. La capacità di un principal di decifrare la risposta del KDC e di presentare un Ticket e un Authenticator correttamente formato (generato con la chiave di sessione dalla risposta del KDC) a un servizio verifica l'identità del principal; allo stesso modo la capacità del servizio di estrarre la chiave di sessione dal Ticket e di dimostrare la sua conoscenza di essa in una risposta verifica l'identità del servizio.
[RFC3961] definisce un framework per definire meccanismi di crittografia e checksum da utilizzare con Kerberos. Definisce anche diversi di tali meccanismi, e altri possono essere aggiunti in futuri aggiornamenti a quel documento.
L'operazione string-to-key fornita da [RFC3961] viene utilizzata per produrre una chiave a lungo termine per un principal (generalmente per un utente). La stringa di salt predefinita, se nessuna viene fornita tramite dati di pre-autenticazione, è la concatenazione del realm e dei componenti del nome del principal, in ordine, senza separatori. A meno che non sia indicato diversamente, viene utilizzato il set di parametri opachi string-to-key predefinito come definito in [RFC3961].
I dati crittografati, le chiavi e i checksum vengono trasmessi utilizzando gli oggetti dati EncryptedData, EncryptionKey e Checksum definiti nella Sezione 5.2.9. Le operazioni di crittografia, decifratura e checksum descritte in questo documento utilizzano le corrispondenti operazioni di crittografia, decifratura e get_mic descritte in [RFC3961], con generazione di "chiave specifica" implicita utilizzando i valori "key usage" specificati nella descrizione di ciascun oggetto EncryptedData o Checksum per variare la chiave per ciascuna operazione. Si noti che in alcuni casi, il valore da utilizzare dipende dal metodo di scelta della chiave o dal contesto del messaggio.
I key usage sono interi senza segno a 32 bit; zero non è consentito. I valori di key usage per la crittografia o il checksum dei messaggi Kerberos sono indicati nella Sezione 5 insieme alle definizioni dei messaggi. I valori di key usage 512-1023 sono riservati per usi interni a un'implementazione Kerberos. (Ad esempio, seminare un generatore di numeri pseudo-casuali con un valore prodotto crittografando qualcosa con una chiave di sessione e un valore di key usage non utilizzato per nessun altro scopo.) I valori di key usage tra 1024 e 2047 (inclusi) sono riservati per l'uso applicativo; le applicazioni DOVREBBERO utilizzare valori pari per la crittografia e valori dispari per i checksum all'interno di questo intervallo. I valori di key usage sono anche riassunti in una tabella nella Sezione 7.5.1.
Potrebbero esistere altri documenti che definiscono protocolli in termini dei tipi di crittografia o tipi di checksum RFC 1510. Questi documenti non avrebbero conoscenza dei key usage. Affinché queste specifiche continuino ad essere significative fino a quando non vengono aggiornate, se non vengono specificati valori di key usage, allora i key usage 1024 e 1025 devono essere utilizzati per derivare le chiavi rispettivamente per la crittografia e i checksum. (Questo non si applica ai protocolli che eseguono la propria crittografia indipendentemente da questo framework, utilizzando direttamente la chiave risultante dallo scambio di autenticazione Kerberos.) I nuovi protocolli definiti in termini dei tipi di crittografia e checksum Kerberos DOVREBBERO utilizzare i propri valori di key usage.
A meno che non sia indicato diversamente, non viene eseguito alcun concatenamento dello stato del cifrario da un'operazione di crittografia a un'altra.
Nota di implementazione: Sebbene non sia raccomandato, alcuni protocolli applicativi continueranno a utilizzare direttamente i dati della chiave, anche se solo nelle specifiche di protocollo attualmente esistenti. Un'implementazione destinata a supportare applicazioni Kerberos generali potrebbe quindi dover rendere disponibili i dati della chiave, così come gli attributi e le operazioni descritti in [RFC3961]. Una delle ragioni più comuni per eseguire direttamente la crittografia è il controllo diretto sulla negoziazione e selezione di un algoritmo di crittografia "sufficientemente forte" (nel contesto di una determinata applicazione). Sebbene Kerberos non fornisca direttamente una struttura per negoziare i tipi di crittografia tra il client applicativo e il server, esistono approcci per utilizzare Kerberos per facilitare questa negoziazione. Ad esempio, un client può richiedere solo tipi di chiave di sessione "sufficientemente forti" dal KDC e aspettarsi che qualsiasi tipo restituito dal KDC sarà compreso e supportato dal server applicativo.