7.2. KDC Messaging - IP Transports (Messaggistica KDC - Trasporti IP)

7.2. KDC Messaging: IP Transports (Messaggistica KDC: Trasporti IP)

Kerberos definisce due meccanismi di trasporto IP per la comunicazione tra client e server: UDP/IP e TCP/IP.

7.2.1. UDP/IP transport (Trasporto UDP/IP)

I server Kerberos (KDC) che supportano i trasporti IP DEVONO accettare richieste UDP e DOVREBBERO ascoltarle sulla porta 88 (decimale) a meno che non siano specificamente configurati per ascoltare su una porta UDP alternativa. Porte alternative POSSONO essere utilizzate quando si eseguono più KDC per più realm sullo stesso host.

I client Kerberos che supportano i trasporti IP DOVREBBERO supportare l'invio di richieste UDP. I client DOVREBBERO utilizzare la scoperta KDC [7.2.3] per identificare l'indirizzo IP e la porta a cui invieranno la loro richiesta.

Quando si contatta un KDC per una richiesta KRB_KDC_REQ utilizzando il trasporto UDP/IP, il client deve inviare un datagramma UDP contenente solo una codifica della richiesta al KDC. Il KDC risponderà con un datagramma di risposta contenente solo una codifica del messaggio di risposta (KRB_ERROR o KRB_KDC_REP) alla porta mittente all'indirizzo IP del mittente. La risposta a una richiesta fatta tramite trasporto UDP/IP DEVE utilizzare anche il trasporto UDP/IP. Se la risposta non può essere gestita utilizzando UDP (ad esempio, perché è troppo grande), il KDC DEVE restituire KRB_ERR_RESPONSE_TOO_BIG, forzando il client a riprovare la richiesta utilizzando il trasporto TCP.

7.2.2. TCP/IP Transport (Trasporto TCP/IP)

I server Kerberos (KDC) che supportano i trasporti IP DEVONO accettare richieste TCP e DOVREBBERO ascoltarle sulla porta 88 (decimale) a meno che non siano specificamente configurati per ascoltare su una porta TCP alternativa. Porte alternative POSSONO essere utilizzate quando si eseguono più KDC per più realm sullo stesso host.

I client DEVONO supportare l'invio di richieste TCP, ma POSSONO scegliere di provare una richiesta inizialmente utilizzando il trasporto UDP. I client DOVREBBERO utilizzare la scoperta KDC [7.2.3] per identificare l'indirizzo IP e la porta a cui invieranno la loro richiesta.

Nota di implementazione: Alcune estensioni al protocollo Kerberos non avranno successo se è coinvolto un client o KDC che non supporta il trasporto TCP. Le implementazioni di RFC 1510 non erano richieste per supportare i trasporti TCP/IP.

Quando il messaggio KRB_KDC_REQ viene inviato al KDC su un flusso TCP, la risposta (messaggio KRB_KDC_REP o KRB_ERROR) DEVE essere restituita al client sullo stesso flusso TCP stabilito per la richiesta. Il KDC PUÒ chiudere il flusso TCP dopo aver inviato una risposta, ma PUÒ lasciare il flusso aperto per un periodo di tempo ragionevole se si aspetta un seguito. Si deve prestare attenzione nella gestione delle connessioni TCP/IP sul KDC per prevenire attacchi denial of service basati sul numero di connessioni TCP/IP aperte.

Il client DEVE essere preparato ad avere il flusso chiuso dal KDC in qualsiasi momento dopo la ricezione di una risposta. Una chiusura del flusso NON DOVREBBE essere trattata come un errore fatale. Invece, se sono richiesti più scambi (ad esempio, alcune forme di pre-autenticazione), il client potrebbe dover stabilire una nuova connessione quando è pronto a inviare messaggi successivi. Un client PUÒ chiudere il flusso dopo aver ricevuto una risposta, e DOVREBBE chiudere il flusso se non si aspetta di inviare messaggi di seguito.

Un client PUÒ inviare più richieste prima di ricevere risposte, sebbene debba essere preparato a gestire la chiusura della connessione dopo la prima risposta.

