Passa al contenuto principale

3. Operazione StartTLS

L'operazione Start Transport Layer Security (StartTLS), definita nella sezione 4.14 di [RFC4511], offre la capacità di stabilire TLS [RFC4346] in una sessione LDAP.

Gli obiettivi dell'uso del protocollo TLS con LDAP sono garantire la riservatezza e l'integrità dei dati e, facoltativamente, fornire l'autenticazione. TLS fornisce esplicitamente queste capacità, tuttavia i servizi di autenticazione di TLS sono disponibili per LDAP solo in combinazione con il metodo di autenticazione SASL EXTERNAL (vedere la sezione 5.2.3), e ancora solo se l'implementazione SASL EXTERNAL sceglie di utilizzare le credenziali di TLS.

3.1. Procedure di costituzione di TLS​

Questa sezione descrive le procedure generali che i client e i server devono seguire per la costituzione di TLS. Queste procedure tengono conto di vari aspetti del livello TLS, inclusi la scoperta del livello di sicurezza risultante e l'asserzione dell'identità di autorizzazione del client.

3.1.1. Sequenziamento delle richieste StartTLS​

Un client può inviare la richiesta estesa StartTLS in qualsiasi momento dopo la costituzione di una sessione LDAP, ad eccezione:

  - quando TLS è attualmente stabilito sulla sessione,
  - quando una negoziazione SASL a più fasi è in corso sulla sessione, o
  - quando ci sono risposte in sospeso a richieste di operazione precedentemente emesse sulla sessione.

Come descritto in [RFC4511], sezione 4.14.1, la violazione (rilevata) di uno di questi requisiti comporta la restituzione del resultCode operationsError.

Gli implementatori di client dovrebbero assicurare il rigoroso rispetto di questi requisiti di sequenziamento delle operazioni per evitare problemi di interoperabilità. L'esperienza operativa mostra che la violazione di tali requisiti causa problemi di interoperabilità, poiché esistono condizioni di competizione che impediscono ai server di rilevare alcune violazioni di questi requisiti, a causa di fattori come la velocità dell'hardware del server e le latenze di rete.

Non esiste alcun requisito generale che il client debba o non debba aver già eseguito un'operazione Bind (sezione 5) prima di inviare una richiesta dell'operazione StartTLS; tuttavia, quando un client intende eseguire sia un'operazione Bind sia un'operazione StartTLS, DOVREBBE (SHOULD) eseguire prima l'operazione StartTLS, in modo che i messaggi di richiesta e risposta Bind siano protetti dai servizi di sicurezza dei dati stabiliti dall'operazione StartTLS.

3.1.2. Certificato client​

Se un server LDAP richiede o impone a un client di fornire un certificato utente durante la negoziazione TLS e il client non fornisce un certificato utente adeguato (ad esempio uno verificabile), il server può usare una politica di sicurezza locale per determinare se completare con successo la negoziazione TLS.

Se un client che ha fornito un certificato adeguato esegue successivamente un'operazione Bind usando il meccanismo di autenticazione SASL EXTERNAL (sezione 5.2.3), le informazioni nel certificato possono essere usate dal server per identificare e autenticare il client.

3.1.3. Verifica dell'identità del server​

Al fine di prevenire attacchi man-in-the-middle, il client DEVE (MUST) verificare l'identità del server (presentata nel messaggio Certificate del server). In questa sezione, la comprensione del client dell'identità del server (tipicamente l'identità usata per stabilire la connessione di trasporto) è detta "identità di riferimento" (reference identity).

Il client determina il tipo (ad esempio nome DNS o indirizzo IP) dell'identità di riferimento ed esegue un confronto tra l'identità di riferimento e ogni valore subjectAltName del tipo corrispondente, finché non si trova una corrispondenza. Una volta trovata una corrispondenza, l'identità del server è stata verificata e la verifica dell'identità del server è completa. I diversi tipi di subjectAltName sono confrontati in modi diversi. Le sezioni 3.1.3.1 fino a 3.1.3.3 spiegano come confrontare i valori dei vari tipi di subjectAltName.

Il client può mappare l'identità di riferimento su un tipo diverso prima di eseguire un confronto. Le mappature possono essere eseguite per tutti i tipi di subjectAltName disponibili su cui l'identità di riferimento può essere mappata; tuttavia, l'identità di riferimento DOVREBBE (SHOULD) essere mappata solo su tipi per cui la mappatura è intrinsecamente sicura (ad esempio l'estrazione del nome DNS da un URI per confrontarlo con un subjectAltName di tipo dNSName) o effettuata in modo sicuro (ad esempio usando DNSSEC, o tabelle di corrispondenza host-verso-indirizzo / indirizzo-verso-host configurate dall'utente o dall'amministratore).

