Autenticazione in Ambienti Distribuiti: protocollo LDAP

Transcript

Autenticazione in
Ambienti Distribuiti:
protocollo LDAP
Prefazione -1
• Con la nascita ed evoluzione di Internet e con il
notevole incremento dei suoi utenti, sono sorti
problemi di sicurezza.
– La suite di protocolli TCP/IP non prevede nessun meccanismo
che garantisce confidenzialità e privacy tra gli utenti.
• Gli scenari e le applicazioni in cui è richiesta
confidenzialità e privacy delle connessioni
sull'inter-rete sono molteplici.
Tesina per il corso di Sicurezza su Reti a cura di:
Salvatore Moscariello
Rocco Pecoraro
Giovanni Russo
– Accedere in maniera privata ad una directory remota dislocata
su di un server è uno di questi possibili scenari.
Autenticazione in Ambienti
Distribuiti: protocollo LDAP
Prefazione -2
• Introdurremo il protocollo LDAP nato per gestire
le directory in un intero dominio internet.
– Tratteremo brevemente i dettagli relativi alla sua evoluzione.
– Daremo successivamente le nozioni di base dei protocolli che
LDAP coinvolge nella sua specifica.
– Ci soffermeremo sui vari scenari che si vengono a creare per
accedere ad una directory remota e mostreremo le varie
politiche e meccanismi di sicurezza adottati da LDAP.
2
Introduzione
Cos’è una directory?
Cos’è LDAP?
Protocolli
Metodi di autenticazione in LDAP
3
Cos’è una directory?
Servizi locali e servizi globali
• Database specializzato per la lettura e la ricerca.
• Possibilità di contenere informazioni basate su
• Alcuni servizi di directory sono locali.
attributi o descrizioni.
• Altri servizi sono globali.
• Supporto di sofisticate capacità di ricerca
•
– Forniscono servizi ad un contesto più ampio, quale ad esempio
l’intera Internet.
attraverso dei filtri.
Risposte veloci ad operazioni di consultazione o
di ricerca su volumi di dati enormi.
– Forniscono servizi ad un ristretto contesto, ad esempio una
singola macchina.
• I servizi globali sono distribuiti.
– I dati contenuti sono memorizzati in diverse macchine, ognuna
delle quali provvede al servizio di directory.
5
6
1
Cos’è LDAP?
Prima di LDAP
• LDAP è un acronimo che sta per
•
•
LIGHTWEIGHT DIRECTORY ACCESS
PROTOCOL.
È un protocollo leggero per accedere ai servizi di
directory, basati sul protocollo X.500.
Opera su TCP/IP o su altre connessioni orientate
ai servizi di trasferimento.
– Dettagli definiti nella RFC 2251.
7
• Prima di LDAP, per accedere a dati memorizzati
in una directory X.500 un client doveva
supportare il DAP (DIRECTORY ACCESS
PROTOCOL).
– Imponeva una notevole penalizzazione delle risorse in gioco
poiché richiedeva l'utilizzo della specifica OSI (Open System
Interconnection).
• LDAP nasce proprio per sostituire DAP.
8
Tipologie delle informazioni
Struttura delle informazioni
• Il modello di informazioni di LDAP è basato sulle
• Le entry di una directory sono strutturate come
entry.
in una struttura gerarchica di un albero.
• La entry che rappresenta il paese si trova alla
– Collezioni di attributi che hanno un unico nome globale: il
Distinguished Name (DN).
radice dell’albero.
• Ogni attributo della entry ha un tipo ed uno o
• Al di sotto di essa ci sono quelle che
più valori.
rappresentano stati e organizzazioni nazionali.
– I tipi sono stringhe mnemoniche, come cn per i common name,
oppure mail per gli indirizzi di posta elettronica.
– Seguono poi altri tipi di entry che possono rappresentare
organizzazioni, persone, stampanti, documenti, ecc.
9
LDAP directory tree con nomi
tradizionali
10
LDAP directory tree con nomi usati
in Internet
11
12
2
Come si accede alle informazioni
Protezione delle informazioni
• Il protocollo LDAP definisce servizi per accedere
• Molti servizi di directory non prevedono
•
• LDAP include un meccanismo nel quale un client
•
e aggiornare una directory.
L’operazione più usata è quella di ricerca di
informazioni all’interno della directory.
LDAP fornisce un efficiente algoritmo di ricerca.
protezione per i dati e le informazioni.
•
si può autenticare, o provare la sua identità ad
un directory server.
LDAP consente servizi di privacy e di integrità
delle informazioni.
13
Funzionamento di LDAP -1
Funzionamento di LDAP -2
• Il servizio di directory LDAP è basato su un
• Il client si connette al server e gli chiede
•
• Il server replica con risposte precise e/o con un
modello client – server.
Uno o più server LDAP contengono i dati che
servono a costruire l’albero delle informazioni di
una directory, il DIT (Directory Information
Tree).
15
Schema di funzionamento con un
server X.500
X .500
14
informazioni.
puntatore ad eventuali informazioni addizionali.
• Il client LDAP può comunicare sia con un server
X.500 sia con un server LDAP.
16
Schema di funzionamento con un
server LDAP
17
18
3
LDAP versione 2
LDAP versione 3
• LDAP con la versione 2 diventa un standard di
• Con questa versione LDAP viene specificato
Internet nel 1995.
– Era stata largamente implementata.
• In questa versione viene introdotto il concetto di
Bind Operation, operazione principale per fare
comunicare client e server LDAP.
– La Bind Operation è usata per stabilire un sessione tra il client e
server che permette al client di autenticarsi sul server.
19
Introduzione
•
•
direttamente su protocolli di trasporto come
TCP.
Introdotti i meccanismi SASL per rendere i
servizi offerti dal server più sicuri.
Possibilità di estendere il protocollo introducendo
nuove operazioni.
– Implementata nel 1997.
20
Introduzione ai protocolli
Protocolli
• È utile introdurre i concetti basilari di alcuni
Introduzione
SASL
TLS
OTP
DIGEST-- MD5
DIGEST
OTP SASL
protocolli utilizzati in LDAP.
• Dei protocolli SASL, TLS e OTP illustreremo
solo le caratteristiche principali.
• Tratteremo in maniera più dettagliata i protocolli
DIGEST-MD5 e OTP SASL.
Metodi di autenticazione in LDAP
22
Protocollo SASL: descrizione
Protocollo SASL: meccanismi
• Simple Authentication and Security Layer è
• I meccanismi SASL sono identificati da stringhe,
•
un metodo per includere l’autenticazione a
supporto di protocolli basati sulla connessione.
Include meccanismi per identificare e
autenticare un utente su un server
inizializza un protocollo di autenticazione.
– Presenti meccanismi opzionali per negoziare un livello sicuro ch e
assicura confidenzialità.
– Protocollo descritto nella RFC 2222.
lunghe da 1 a 20 caratteri.
• Se supporta questi meccanismi, un server,
23
– Consiste in una serie di challenges e risposte del client.
– Le challenges e le risposte sono definite per ogni meccanismo
come token binari di arbitraria lunghezza.
24
4
Protocollo SASL: funzionamento -1
Protocollo SASL: funzionamento -2
• Un server invia una challenge, indica il
• Durante l’autenticazione, il meccanismo
•
fallimento, o che l’autenticazione è completata
dopo la ricezione di un comando di
autenticazione o di una risposta di un client.
Dopo la ricezione di una challenge, un client può
rilasciare una risposta o abortire l’autenticazione.
25
Protocollo TLS: descrizione
•
trasmette una authorization identity dal client al
server.
Negozia poi l’uso di specifici meccanismi per un
livello di sicurezza.
– I meccanismi definiti in SASL sono: Kerberos version 4, GSSAPI
mechanism, S/Key mechanism, External mechanism.
TLS Record Protocol
• Lo scopo di TLS è di garantire privacy e integrità
• Il TLS Record Protocol garantisce connessioni
•
• La connessione è privata.
•
dei dati tra due applicazioni che comunicano.
È composto da due livelli: TLS Record
Protocol e TLS Handshake Protocol.
Al livello più basso il TLS si allaccia con un
protocollo di trasporto, e con il TLS Record
Protocol.
sicure che hanno due proprietà basilari.
– Per la cifratura è utilizzata la crittografia simmetrica (ad esempio
DES, RC4, ecc.).
• La connessione è affidabile.
– I Messaggi di trasporto includono un messaggio da integrità usando
MAC.
– Funzioni hash sicure sono usate per il calcolo del MAC.
– Descritto nella RFC 2246.
27
TLS Handshake Protocol -1
TLS Handshake Protocol -2
• IL TLS Record Protocol è incapsulato da
• L’identità dei peer può essere autenticata
•
protocolli da protocolli di livello più alto.
Uno di questi protocolli è il TLS Handshake
Protocol.
28
usando la crittografia asimmetrica, o a chiavi
pubbliche
– Ad esempio RSA, DSS, ecc. Può essere opzionale.
• La negoziazione di un segreto condiviso è sicura.
– Permette al server e al client di autenticarsi e negoziare un
algoritmo di cifratura e le eventuali chiavi, prima che vengano
trasmessi eventuali dati.
– La negoziazione di segreti non deve permettere ad eventuali
attaccanti di impersonare uno dei peer.
• Il TLS Handshake Protocol dà garanzia di
• La negoziazione è affidabile.
connessioni sicure che hanno tre proprietà
basilari.
26
– Nessun attaccante può modificare la comunicazione delle parti
che effettuano la negoziazione.
29
30
5
One--Time Password System
One
OTP: concetti base
• Utilizza una pass-phrase segreta per generare
• Racchiude meccanismi per l'autenticazione
•
relativa ad accessi a sistemi che richiedono
un'autenticazione sicura rispetto ad attacchi
passivi basati sul replay delle password.
One-time-password (OTP) è stato progettato per
evitare l’ascolto indesiderato delle connessioni.
•
•
– Descritto nella RFC 1938.
una sequenza di password utilizzate una sola
volta.
La pass-phrase non attraversa mai la rete ed è
quindi non vulnerabile agli attacchi di replay.
Ci sono due entità che sono coinvolte in
un'operazione di one-time password: il
generatore e il server.
31
OTP: generatore e server -1
• Il generatore produce l'appropriata OTP dalla
• Il generatore OTP crea una OTP con iterazioni
•
•
pass-phrase dell'utente e consente di vedere le
informazioni contenute nella challenge inviata
dal server.
Il server deve inviare una challenge che include i
parametri per il generatore e deve verificare la
OTP ricevuta dal client.
33
multiple, di una funzione hash sicura, a partire
dal valore seed contenuto nella challenge
ricevuta e dalla pass-phrase.
Dopo che l'autenticazione è avvenuta con
successo, il numero delle iterazioni della
funzione hash è decrementato di uno.
– Questo permette di generare una sequenza di password unica.
Generazione di una OTP
• Il server verifica l'OTP ricevuta computando i
• La generazione di una OTP consta di un passo
•
valori di una precedente autenticazione, che ha
memorizzato, con la funzione hash e confronta i
risultati.
La sicurezza del sistema OTP è basata sulla
difficoltà di invertibilità delle funzioni hash.
– Le funzioni hash supportate da questo protocollo sono MD4,
MD5 e SHA.
35
32
34
iniziale in cui tutti gli input sono combinati.
• Un secondo passo dove la funzione hash è iterata
un numero specifico di volte
• Un terzo passo dove i 64 bit prodotti dalla
funzione hash sono convertiti in parole (tramite
un dizionario) comprensibili all'utente con una
funzione di output.
36
6
Digest Authentication come
meccanismo SASL. Passo Uno.
Passo Due. DIGEST response
• Digest può essere usato come un meccanismo di
• A questo punto il client prende nota del digest
challenge e risponde al server con una stringa
strutturata e costruita secondo le regole del
digest response.
Il valore del campo response, formato da 32
cifre esadecimali con caratteri lower case sarà:
autenticazione per il protocollo SASL.
– Argomento della RFC 2831.
• Se il client non si è ancora autenticato al server,
•
deve anzitutto effettuare l’autenticazione iniziale.
Il server inizia mandando un challenge.
•
response -value =
HEX( KD ( HEX(H(A 1 )), { nonce-value, ":" nc-value, ":",
cnonce-value, ":", qop-value, ":", HEX(H(A 2 )) }))
Se il campo authzid è presente, allora A1 è uguale a:
A 1 = { H( { username-value, ":", realm -value, ":",
passwd } ),":", nonce-value, ":", cnonce-value, ":", authzid-value }
– I dati inclusi in questo challenge contengono alcune stringe
strutturate secondo le regole della digest challenge.
DIGEST response: response
response--value
38
Passo Tre. Verifica.
• Il server a questo punto riceve e verifica la
• Il campo response-value sarà:
Se il campo authzid non è presente, allora A1 è uguale a:
A 1 = { H( { username-value, ":", realm -value, ":", passwd } ), ":",
nonce-value, ":", cnonce-value }
dove passwd = *OCTET
Se il valore del campo qop è auth, allora A2 è uguale a:
A 2 = { "AUTHENTICATE:", digest-uri-value }
Se il valore del campo qop è auth-int oppure auth-conf allora A2 è:
A 2 = { "AUTHENTICATE:", digest-uri-value,
":00000000000000000000000000000000" }
37
digest response. Verifica anzitutto che il valore
di nonce-count è “00000001” e manda un
messaggio strutturato come segue:
response-auth = " rspauth" "=" response-value
Il response-value è calcolato come descritto al passo precedente,
usando i valori mandati al passo due, eccetto che se il valore di qop è auth,
allora A2 è:
A 2 = { ":", digest-uri-value }
E se qop è auth-int oppure auth-conf allora A2 vale:
A 2 = { ":", digest-uri-value,
":00000000000000000000000000000000" }
39
One -Time
OneTime--Password per il
meccanismo SASL
Profili OTP per SASL
• I meccanismi OTP SASL, sostituiscono i
• Meccanismi di SASL offrono un modo formale
meccanismi SKEY SASL.
– Sono descritti nella RFC 2444.
• OTP è una buona scelta per scenari dove il client
non è fidato.
– Darà una sola opportunità a client maliziosi di accedere a dei
servizi a nome di un altro utente.
•
40
per integrare OTP all’interno dei protocolli dove
è supportato SASL includendo IMAP, ACAP,
POP3 e LDAPv3.
OTP e OTP extended response offrono un certo
numero di opzioni.
– Per un’ autenticazione con successo, il client e il server hanno
bisogno di un set di opzioni compatibili.
• OTP è una buona scelta per situazioni dove
vengono effettuate login interattive sul server.
41
42
7
Regole per il meccanismo OTP -1
Regole per il meccanismo OTP -2
• Deve essere usata la sintassi extended response.
• I server devono supportare le quattro risposte
• I client dovrebbero supportare il monitoraggio
estese: “hex”, “word”, “init-hex” and “init-word”.
• I server devono supportare “word” e “init-word”
•
per un dizionario standard e dovrebbero
supportare dizionari alternativi.
I server non devono richiedere l’uso di altre
estensioni OTP o opzioni.
della challenge OTP per utente e una entry OTP
in formato multi-word.
– I client possono anche supportare una entry per la pass phrase e
calcolare la risposta “hex” o “word”.
• I client devono indicare quando l’autenticazione
fallisce.
–
–
–
–
A causa di un sequence number troppo basso.
Deve offrire all’utente un opzione per resettarlo.
Usando “init-hex” o ”init-word”.
È richiesto il supporto di MD5 ed è raccomandato l’uso di SHA1.
43
44
Meccanismi di
autenticazione OTP -1
Meccanismi di
• Il client inizia inviando un messaggio al server
2. Un Authentication Identity. Sarà usata l’identità
della pass-phrase.
con:
1. Un Authorizzation Identity. Se è usata la stringa
vuota, viene utilizzata la Authentication Identity
di default .
– Quest’ultima è usata da sistemi di amministrazione o dai server
proxy per il login con differenti identità utente.
– Questo campo deve contenere almeno 255 ottetti e deve
terminare con un ottetto NUL.
– Di solito, vengono utilizzati i caratteri US-ASCII, benché sono
supportati i caratteri UTF -8 .
– Questo campo deve essere almeno di 255 ottetti. Per questo
campo sono preferiti caratteri US-ASCII.
• Il server risponde inviando un messaggio
contenente la OTP challenge.
• Il client calcola il valore hash.
– Se non è in grado di inviare direttamente questo può inviare 6
parole formattate digitate manualmente
– Fornite dalla funzione di output del generatore OTP del client.
45
Meccanismi di
Meccanismi di
• Se il client vede una funzione hash sconosciuta
• Ad ogni autenticazione riuscita, il client genera
non sarà capace di processare una pass phrase
in input dall’utente.
– In questa situazione il client può stampare sei parole formattate,
cancellando questa sequenza.
– Tentare di utilizzare differenti meccanismi di SASL.
– Chiudere la connessione rifiutando l’autenticazione.
• Come risultato di questo comportamento, un
una risposta estesa nel formato “hex”, “word”,
“init-hex” e “init-word”.
– Non è richiesto al client di terminare la risposta con un spazio
bianco o un carattere di newline.
• I server devono tollerare un input di lunghezza
arbitraria.
– Può fallire l’autenticazione se la lunghezza dell’input del client è
eccessiva.
server è costretto ad utilizzare una funzione
hash che l’utente possiede.
46
47
48
8
OTP SASL: esempi -1
OTP SASL: esempi -2
• I messaggi contrassegnati da una “C:”
• I seguenti esempi di meccanismi OTP usano il
•
rappresentano i messaggi inviati dal client al
server
I messaggi con una “S:” rappresentano i
messaggi inviati dal server al client.
profilo ACAP di SASL. La pass phrase usata in
questi esempi è: This is a test.
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL> tim
S: + "otp-md5 499 ke1234 ext"
C: "hex:5bf075d9959d036f"
S: a001 OK "AUTHENTICATE completed"
– L’user name utilizzato è “tim” e non è prevista una
Authorizzation Identity. La stringa “<NUL>” rappresenta un
ottetto nullo.
OTP SASL: esempi -3
• Lo stesso esempio con init -hex extended
response:
risposta con sei parole formattate:
C: <NUL> tim
S: + "otp-md5 499 ke1234 ext“
C: "init-hex:5bf075d9959d036f:md5 499
ke1235:3712dcb4aa5316c1“
S: a001 OK "OTP sequence reset,
authentication complete"
C: <NUL> tim
S: + "otp-md5 499 ke1234 ext“
C: "word:BOND FOGY DRAB NE RISE MART“
S: a001 OK "AUTHENTICATE completed“
• Il seguente è un esempio del meccanismo OTP
• Lo stesso esempio utilizzando il meccanismo
utilizzando il profilo IMAP profilo di SASL.
OTP-SHA1:
51
52
Protocolli
• OTP SASL non prevede sessioni private,
autenticazione server o protezione da attacchi
attivi.
È soggetto ad attacchi passivi con dizionario ma
il rischio di tali attacchi può essere ridotto
scegliendo pass phrase opportune.
– Il database di autenticazione server, necessario per l’uso con
OTP, non necessita di essere plaintext-equivalent.
– Le implementazioni dei server devono essere progettate per
resistere a race attack .
C: a001 AUTHENTICATE OTP
S: +
C: AHRpbQ==
S: +b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
S: a001 OK AUTHENTICATE completed
Introduzione
OTP SASL: considerazioni sulla
sicurezza
•
50
OTP SASL: esempi -4
• Vediamo lo stesso esempio utilizzando una
C: <NUL> tim
S: + "otp-sha1 499 ke1234 ext“
C: "hex:c90fc02cc488df5e“
S: a001 OK "AUTHENTICATE completed"
49
53
Metodi di Autenticazione in LDAP
Panoramica
Scenari tipici
Autenticazione e Autorizzazione: definizione e concetti
Meccanismi di sicurezza richiesti
Autenticazione anonima
Autenticazione basata su password
Autenticazione basata su certificati
Altri meccanismi
Authorization Identity
TLS Ciphersuite
Il SASL service name per LDAP
9
Panoramica -1
Panoramica -2
• LDAP Versione 3 è un potente protocollo per
• Un servizio di accesso alle directory LDAP
deve prevenire:
accesso a directory.
– Accessi non autorizzati ai dati attraverso operazioni.
– Accessi non autorizzati di client che riutilizzano le
informazioni monitorando altri accessi.
– Accessi non autorizzati ai dati monitorando altri
accessi.
– Modifiche non autorizzate dei dati.
– Modifiche non autorizzate della configurazione.
– Uso non autorizzato o eccessivo di risorse (denial of
service).
– Spoofing di directory, ingannare un client mostrando
dati diversi da quelli presenti nella sua directory.
– Permette la ricerca, l’elaborazione e la manipolazione dei
dati contenuti in una directory. Offre un insieme di funzioni di
sicurezza.
• L’insieme minimo di funzioni di sicurezza di
LDAPv3 sono compatibili con macchine con
caratteristiche differenti.
55
Panoramica -3
56
Panoramica -4
• La suite di protocolli LDAP può essere protetta
con i seguenti meccanismi di sicurezza:
• Altri meccanismi di sicurezza:
– Protezione contro spoofing attraverso il protocollo TLS
oppure utilizzando meccanismi di crittografia dati di
SASL.
– Limitazione di risorse attraverso limiti amministrativi
sui servizi.
– Autenticazione del server attraverso il protocollo TLS
o meccanismi del SASL.
– Autenticazione del client attraverso l’insieme dei
meccanismi di SASL, possibilmente sostenuti da
scambio di credenziali TLS.
– Autorizzazione del client attraverso controlli di
accesso base formulati sull’identità del richiedente.
– Protezione dell’integrità dei dati attraverso il
protocollo TLS o con i meccanismi SASL.
57
Dati sensibili
58
Esempi di scenari tipici -1
• I "dati sensibili" sono dati che, se rivelati,
possono causare seri pericoli alla sicurezza del
loro possessore.
– Non tutti i dati protetti sono sensibili.
• In quali scenari della rete e come vengono
1. Una directory a sola lettura, non contenente
dati sensibili accessibili da tutti.
– Non richiede funzioni di sicurezza eccetto che per servizi limitati
dall'amministrazione.
dati sensibili, dove gli accessi in lettura sono
garantiti attraverso l’identità base.
gestiti i dati sensibili?
– Richiede una funzione di autenticazione sicura.
59
60
10
dati sensibili.
dati sensitivi, dove l'accesso in lettura è
disponibile per chiunque, l'accesso per l’update
può essere effettuato solo da persone
autorizzate.
– Il client deve essere assicurato che i dati della directory sian o
autenticati dal server e che non verranno modificati.
4. Un directory contenente dati sensibili.
– Questo scenario richiede funzioni di autenticazione sicure.
– Questo scenario richiede una sessione sicura che assicura
confidenzialità ed una funzione di autenticazione sicura.
61
Autenticazione, Credenziali,
Identità
Politiche di controllo di accesso
• Le credenziali di autenticazione asseriscono
• Una politica di controllo di accesso è un
•
•
l’identità di una parte che sta cercando di
stabilire una comunicazione con un’altra parte.
L’autenticazione è il processo di generazione,
trasmissione e verifica di queste credenziali per
stabilire l'identità delle parti.
Un'identità di autenticazione (authentication
identity) è il nome presentato in una credenziale.
63
Fattori di controllo di accesso
insieme di regole che definiscono la protezione
di risorse.
– Stabilisce quali entità e persone possano accedere alle risorse.
64
Identità di autorizzazione
• Una delle forme più usate di politiche di controllo
di accesso è l' access control list.
– E’ una lista di fattori di sicurezza. Il server li usa per deter minare
quando e come processare queste richieste.
– Tali fattori sono chiamati fattori di controllo di accesso
(ACFs, Access Control Factors).
– Includono: gli indirizzi IP sorgente e destinazione, una stringa
cifrata, il tipo di operazione inizialmente richiesta, l'ora del
giorno, ecc...
62
65
• Una authorization identity è uno dei tipi di
fattore di controllo di accesso.
– È il nome dell’utente o di un’altra entità che richiede di eseguire
un'operazione.
• SASL permette ai client di specificare una
authorization identity diversa dall’identità di
autenticazione asserita dalle credenziali del
client.
– Permette a un proxy server di autenticarsi con le proprie
credenziali o con l’identità della macchine per cui esegue il
servizio di proxy .
66
11
Meccanismi di sicurezza richiesti -1
Meccanismi di sicurezza richiesti -2
1. Per una directory pubblica a sola lettura può
essere usata l’autenticazione anonima.
2. Le implementazioni che prevedono
un’autenticazione basata su password devono
supportare l'autenticazione basata sul
meccanismo DIGEST-MD5 SASL.
3. Una directory con sessione protetta e
autenticata usa l’operazione Start dil TLS e una
semplice autenticazione o il meccanismo SASL
EXTERNAL.
• Se viene negoziato il protocollo TLS:
– Il client deve scartare tutte le informazioni sul server
che gli sono arrivate prima della negoziazione TLS.
• Se viene negoziato il livello di sicurezza SASL:
– Il client deve scartare tutte le informazioni sul server
ricevute precedentemente alla negoziazione SASL.
Autenticazione anonima
• Operazioni su directory che modificano entrate o
•
67
accedono ad attributi protetti richiedono
l’autenticazione del client.
Se non si effettuano queste operazioni il client
utilizza un'autenticazione anonima.
Procedure di autenticazione
anonima
• Un client LDAP che non ha completato con
•
– Ogni implementazione di LDAP deve supportare il meccanismo di
autenticazione anonima.
• Un LDAP server può decidere se consentire o
68
successo l'operazione di bind viene autenticato
in modo anonimo.
Un client LDAP può richiedere di autenticarsi
anonimamente in una richiesta di bind.
– Usando OCTECT STRING di lunghezza zero nella scelta di
autenticazione semplice.
negare il diritto di accesso ad un client che ha
effettuato un'autenticazione anonima.
69
70
Autenticazione anonima e TLS
Autenticazione basata su password
• Un client LDAP può usare l’operazione Start del
• Un’implementazione LDAP deve supportare
•
TLS per negoziare l’utilizzo degli strumenti di
sicurezza supportati da TLS.
Un server LDAP che richiede che il client fornisca
i propri certificati durante una negoziazione TLS,
può usare una politica locale di sicurezza.
– È usata per determinare se la negoziazione TLS è completata
con successo.
71
autenticazione con password.
– Usando i meccanismi DIGEST-MD5 di SASL per la protezione
delle password.
• Un’implementazione LDAP deve supportare la
scelta dell’autenticazione con password
“semplice” quando la connessione è protetta con
TLS.
72
12
Digest authentication -1
• Un client LDAP può determinare se il server
• Il server risponderà con una bind.
•
supporta questo meccanismo, effettuando una
richiesta di ricerca all’interno della root DSE.
Durante l’autenticazione iniziale, il client invia
una richiesta di bind.
–
–
–
–
– Il resultCode è saslBindInProgress.
– Il campo serverSaslCreds è presente ed è definito dal digestchallenge.
• Il client invierà una bind request, con un diverso
identificativo.
Il numero della versione è 3.
La scelta di autenticazione è SASL.
Il meccanismo di SASL è DIGEST -MD5.
Le credenziali sono assenti.
– Il numero della versione è 3.
– La scelta di autenticazione è SASL, il nome del meccanismo di
SASL è DIGEST-MD5.
– Le credenziali contengono la stringa definita dalla digetsresponse.
– Il server-type indicato sarà ldap.
73
Autenticazione “semplice”
utilizzando TLS -1
• Il server risponderà con una bind response.
• Un client che ha una entry della directory con
– il campo ResultCode indicherà se la funzione è terminata con
successo o meno.
un attributo userPassword, può autenticarsi in
questo modo:
• Se l’autenticazione ha successo e il server
supporta un ulteriore passo di autenticazione,
allora il campo contenente le credenziali conterrà
la stringa definita da response-auth.
– Se non richiede ulteriori autenticazioni il campo sarà vuoto.
– Il supporto di ulteriori identificazioni è opzionale sia per il client
che per il server.
75
– Esegue una semplice sequenza di bind con una semplice
password;
– Negozia una TLS ciphersuite che provvede ad una connessione
che assicura confidenzialità.
– Usa l’operazione Start del TLS per negoziare l’uso della
sicurezza del TLS sulla connessione ad un server LDAP.
utilizzando TLS -2
utilizzando TLS -3
• Un’autenticazione semplice ha successo se il
• Il server verifica se c'è corrispondenza tra il
•
74
76
proprio elenco e la password del client.
client e il server negoziano una ciphersuite.
Dopo una negoziazione TLS avvenuta con
successo, il client deve inviare una richiesta
LDAP al server.
– Se c’è una corrispondenza, risponde indicando nel campo
resultCode che si è verificato un successo.
– Altrimenti risponderà con il campo resultCode contenente
invalidCredenzial.
– Il cui numero di versione è 3.
– Il campo nome contiene il nome dell'entry dell'utente.
– Nel campo scelta di autenticazione “semplice”.
77
78
13
Altre Autenticazioni con TLS
utilizzando TLS -1
• In seguito ad una negoziazione TLS è possibile
• Se un utente ha una coppia di chiavi
effettuare un'autenticazione SASL che non
presenta lo scambio di password riutilizzabili in
chiaro.
pubblica/privata può autenticarsi ad un directory
server con i certificati.
– Il campo subject del certificato dell’utente contiene il nome
dell’entry della sua directory.
– Se il server si fida del’autorità che ha rilasciato la chiave pubblica
all’utente.
– Il client ed il server negoziano una ciphersuite è richiesta solo
l’integrità dei dati.
utilizzando TLS -2
• Il server deve verificare che il certificato
negoziare l’uso della sicurezza supportata dal
TLS su una connessione ad un server LDAP.
fornitogli dal client è valido.
– Il server richiede un certificato.
– Il client invierà il suo certificato al server cifrandolo con la chiave
privata.
– La cifratura proverà che il client è in possesso della chiave
privata del certificato che ha inviato.
su internet se la rete non assicura la
confidenzialità.
Se il client richiede un’identità di autorizzazione
differente da una distinguished name, dovrebbe
essere usato un meccanismo che protegge la
password in transito.
Il client può richiedere al server LDAP uno
scambio sicuro a basso livello delle credenziali
utilizzando il meccanismo SASL EXTERNAL.
• Il client invierà una richiesta di bind LDAP nella
quale sarà specificato EXTERNAL come
meccanismo di SASL.
82
Authorization Identity -1
• Un'autenticazione “semplice” non è consigliabile
•
– Controlla se il certificato è stato rilasciato da una fidata Autorità
di Certificazione.
– Controlla se i certificati siano non validi o revocati.
81
Altri meccanismi
•
80
utilizzando TLS -3
• l Client utilizza l’operazione Start del TLS per
79
83
• Una Authorization Identity è presente nel campo
•
delle credenziali SASL sia nelle richieste che nelle
risposte bind di LDAP.
Se il meccanismo “EXTERNAL” è negoziato, il
campo credenziali contiene una authorization
identity (se presente) della forma authzId.
84
14
Authorization Identity -2
TLS Ciphersuite -1
• L’authorization identity è una stringa nel formato
• Le seguenti ciphersuite, non devono essere
UTF-8, corrispondente al seguente ABNF:
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
dn = utf8string ; with syntax defined in RFC
2253
; unspecified userid, UTF -8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
usate per protezione e confidenzialità di
password o dati perché non offrono garanzie di
sicurezza.
TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
• Una utf8string è definita come la codifica UTF-8
di uno o più dei 10646 caratteri ISO.
85
TLS Ciphersuite -2
TLS Ciphersuite -3
• Le seguenti ciphersuite, possono essere
• Le seguenti ciphersuite sono vulnerabili ad
facilmente rotte (meno di una settimana per una
CPU standard del 1997).
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
86
attacchi man-in-the-middle e non devono essere
usate per proteggere password o dati sensibili.
– A meno che la configurazione della rete è tale che i pericoli di
attacchi man-in-the-middle sono tollerabili.
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
87
88
Bibliografia
•
•
•
•
•
•
•
•
•
•
•
•
•
www.OpenLDAP.org
Motore di Ricerca per RFC
RFC1938 One-Time Password System
RFC1321 The MD5 Message -Digest Algorithm
RFC2222 Simple Authentication and Security Layer (SASL)
RFC2246 The TLS Protocol Version 1.0
RFC2251 Lightweight Directory Access Protocol (v3)
RFC2253 Lightweight Directory Access Protocol (v3): UTF -8 String
Representation of Distinguished Names
RFC2444 The One-Time-Password SASL Mechanism
RFC2829 Authentication Methods for LDAP
RFC2831 Using Digest Authentication as a SASL Mechanism
RFC3377 Lightweight Directory Access Protocol (v3): Technical
Specification
RFC2828 Internet Security Glossary
89
15

Autenticazione in Ambienti Distribuiti: protocollo LDAP

Transcript

Documenti analoghi

Get Pdf - IGSuite

Disposizioni per la sicurezza e l`utilizzo degli strumenti informatici

2_Sicurezza Informatica - Istituto Paritario Michelangelo

una possibile soluzione opensource per un servizio di

Configurazione rete Wireless LUISSwpa Win8

Disattivazione del protocollo crittografico SSL v3 per internet Bug di

Protocollo Porta standard Porta SSL HTTP 80 443 NNTP 119 563

Outlook Express

PDF995, Job 2 - RETI CIVICHE per la PAL