Ogni richiesta (KRB_KDC_REQ) e risposta (KRB_KDC_REP o KRB_ERROR) inviata sul flusso TCP è preceduta dalla lunghezza della richiesta come 4 ottetti in ordine di byte di rete. Il bit alto della lunghezza è riservato per espansione futura e DEVE attualmente essere impostato a zero. Se un KDC che non capisce come interpretare un bit alto impostato della codifica della lunghezza riceve una richiesta con il bit di ordine alto della lunghezza impostato, DEVE restituire un messaggio KRB-ERROR con l'errore KRB_ERR_FIELD_TOOLONG e DEVE chiudere il flusso TCP.

Se più richieste vengono inviate su una singola connessione TCP e il KDC invia più risposte, il KDC non è richiesto di inviare le risposte nell'ordine delle richieste corrispondenti. Questo può permettere ad alcune implementazioni di inviare ogni risposta non appena è pronta, anche se le richieste precedenti sono ancora in elaborazione (ad esempio, in attesa di una risposta da un dispositivo o database esterno).

7.2.3. KDC Discovery on IP Networks (Scoperta KDC su Reti IP)

Le implementazioni client Kerberos DEVONO fornire un mezzo per il client per determinare la posizione dei Key Distribution Center (KDC) Kerberos. Tradizionalmente, le implementazioni Kerberos hanno memorizzato tali informazioni di configurazione in un file su ciascuna macchina client. L'esperienza ha dimostrato che questo metodo di memorizzazione delle informazioni di configurazione presenta problemi con informazioni obsolete e scalabilità, specialmente quando si utilizza l'autenticazione cross-realm. Questa sezione descrive un metodo per utilizzare il Domain Name System [RFC1035] per memorizzare le informazioni sulla posizione del KDC.

7.2.3.1. DNS vs. Kerberos: Case Sensitivity of Realm Names

In Kerberos, i nomi dei realm sono case-sensitive. Sebbene sia fortemente incoraggiato che tutti i nomi dei realm siano tutti maiuscoli, questa raccomandazione non è stata adottata da tutti i siti. Alcuni siti utilizzano nomi tutti minuscoli e altri utilizzano case misto. DNS, d'altra parte, è case-insensitive per le query. Poiché i nomi dei realm "MYREALM", "myrealm" e "MyRealm" sono tutti diversi, ma si risolvono nello stesso modo nel sistema dei nomi di dominio, è necessario che solo una delle possibili combinazioni di caratteri maiuscoli e minuscoli sia utilizzata nei nomi dei realm.

7.2.3.2. Specifying KDC Location Information with DNS SRV records

Le informazioni sulla posizione del KDC devono essere memorizzate utilizzando il DNS SRV RR [RFC2782]. Il formato di questo RR è il seguente:

_Service._Proto.Realm TTL Class SRV Priority Weight Port Target

Il nome del servizio per Kerberos è sempre "kerberos".

Il Proto può essere "udp" o "tcp". Se questi record SRV devono essere utilizzati, i record "udp" e "tcp" DEVONO essere specificati per tutte le distribuzioni KDC.

Il Realm è il realm Kerberos a cui corrisponde questo record. Il realm DEVE essere un nome di realm in stile dominio.

TTL, Class, SRV, Priority, Weight e Target hanno il significato standard come definito in RFC 2782.

Come da RFC 2782, il numero di porta utilizzato per i record SRV "_udp" e "_tcp" DOVREBBE essere il valore assegnato a "kerberos" dall'Internet Assigned Number Authority: 88 (decimale), a meno che il KDC non sia configurato per ascoltare su una porta TCP alternativa.

Nota di implementazione: Molte implementazioni client esistenti non supportano la scoperta KDC e sono configurate per inviare richieste alla porta assegnata IANA (88 decimale), quindi è fortemente raccomandato che i KDC siano configurati per ascoltare su quella porta.

7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks

Questi sono record DNS per un realm Kerberos EXAMPLE.COM. Ha due server Kerberos, kdc1.example.com e kdc2.example.com. Le query dovrebbero essere dirette prima a kdc1.example.com come da priorità specificata. I pesi non sono utilizzati in questi record di esempio.

_kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
_kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
_kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
_kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.