[Date Prev][Date Next] [Chronological] [Thread] [Top]

draft-ietf-ldapext-ldapv3-tls-06.txt



Jeff,

I have only significant concern.

In 6.1.2:
	[Upon failure of BIND SASL/EXTERNAL...]
	The LDAP association's authentication identity and
       authorization identity (if any) which were in effect
       after TLS establishment but prior to making the Bind request,
       MUST remain in force.

This is inconsistent with RFC 2251 prescribed behavior:
  Clients MAY send multiple bind requests on a connection to change
  their credentials. ...  Authentication from earlier binds
  are subsequently ignored, and so if the bind fails, the connection
  will be treated as anonymous.

I can find no compelling reasoning why BIND failure whilst
TLS is enabled should have special behavior.  I believe this an
unnecessary complication.  I believe there are many good reasons
why this BIND behavior should be consistent without regard to TLS
(or IPSEC or whatever).  Reasons: simplicity of specification,
implementation, and use.

The general rule for security is simplicity.  Why the complication?