Passa al contenuto principale

5. Operazione Bind

L'operazione Bind ([RFC4511], sezione 4.2) consente lo scambio di informazioni di autenticazione tra client e server per stabilire un nuovo stato di autorizzazione.

La richiesta Bind specifica tipicamente l'identità di autenticazione desiderata. Alcuni meccanismi Bind consentono inoltre al client di specificare l'identità di autorizzazione. Se l'identità di autorizzazione non è specificata, il server la deriva dall'identità di autenticazione in modo specifico dell'implementazione.

Se l'identità di autorizzazione è specificata, il server DEVE (MUST) verificare che all'identità di autenticazione del client sia consentito assumere (ad esempio sostituirsi a) l'identità di autorizzazione asserita. Il server DEVE (MUST) respingere l'operazione Bind con un resultCode invalidCredentials nella risposta Bind se il client non è così autorizzato.

5.1. Metodo di autenticazione semplice​

Il metodo di autenticazione semplice dell'operazione Bind fornisce tre meccanismi di autenticazione:

  - Un meccanismo di autenticazione anonimo (sezione 5.1.1).

  - Un meccanismo di autenticazione non autenticato (sezione 5.1.2).

  - Un meccanismo di autenticazione nome/password che usa credenziali costituite da un nome (nella forma di un nome distinto LDAP [RFC4514]) e una password (sezione 5.1.3).

5.1.1. Meccanismo di autenticazione anonimo di Bind semplice​

Un client LDAP può usare il meccanismo di autenticazione anonimo del metodo Bind semplice per stabilire esplicitamente uno stato di autorizzazione anonimo inviando una richiesta Bind con un valore di nome di lunghezza zero e specificando la scelta di autenticazione semplice contenente un valore di password di lunghezza zero.

5.1.2. Meccanismo di autenticazione non autenticato di Bind semplice​

Un client LDAP può usare il meccanismo di autenticazione non autenticato del metodo Bind semplice per stabilire uno stato di autorizzazione anonimo inviando una richiesta Bind con un valore di nome (un nome distinto in forma di stringa LDAP [RFC4514] di lunghezza diversa da zero) e specificando la scelta di autenticazione semplice contenente un valore di password di lunghezza zero.

Il valore del nome distinto fornito dal client è destinato a essere usato solo a fini di tracciamento (ad esempio registrazione). Il valore non deve essere autenticato o altrimenti convalidato (inclusa la verifica che il DN si riferisca a un oggetto di directory esistente). Il valore non deve essere usato (direttamente o indirettamente) a fini di autorizzazione.

Le operazioni Bind non autenticate possono presentare problemi di sicurezza significativi (vedere la sezione 6.3.1). In particolare, gli utenti che intendono eseguire un'autenticazione nome/password possono fornire inavvertitamente una password vuota e causare così che client mal implementati richiedano un accesso non autenticato. I client DOVREBBERO (SHOULD) essere implementati in modo da richiedere che l'utente selezioni il meccanismo di autenticazione non autenticata con mezzi diversi dalla inserzione di una password vuota. I client DOVREBBERO (SHOULD) impedire l'inserimento di una password vuota in un'interfaccia utente di autenticazione nome/password. Inoltre, i server DOVREBBERO (SHOULD) per impostazione predefinita far fallire le richieste Bind non autenticate con un resultCode unwillingToPerform.

5.1.3. Meccanismo di autenticazione nome/password di Bind semplice​

Un client LDAP può usare il meccanismo di autenticazione nome/password del metodo Bind semplice per stabilire uno stato di autorizzazione autenticato inviando una richiesta Bind con un valore di nome (un nome distinto in forma di stringa LDAP [RFC4514] di lunghezza diversa da zero) e specificando la scelta di autenticazione semplice contenente un valore di password OCTET STRING di lunghezza diversa da zero.

I server che mappano il DN inviato nella richiesta Bind a una voce di directory con un insieme associato di una o più password usate con questo meccanismo confronteranno la password presentata con quell'insieme di password. La password presentata è considerata valida se corrisponde a qualsiasi membro di quell'insieme.

Un resultCode invalidDNSyntax indica che il DN inviato nel valore di nome è sintatticamente non valido. Un resultCode invalidCredentials indica che il DN è sintatticamente corretto ma non valido ai fini dell'autenticazione, che la password non è valida per il DN, o che il server considera altrimenti le credenziali non valide. Un resultCode success indica che le credenziali sono valide e che il server è disposto a fornire il servizio all'entità che queste credenziali identificano.

