Passa al contenuto principale

Appendice B. Riepilogo delle modifiche

Questa appendice non è normativa.

Questa appendice riassume le modifiche sostanziali apportate all'RFC 2251, all'RFC 2829 e all'RFC 2830. Oltre alle modifiche specifiche dettagliate di seguito, il lettore di questo documento dovrebbe essere consapevole che sono state apportate numerose modifiche redazionali generali al contenuto originale dei documenti di origine. Tali modifiche includono le seguenti:

  • Il materiale originariamente presente nelle sezioni 4.2.1 e 4.2.2 dell'RFC 2251, nell'RFC 2829 (tutte le sezioni tranne le sezioni 2 e 4) e nell'RFC 2830 è stato riunito in un unico documento.

  • Il materiale riunito è stato sostanzialmente riorganizzato e rielaborato per raggruppare argomenti correlati, migliorare la scorrevolezza del documento e chiarirne l'intento.

  • Sono state apportate modifiche a tutto il testo per allinearlo alle definizioni dei livelli di protocollo LDAP e alla terminologia di sicurezza IETF.

  • Le considerazioni sulla sicurezza di entrambi i documenti sono state sostanzialmente aggiornate e integrate sulla base dell'esperienza operativa attuale.

B.1. Modifiche apportate all'RFC 2251​

Questa sezione riassume le modifiche sostanziali apportate da questo documento alle sezioni 4.2.1 e 4.2.2 dell'RFC 2251. Ulteriori modifiche sostanziali alla sezione 4.2.1 dell'RFC 2251 sono documentate anche in [RFC4511].

B.1.1. Sezione 4.2.1 ("Sequenziamento della richiesta Bind")​

  • Paragrafo 1: rimossa la frase "If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection". L'operazione Unbind consente ancora questo comportamento, ma esso non è documentato in modo esplicito.

  • Chiarito che la sessione passa a uno stato anonimo al ricevimento della PDU BindRequest e che passa a uno stato non anonimo solo se e quando la richiesta Bind ha esito positivo.

B.1.2. Sezione 4.2.2 ("Autenticazione e altri servizi di sicurezza")​

  • L'RFC 2251 afferma che l'autenticazione anonima DEVE (MUST) essere eseguita con il metodo bind semplice. Questa specifica definisce il meccanismo di autenticazione anonima del metodo bind semplice e richiede che tutte le implementazioni conformi lo supportino. Anche altri meccanismi di autenticazione che producono uno stato di autenticazione e autorizzazione anonimo possono essere implementati e usati da implementazioni conformi.

B.2. Modifiche apportate all'RFC 2829​

Questa sezione riassume le modifiche sostanziali apportate all'RFC 2829.

B.2.1. Sezione 4 ("Meccanismi di sicurezza richiesti")​

  • Il meccanismo di autenticazione nome/password (vedere la sezione B.2.5 di seguito), protetto da TLS, sostituisce il meccanismo SASL DIGEST-MD5 come meccanismo di autenticazione basato su password obbligatorio da implementare in LDAP. Le implementazioni sono incoraggiate a continuare a supportare SASL DIGEST-MD5 [DIGEST-MD5].

B.2.2. Sezione 5.1 ("Procedura di autenticazione anonima")​

  • Chiarito che l'autenticazione anonima comporta un valore di nome di lunghezza zero e un valore di password di lunghezza zero. Il meccanismo di autenticazione non autenticata è stato aggiunto per gestire le richieste Bind semplici che comportano un valore di nome di lunghezza diversa da zero e un valore di password di lunghezza zero.

B.2.3. Sezione 6 ("Autenticazione basata su password")​

  • Vedere la sezione B.2.1.

B.2.4. Sezione 6.1 ("Autenticazione Digest")​

  • Poiché il meccanismo SASL-DIGEST-MD5 non è più obbligatorio da implementare, questa sezione è ora storica e non è stata inclusa in questo documento. La sezione 6.1 dell'RFC 2829 continua a documentare il meccanismo di autenticazione SASL DIGEST-MD5.