L'identità del server può anche essere verificata confrontando l'identità di riferimento con il valore Common Name (CN) [RFC4519] del Relative Distinguished Name (RDN) foglia del campo subjectName del certificato del server. Questo confronto viene effettuato usando le regole di confronto dei nomi DNS della sezione 3.1.3.1 qui sotto, tranne per il fatto che la corrispondenza con caratteri jolly non è consentita. Sebbene l'uso del valore Common Name sia una prassi esistente, essa è sconsigliata, e le autorità di certificazione sono incoraggiate a fornire in alternativa valori subjectAltName. Si noti che l'implementazione TLS può rappresentare i DN nei certificati secondo X.500 o altre convenzioni. Ad esempio, alcune implementazioni X.500 ordinano i RDN di un DN secondo una convenzione da sinistra a destra (dal più significativo al meno significativo) invece della convenzione da destra a sinistra di LDAP.

Se la verifica dell'identità del server fallisce, i client orientati all'utente DOVREBBERO (SHOULD) o notificare all'utente (i client possono in tal caso dare all'utente la possibilità di continuare la sessione LDAP) o chiudere la connessione di trasporto e indicare che l'identità del server è sospetta. I client automatizzati DOVREBBERO (SHOULD) chiudere la connessione di trasporto e quindi restituire o registrare un errore che indica che l'identità del server è sospetta, o entrambe le cose.

Oltre alla verifica dell'identità del server descritta in questa sezione, i client dovrebbero essere pronti a effettuare ulteriori controlli per assicurarsi che il server sia autorizzato a fornire il servizio per la cui fornitura è richiesto. Il client può dover usare informazioni di politica locale per prendere questa determinazione.

3.1.3.1. Confronto dei nomi DNS​

Se l'identità di riferimento è un nome di dominio internazionalizzato, le implementazioni conformi DEVONO (MUST) convertirlo nel formato ASCII Compatible Encoding (ACE) come specificato nella sezione 4 dell'RFC 3490 [RFC3490] prima di confrontarlo con i valori subjectAltName di tipo dNSName. In particolare, le implementazioni conformi DEVONO (MUST) eseguire l'operazione di conversione specificata nella sezione 4 dell'RFC 3490 come segue:

  * al passaggio 1, il nome di dominio DEVE (SHALL) essere considerato una "stored string";
  * al passaggio 3, impostare il flag chiamato "UseSTD3ASCIIRules";
  * al passaggio 4, elaborare ogni etichetta con l'operazione "ToASCII"; e
  * al passaggio 5, cambiare tutti i separatori di etichetta in U+002E (punto).

Dopo aver eseguito la conversione "to-ASCII", le etichette e i nomi DNS DEVONO (MUST) essere confrontati per l'uguaglianza secondo le regole specificate nella sezione 3 dell'RFC 3490.

Il carattere jolly '*' (ASCII 42) è consentito nei valori subjectAltName di tipo dNSName, e solo come etichetta DNS più a sinistra (meno significativa) di tale valore. Questo carattere jolly corrisponde a qualsiasi etichetta DNS più a sinistra nel nome del server. Cioè, il subject *.example.com corrisponde ai nomi di server a.example.com e b.example.com, ma non corrisponde a example.com o a.b.example.com.

3.1.3.2. Confronto degli indirizzi IP​