Il comportamento del server non è definito per le richieste Bind che specificano il meccanismo di autenticazione nome/password con un valore di nome di lunghezza zero e un valore di password di lunghezza diversa da zero.

Il meccanismo di autenticazione nome/password del metodo Bind semplice non è adatto all'autenticazione in ambienti privi di protezione della riservatezza.

5.2. Metodo di autenticazione SASL​

Il metodo di autenticazione sasl dell'operazione Bind fornisce le funzionalità per usare qualsiasi meccanismo SASL, compresi meccanismi di autenticazione e altri servizi (ad esempio servizi di sicurezza dei dati).

5.2.1. Profilo di protocollo SASL​

LDAP consente l'autenticazione tramite qualsiasi meccanismo SASL [RFC4422]. Poiché LDAP comprende metodi di autenticazione nativi anonimo e nome/password (testo in chiaro), i meccanismi SASL ANONYMOUS [RFC4505] e PLAIN [PLAIN] in genere non sono usati con LDAP.

Ogni protocollo che utilizza i servizi SASL è tenuto a fornire determinate informazioni che descrivono il modo in cui essi sono esposti attraverso il protocollo ([RFC4422], sezione 4). Questa sezione spiega come ciascuno di questi requisiti di profilazione è soddisfatto da LDAP.

5.2.1.1. Nome di servizio SASL per LDAP​

Il nome di servizio SASL per LDAP è "ldap", che è stato registrato presso l'IANA come nome di servizio SASL.

5.2.1.2. Avvio dell'autenticazione SASL e scambio di protocollo​

L'autenticazione SASL è avviata tramite un messaggio BindRequest ([RFC4511], sezione 4.2) con i seguenti parametri:

  - La versione è 3.
  - AuthenticationChoice è sasl.
  - L'elemento mechanism della sequenza SaslCredentials contiene il valore del meccanismo SASL desiderato.
  - Il campo facoltativo credentials della sequenza SaslCredentials PUÒ (MAY) essere usato per fornire una risposta iniziale del client per i meccanismi definiti in modo che il client invii per primo i dati (vedere [RFC4422], sezioni 3 e 5).

In generale, uno scambio di protocollo di autenticazione SASL consiste in una serie di sfide del server e risposte del client, il cui contenuto è specifico e definito dal meccanismo SASL. Quindi, per alcuni meccanismi di autenticazione SASL, può essere necessario che il client risponda a una o più sfide del server inviando più volte messaggi BindRequest. Una sfida è indicata dal server inviando un messaggio BindResponse con il resultCode impostato a

saslBindInProgress. Ciò indica che il server richiede al client di inviare un nuovo messaggio BindRequest con lo stesso meccanismo SASL per continuare il processo di autenticazione.

Per il livello di messaggi LDAP, queste sfide e risposte sono token binari opachi di lunghezza arbitraria. I server LDAP usano il campo serverSaslCreds (un OCTET STRING) in un messaggio BindResponse per trasmettere ogni sfida. I client LDAP usano il campo credentials (un OCTET STRING) nella sequenza SaslCredentials di un messaggio BindRequest per trasmettere ogni risposta. Si noti che, a differenza di alcuni protocolli Internet in cui SASL è usato, LDAP non è basato sul testo e non trasforma in Base64 questi valori di sfida e risposta.

I client che inviano un messaggio BindRequest con la scelta sasl selezionata DOVREBBERO (SHOULD) inviare un valore di lunghezza zero nel campo name. I server che ricevono un messaggio BindRequest con la scelta sasl selezionata IGNORERANNO (SHALL) qualsiasi valore nel campo name.

Un client può interrompere una negoziazione Bind SASL inviando un messaggio BindRequest con un valore diverso nel campo mechanism di SaslCredentials o con un AuthenticationChoice diverso da sasl.

Se il client invia una BindRequest con il campo mechanism di sasl come stringa vuota, il server DEVE (MUST) restituire una BindResponse con un resultCode authMethodNotSupported. Ciò consentirà al client di interrompere una negoziazione se desidera riprovare con lo stesso meccanismo SASL.

Il server indica il completamento dello scambio sfida-risposta SASL rispondendo con una BindResponse in cui il valore del resultCode non è saslBindInProgress.

Il campo serverSaslCreds nella BindResponse può essere usato per includere una sfida facoltativa con una notifica di successo per i meccanismi definiti in modo che il server invii dati aggiuntivi insieme all'indicazione del completamento con successo.

5.2.1.3. Campi facoltativi​