B.2.5. Sezione 6.2 ("Scelta di autenticazione "simple" sotto cifratura TLS")​

  • Il meccanismo di autenticazione "simple" è stato rinominato meccanismo di autenticazione nome/password per descriverlo meglio.

  • L'uso di TLS è stato generalizzato per allinearlo alle definizioni dei livelli di protocollo LDAP. La costituzione di TLS è ora discussa come argomento indipendente ed è generalizzata per l'uso con tutti i meccanismi di autenticazione e gli altri livelli di sicurezza.

  • Rimossa l'implicazione che l'attributo userPassword sia l'unica sede di memorizzazione dei valori di password da usare nell'autenticazione. Non esiste più alcun requisito implicito su come o dove le password siano memorizzate sul server per l'uso nell'autenticazione.

B.2.6. Sezione 6.3 ("Altre scelte di autenticazione con TLS")​

  • Vedere la sezione B.2.5.

B.2.7. Sezione 7.1 ("Autenticazione basata su certificato con TLS")​

  • Vedere la sezione B.2.5.

B.2.8. Sezione 8 ("Altri meccanismi")​

  • Tutti i meccanismi di autenticazione SASL sono esplicitamente consentiti all'interno di LDAP. In particolare, ciò significa che i meccanismi SASL ANONYMOUS e SASL PLAIN non sono più esclusi dall'uso all'interno di LDAP.

B.2.9. Sezione 9 ("Identità di autorizzazione")​

  • Specificate le regole di corrispondenza per i valori dnAuthzId e uAuthzId. In particolare, il valore DN nella forma dnAuthzId deve essere confrontato usando le regole di corrispondenza dei DN, e il valore uAuthzId DEVE (MUST) essere preparato con le regole SASLprep prima di essere confrontato ottetto per ottetto.

  • Chiarito che i valori uAuthzId non dovrebbero essere presunti globalmente unici.

B.2.10. Sezione 10 ("Suite di cifratura TLS")​

  • Le raccomandazioni sulle suite di cifratura TLS non sono più incluse in questa specifica. Le implementazioni devono ora supportare la suite di cifratura TLS_RSA_WITH_3DES_EDE_CBC_SHA e dovrebbero continuare a supportare la suite di cifratura TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

  • Chiarito che l'autenticazione anonima comporta un valore di nome di lunghezza zero e un valore di password di lunghezza zero. Il meccanismo di autenticazione non autenticata è stato aggiunto per gestire le richieste Bind semplici che comportano un valore di nome di lunghezza diversa da zero e un valore di password di lunghezza zero.

B.3. Modifiche apportate all'RFC 2830​

Questa sezione riassume le modifiche sostanziali apportate alle sezioni 3 e 5 dell'RFC 2830. I lettori dovrebbero consultare [RFC4511] per i riepiloghi delle modifiche alle altre sezioni.

B.3.1. Sezione 3.6 ("Verifica dell'identità del server")​

  • Aggiornato sostanzialmente l'algoritmo di verifica dell'identità del server per garantirne la completezza e la robustezza. In particolare, l'uso di tutti i valori pertinenti nei campi subjectAltName e subjectName è coperto dall'algoritmo, e per ogni tipo di valore sono specificate regole di corrispondenza. Le forme mappate (derivate) dell'identità del server possono ora essere usate quando la mappatura è eseguita in modo sicuro.

B.3.2. Sezione 3.7 ("Aggiornamento delle informazioni sulle capacità del server")​

  • I client non sono più tenuti ad aggiornare sempre le informazioni sulle capacità del server dopo la costituzione di TLS. Ciò serve a tenere conto delle situazioni in cui tali informazioni sono state ottenute tramite un meccanismo sicuro.

B.3.3. Sezione 5 ("Effetti di TLS sull'identità di autorizzazione di un client")​

  • La costituzione di un livello TLS su una sessione LDAP può ora comportare una modifica dello stato di autorizzazione della sessione LDAP.

B.3.4. Sezione 5.2 ("Effetti della chiusura della connessione TLS")​

  • La chiusura di un livello TLS su una sessione LDAP modifica lo stato di autenticazione e autorizzazione della sessione LDAP in base alla politica locale. In particolare, ciò significa che le implementazioni non sono tenute a riportare gli stati di autenticazione e autorizzazione ad anonimo alla chiusura di TLS.

  • Sostituiti i riferimenti all'RFC 2401 con l'RFC 4301.