Authentication Methods
and
Connection Level Security Mechanisms
for LDAPv3

Roger G. Harrison

draft-ldapbis-authmeth-01.txt

 

Modifications for -01

•      Incoporated all Bind operation material from ldapbis-protocol-02.

–   Intention is to leave only the ASN.1 definition and a short description in protocol doc

•      Incorporated all material from RFC 2830 Start TLS (extended) operation.

Modifications for -01 (cont.)

•      Made the discussion of Bind and Start TLS operations parallel in form.

–   PDUs and ASN.1 definitions were NOT changed.

Modifications for -01(cont.)

•      Reorganized material to have related information together.

–   Some reorganization was already done in -00 version

–   Brought all material on SASL together.

•   RFC 2251 sections 4.4 - 4.7

•   RFC 2829 sections 8, 9, 11, 12

•      Moved security “tutorial” information to appendices

Outstanding work

•      Provide StartTLS state transition table

•      Clarify or define several terms, phrases, and references in the document.

–   Examples: LDAP association, secure authentication function, session protection

 

Outstanding work (cont.)

•      Clarifications on Start TLS semantics

–   does “discarding information fetched prior to TLS negotiation” mean beginning or end of the negotiation?

–   Is admonition that clients SHOULD check supportedSASLMechanisms list after negotiating  a SASL security layer really a requirement that they MUST check it UNLESS they use a different trusted source to determine available supported SASL mechanisms?

Outstanding work (cont.)

•      Several past questions & suggestions on list

–   document ordering of strengths of authentication levels

–   document vulnerabilities of various mechanisms

–   explicitly state what to do if SASL credentials are empty

–   explicitly state whether the DN must exist in the directory if the dn form of SASL credentials is used

Outstanding work (cont.)

•      Several past questions & suggestions on list

–   loosen requirements on hostname check?

–   document whether userPassword attribute type is the only attribute type allowed to store password values (currently implied, probably not the intent of the doc)