Quando l'identità di riferimento è un indirizzo IP, l'identità DEVE (MUST) essere convertita nella rappresentazione in stringa di ottetti in "network byte order" [RFC791][RFC2460]. Per IP versione 4, come specificato nell'RFC 791, la stringa di ottetti conterrà esattamente quattro ottetti. Per IP versione 6, come specificato nell'RFC 2460, la stringa di ottetti conterrà esattamente sedici ottetti. Questa stringa di ottetti viene quindi confrontata con i valori subjectAltName di tipo iPAddress. Una corrispondenza si ha se la stringa di ottetti dell'identità di riferimento e le stringhe di ottetti dei valori sono identiche.

3.1.3.3. Confronto di altri tipi di subjectName​

Le implementazioni client POSSONO (MAY) supportare la corrispondenza con valori subjectAltName di altri tipi come descritto in altri documenti.

3.1.4. Scoperta del livello di sicurezza risultante​

Dopo che un livello TLS è stato stabilito in una sessione LDAP, entrambe le parti devono decidere indipendentemente l'una dall'altra se continuare o meno, in base alla politica locale e al livello di sicurezza raggiunto. Se una delle parti decide che il livello di sicurezza è inadeguato per proseguire, DOVREBBE (SHOULD) rimuovere il livello TLS subito dopo il completamento della (ri)negoziazione TLS (vedere [RFC4511], sezione 4.14.3, e la sezione 3.2 seguente). Le implementazioni possono rivalutare il livello di sicurezza in qualsiasi momento e, trovandolo inadeguato, dovrebbero rimuovere il livello TLS.

3.1.5. Aggiornamento delle informazioni sulle capacità del server​

Dopo che un livello TLS è stato stabilito in una sessione LDAP, il client DOVREBBE (SHOULD) scartare o aggiornare tutte le informazioni sul server che ha ottenuto prima dell'inizio della negoziazione TLS e che non ha ottenuto tramite meccanismi sicuri. Ciò protegge da attacchi man-in-the-middle che potrebbero aver alterato qualsiasi informazione sulle capacità del server recuperata prima dell'installazione del livello TLS.

Il server può annunciare capacità diverse dopo l'installazione di un livello TLS. In particolare, il valore di 'supportedSASLMechanisms' può essere diverso dopo l'installazione di un livello TLS (in particolare, i meccanismi EXTERNAL e PLAIN [PLAIN] sono probabilmente elencati solo dopo l'installazione di un livello TLS).

3.2. Effetto di TLS sullo stato di autorizzazione​

La costituzione, la modifica e/o la chiusura di TLS può comportare il passaggio dello stato di autorizzazione a un nuovo stato. Ciò viene discusso ulteriormente nella sezione 4.

3.3. Suite di cifratura TLS​

Diverse questioni dovrebbero essere prese in considerazione nella scelta delle suite di cifratura TLS adeguate per una data situazione. Queste questioni includono:

  - la capacità della suite di cifratura di fornire un'adeguata protezione della riservatezza per le password e gli altri dati inviati sulla connessione di trasporto. Gli implementatori di client e server dovrebbero essere consapevoli che alcune suite di cifratura TLS non forniscono alcuna protezione della riservatezza, mentre altre che la forniscono possono essere vulnerabili a un attacco di rottura per forza bruta, in particolare alla luce di velocità di CPU in continua crescita che riducono il tempo necessario per condurre con successo tali attacchi;

  - gli implementatori di client e server dovrebbero valutare attentamente il valore della password o dei dati protetti rispetto al livello di protezione della riservatezza fornito dalla suite di cifratura, per assicurarsi che il livello di protezione fornito dalla suite sia adeguato;

  - la vulnerabilità (o l'assenza di essa) della suite di cifratura agli attacchi man-in-the-middle. Le suite vulnerabili agli attacchi man-in-the-middle NON DOVREBBERO (SHOULD NOT) essere usate per proteggere password o dati sensibili, salvo che la configurazione della rete sia tale che il pericolo di un attacco man-in-the-middle sia trascurabile;

  - dopo il completamento di una negoziazione TLS (iniziale o successiva), entrambi gli omologhi del protocollo dovrebbero verificare indipendentemente che i servizi di sicurezza forniti dalla suite di cifratura negoziata siano adeguati all'uso previsto della sessione LDAP. In caso contrario, il livello TLS dovrebbe essere chiuso.