Come discusso sopra, LDAP fornisce un campo facoltativo per trasportare una risposta iniziale nel messaggio che avvia lo scambio SASL e fornisce un campo facoltativo per trasportare dati aggiuntivi nel messaggio che indica l'esito dello scambio di autenticazione. Poiché il contenuto specifico del meccanismo in questi campi può avere lunghezza zero, SASL richiede che le specifiche di protocollo dettaglino come un campo vuoto si distingue da un campo assente.

Dati di risposta iniziale di lunghezza zero si distinguono da dati di risposta iniziale assenti, nel messaggio di avvio, una PDU BindRequest, per la presenza dell'OCTET STRING SaslCredentials.credentials (di lunghezza zero) in quella PDU. Se il client non intende inviare una risposta iniziale con la BindRequest che avvia lo scambio SASL, DEVE (MUST) omettere l'OCTET STRING SaslCredentials.credentials (anziché includere un OCTET STRING di lunghezza zero).

Dati aggiuntivi di lunghezza zero si distinguono da dati di risposta aggiuntivi assenti, nel messaggio di esito, una PDU BindResponse, per la presenza dell'OCTET STRING serverSaslCreds (di lunghezza zero) in quella PDU. Se un server non intende inviare dati aggiuntivi nel messaggio BindResponse che indica l'esito dello scambio, il server DEVE (SHALL) omettere l'OCTET STRING serverSaslCreds (anziché includere un OCTET STRING di lunghezza zero).

5.2.1.4. Ottetto in cui i livelli di sicurezza negoziati prendono effetto​

I livelli SASL prendono effetto dopo la trasmissione da parte del server e la ricezione da parte del client della BindResponse finale nello scambio SASL con un resultCode success.

Una volta che un livello SASL che fornisce servizi di integrità o riservatezza dei dati prende effetto, il livello rimane in vigore fino a quando non viene installato un nuovo livello (cioè al primo ottetto successivo alla BindResponse finale dell'operazione Bind che ha fatto prendere effetto al nuovo livello). Pertanto, un livello SASL stabilito non è influenzato da un Bind fallito o non SASL.

5.2.1.5. Determinazione dei meccanismi SASL supportati​

I client possono determinare i meccanismi SASL che un server supporta leggendo l'attributo 'supportedSASLMechanisms' dal DSE radice (DSA-Specific Entry) ([RFC4512], sezione 5.1). I valori di questo attributo, se presenti, elencano i meccanismi che il server supporta nello stato attuale della sessione LDAP. I server LDAP DOVREBBERO (SHOULD) consentire a tutti i client — anche quelli con un'autorizzazione anonima — di recuperare l'attributo 'supportedSASLMechanisms' del DSE radice sia prima sia dopo lo scambio di autenticazione SASL. Lo scopo di quest'ultimo recupero è permettere al client di rilevare possibili attacchi di declassamento (vedere la sezione 6.4 e [RFC4422], sezione 6.1.2).

Poiché i meccanismi SASL forniscono funzioni di sicurezza critiche, client e server dovrebbero essere configurabili per specificare quali meccanismi sono accettabili e consentire l'uso solo di tali meccanismi. Sia i client che i server devono confermare che il livello di sicurezza negoziato soddisfi i loro requisiti prima di procedere all'uso della sessione.

5.2.1.6. Regole per l'uso dei livelli SASL​

All'atto dell'installazione di un livello SASL, il client DOVREBBE (SHOULD) scartare o aggiornare tutte le informazioni sul server che ha ottenuto prima dell'inizio della negoziazione SASL e che non ha ottenuto tramite meccanismi sicuri.

Se è installato un livello di sicurezza di livello inferiore (ad esempio TLS), qualsiasi livello SASL DEVE (SHALL) essere sovrapposto a tali livelli di sicurezza indipendentemente dall'ordine della loro negoziazione. In tutti gli altri aspetti, il livello SASL e gli altri livelli di sicurezza agiscono in modo indipendente: ad esempio, se sono in vigore sia un livello TLS sia un livello SASL, la rimozione del livello TLS non influisce sul servizio continuo del livello SASL.

5.2.1.7. Supporto di autenticazioni multiple​

LDAP supporta più autenticazioni SASL, come definito in [RFC4422], sezione 4.

5.2.1.8. Identità di autorizzazione SASL​

Alcuni meccanismi SASL consentono ai client di richiedere un'identità di autorizzazione desiderata per la sessione LDAP ([RFC4422], sezione 3.4). La decisione di consentire o negare all'attuale identità di autenticazione l'accesso all'identità di autorizzazione richiesta è una questione di politica locale. L'identità di autorizzazione è una stringa di caratteri [Unicode] codificati in UTF-8 [RFC3629] corrispondente alla seguente grammatica Augmented Backus-Naur Form (ABNF) [RFC4234]:

  authzId = dnAuthzId / uAuthzId

  ; distinguished-name-based authz id
  dnAuthzId =  "dn:" distinguishedName

  ; unspecified authorization id, UTF-8 encoded
  uAuthzId = "u:" userid
  userid = *UTF8 ; syntax unspecified

dove la regola distinguishedName è definita nella sezione 3 di [RFC4514] e la regola UTF8 è definita nella sezione 1.4 di [RFC4512].

La scelta dnAuthzId è usata per asserire identità di autorizzazione sotto forma di nome distinto, da confrontare in conformità con la regola di corrispondenza distinguishedNameMatch ([RFC4517], sezione 4.2.15). Non è richiesto che il valore distinguishedName asserito sia quello di una voce nella directory.

La scelta uAuthzId consente ai client di asserire un'identità di autorizzazione che non è in forma di nome distinto. Il formato di userid è definito solo come una sequenza di caratteri [Unicode] codificati in UTF-8 [RFC3629], e qualsiasi ulteriore interpretazione è una questione locale. Ad esempio, il userid può identificare un utente di un servizio di directory specifico, essere un nome di accesso o essere un indirizzo di posta elettronica. Un uAuthzId NON DOVREBBE (SHOULD NOT) essere assunto come globalmente univoco. Per confrontare i valori uAuthzId, ogni valore uAuthzId DEVE (MUST) essere preparato come stringa "query" ([RFC3454], sezione 7) usando l'algoritmo SASLprep [RFC4013], e poi i due valori sono confrontati ottetto per ottetto.

La grammatica sopra è estensibile. La produzione authzId può essere estesa per supportare forme aggiuntive di identità. Ogni forma è contraddistinta dal suo prefisso univoco (vedere la sezione 3.12 di [RFC4520] per i requisiti di registrazione).

5.2.2. Semantica di SASL all'interno di LDAP​

Gli implementatori devono avere cura di mantenere la semantica delle specifiche SASL quando gestiscono dati che hanno una semantica diversa nel protocollo LDAP.

Ad esempio, il meccanismo di autenticazione SASL DIGEST-MD5 [DIGEST-MD5] utilizza un'identità di autenticazione e un realm che sono sintatticamente semplici stringhe e semanticamente semplici valori di nome utente [RFC4013] e realm. Questi valori non sono DN LDAP, e non vi è alcun requisito che siano rappresentati o trattati come tali.

5.2.3. Meccanismo di autenticazione SASL EXTERNAL​

Un client può usare il meccanismo SASL EXTERNAL ([RFC4422], appendice A) per richiedere al server LDAP di autenticarlo e stabilire un'identità di autorizzazione risultante usando credenziali di sicurezza scambiate da un livello di sicurezza inferiore (ad esempio mediante autenticazione TLS). Se le credenziali di autenticazione del client non sono state stabilite a un livello di sicurezza inferiore, il Bind SASL EXTERNAL DEVE (MUST) fallire con un resultCode inappropriateAuthentication. Sebbene questa situazione abbia l'effetto di lasciare la sessione LDAP in uno stato anonimo (sezione 4), lo stato di qualsiasi livello di sicurezza installato non è influenzato.

Un client può richiedere che la sua identità di autorizzazione sia derivata automaticamente dalle sue credenziali di autenticazione scambiate a un livello di sicurezza inferiore, oppure può fornire esplicitamente un'identità di autorizzazione desiderata. La prima è detta asserzione implicita, la seconda asserzione esplicita.

5.2.3.1. Asserzione implicita​

Un'asserzione implicita di identità di autorizzazione è eseguita invocando una richiesta Bind di forma SASL usando il nome di meccanismo EXTERNAL che non include il campo facoltativo credentials (presente nella sequenza SaslCredentials nella BindRequest). Il server deriverà l'identità di autorizzazione del client dall'identità di autenticazione fornita da un livello di sicurezza (ad esempio un certificato a chiave pubblica usato durante l'installazione del livello TLS), secondo la politica locale. I meccanismi sottostanti con cui ciò viene realizzato sono specifici dell'implementazione.

5.2.3.2. Asserzione esplicita​

Un'asserzione esplicita di identità di autorizzazione è eseguita invocando una richiesta Bind di forma SASL usando il nome di meccanismo EXTERNAL che include il campo credentials (presente nella sequenza SaslCredentials nella BindRequest). Il valore del campo credentials (un OCTET STRING) è l'identità di autorizzazione asserita e DEVE (MUST) essere costruita come documentato nella sezione 5.2.1.8.